Improving the gibbing system

Black Mesa Archive The Cafeteria
#1

Currently, gibbing is “bits and pieces” or nothing at all. This means that if one has gibbing turned on, a killed enemy’s corpse will be either intact or totally dismembered. Partial gibbing, like the one seen in L4D2, was not done by the devs due to huge amount of work it would require, and the final effect not being worth it.

An idea of two-stage gibbing came to my mind, and it would probably be a fine balance between gameplay value and amount of work needed to put into it (but I’m not sure, I’m neither a Source modder nor computer specialist). If there is a force strong enough to justify gibbing, the enemy would only lose let’s say a head and a right arm, while torso, left arm and legs would remain. If the resulting corpse is hit, it will further dismember into a state that we have in current gibbing system. Correct me if I’m wrong, but this would only need a creation of one more model for each enemy, as opposed to a total of 32 of them if partial gibbing à la L4D2 were to be implemented.

This would have several benefits:

  • Gibbing would initially generate less gibs, allowing players with weak PCs to have it enabled. Maybe there would be an option to allow only the first stage of gibbing if someone has good enough PC for it, but not good enough to allow even more gibs from full gibbing.
  • Gibbing would be more reasonable and believable, for example it’s quite ridiculous for a .50 cal to explode HECU soldiers with a single bullet. It also works the other way - for example, the tripmine’s explosion at the very beginning of WGH is not strong enough and close enough to gib a scientist, leaving his body intact. This is probably the most blatant example of current gib system’s limitations (I’m not ranting, I like the current gibbing system but this really stood out for me).
  • Gibbing could happen more often without worrying about game performance and entity limit, so the first stage of gibbing would require less damage done to the corpse than it currently needs to dismember it wholly. Currently, it happens quite often that you blow an explosive really close to a body, and it’s still intact. But should the “gib sensitivity” be higher, gibbing would probably happen too often, having an impact on game performance due to large number of entities it generates. Two-stage gibbing would rectify this issue.
  • The second gibbing stage could be also triggered by normal non-explosive weapons like MP5 and shotgun, since corpses are already badly damaged so they are more prone to damage and it would justify gibbing it more easily (maybe they would even have parts of skin torn out aside from missing a head and an arm to suggest they can be gibbed even further?). It would be fun for players to play with bodies (I know people enjoy this little massacre in a video game like this). This could also help re-introducing shotgun gibbing while keeping shotgun’s devastating capabilities within more reasonable bounds - it’s a bit sad it was cut, it would be really satisfying if it happened randomly from time to time, especially due to it’s wow-factor.

For example, current gibbed houndeye could be considered a first-stage gibbing of this creature, since it actually doesn’t differ much from it’s intact corpse. The second stage could be for example tearing its torso in half and shattering its eye.
Again - I am no modder nor programmer of any sort, I’m just a player and I think this idea was worth sharing. What do you think about it?

#2

I’m pretty sure partial gibbing a la L4D2 requires an insane number of models/submodels, IIRC.

#3

“as opposed to” refers to L4D2 gibbing

#4

Ah. Still requires at least a few extra models. Knowing the BM team though, they’d probably want to avoid that kind of work. :frowning:

#5

The biggest problem here is that, as far as I can tell, they’re already pushing the limits with regards to entity count in a map. Spawning additional entities in the form of increased number of gibs might cause the engine (and therefore the game) to crash.

#6

But there would be LESS of them. For example if you gib a scientist, you’ll get torso with legs and one arm and head, dismembered arm, and head parts (eye, brain etc.) - so 3 less entites because most limbs are still attached. And that would be the only option of gibbing a scientist - no other partially dismembered models of him would exist.

#7

so does anyone know for sure, if they could possibly implement such a gibbing system with a few lines of code or will it take a dozen seperate models?

I myself would actually like to pop a scientist in the head with a shotty and watch the head turn to jelly. That’d be nice.

#8

What about the new source 2013 engine? Would it push the engine too much as well? I’m asking since I’m not familiar with the engine since it’s new.

#9

I remember reading somewhere about TF2’s really neat solution to this problem. What they’d do when a character got beheaded was to 1. spawn the appropriate head gib and 2. shrink the head on the model down to nothing so it’d be like it wasn’t even there. It’s really efficient because it doesn’t require making additional models, rather it’s more a matter of modifying gib behavior.

Take an HECU for example. You gib his arm. If we used TF2’s system, we just spawn an arm gib (which exists already), while on the HECU himself we just shrink everything past the arm to make it appear like he’s been dismembered.

#10

Hm, I don’t think that would help the engine running out of edicts (which BM seems to constantly be playing chicken with already).

While I can’t speak for commercial Source branch, if I’m not mistaken the 2013 branch is literally just the 2007 branch (the one the current release is on) plus some additional OS support.

#11

So if the game detects you killed a HECU, and done most of the damage to his arm and head (for example), it spawns arm gib and head gib(s) and shrinks arm and head on the actual ragdoll? That’s really clever, but texture seams on the ragdoll may be a problem (beheaded corpses in TF2 look quite weird with triangle-shaped skin in the place where their head used to be).
But for this to work, doesn’t every limb have to be a separate entity? If so, the idea’s screwed due to entity limit.

#12

I don’t think the limbs have to be separate entities, but the game would have to keep track of what limb gets how much damage, as well as spawning a new model to cover up the missing bit with a little gore.

Also I don’t think 2013 can make parts of ragdolls stop colliding like (I think) L4D2 branch can.

I could be wrong. Or maybe the devs have a newer branch than 2013 since they’re getting it directly from Valve. I guess we’ll see whether or not that’s the case on release.

#13

Hopefully Valve is letting them use a newer branch of the engine then.

#14

I have a simple solution to the entity problem: Area portals. between each area, have an area portal so that the engine only renders what is in that specific room, not the whole map. The engine would only load the entities once the player goes through the area portal.
The area portals would have to be in a blind spot And would be activated when the players steps through the corner or opens the door.

Area Portal explanation.

(the rectangles are entities) The toggle switch turns entities on and off.

#15

No. That’s not how that works.

I mean, you’re correct in that areaportals help control what’s being rendered, but it wouldn’t solve the issue of running out of edicts, it’s not that simple. Trust me, the devs have far mastered areaportals, but they’re not a miracle solution by any means.

For example: visleaves already ensure the entire map isn’t rendered at all times. Areaportals aren’t the whole backbone to that or anything. The issue isn’t simply “too much rendered on screen at once.”

#16

Just because the engine doesn’t render an entity doesn’t mean that entity doesn’t exist. That’s kind of like saying you can win a game of hide and seek by covering your eyes.

The problem is that too many gibs = too many entities IN EXISTENCE, not that there are too many entities being RENDERED.

#17

I reread that page and you’re both right. If only Valve would purchase the Avalanche engine and merge it with Source, then the problem would be solved.

#18

I’m not an expert, but I’m 99% sure that taking two very different engines built for entirely different games and “merging” them isn’t a thing to happen just like that.

#19

Yeah merging the engines probably wouldn’t work to well. It would also probably cause more issues than it would solve.

#20

Of course it would take time but implementing the API of Avalanche into source would allow Valve to make much larger maps that wouldn’t require loading times.

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.