Rise of the Dead! (still WIP in 2017)

[SoulCrow]

Is there such a thing as "truly undead"? It just depends how hard you want the game to be. If you wanted to go further, for example, you could make it so that the zombies have to be gibbed.

[Blade3327]

Just had a thought regarding all of these title options. Nash, if you're undecided on some of them, you can use the ones that didn't make the cut as difficulty levels.

"Never Dead" could represent an easier difficulty while "Drop Dead" could represent a tougher one.

[Nash]

There won't be difficulty levels, not at least in the way Doomers are used to having it - there will be an in-game difficulty slider, you can change this any time you want.

[FDARI]

Faking death is usually a bother because of fixed-size hitboxes. You could obviously make them unshootable and such, but then again it seems unfair to have play-dead enemies that you cannot walk up to and savage until they'll stay down.

I tried something for that long time ago, with morphs for each appearance. Health management was a big issue.

If you have invisible hitbox-actors for a multipart monster, you might be able to disable and enable hitboxes to represent various conditions. You could even implement something like that just for the sake of playing dead.

[Nash]

Yeah, that was what I had in mind.

In other news, I ran coop on this mod for the first time, only to realize how BROKEN it is. Everything is all over the place; sun glares don't work, players' personal sound emitters don't work too (it is what I use to play looping environmental sounds like rain and being underwater per player), and a whole bunch of other things... I wonder what else is broken at this point...

Maybe I shouldn't bother with coop support... ?

[Gez]

The perils of using hacks to fake features through workarounds!

You mentioned earlier that you planned eventually to contract a programmer for coding stuff. If you want multiplayer support for your mod and your sanity relatively intact, my advice would be to let things like sun glares and sound emitters be part of that future job. It's possible in game code to do such things a lot more reliably than when you have to go through the interface of a scripting language that was never designed for such tasks...

[Nash]

Yeah, I'm not going to make myself lose sleep over it. Noted it down in my list of things to fix... as you've said, things like those are better implemented into the renderer rather than through ACS and HUDMessages.

With regards to the "sound emitter", the only problem here is that I can't control looped sounds that are played through ACS. Otherwise, the existing activator ambient sound functions are more than enough.

So to "hack" around it, I tried attaching each players their own sound emitter.

[SamVision]

Maybe you can make a special coop edition when the mod is complete.

[NeuralStunner]

Random idea: Make zombies of various ethnicities. (Then count the number of people that call it "racist" because they're not all caucasian.)

[Nash]

Neural: Already planned. :)

[Nash]

carlcyber was awesome enough to help me fix the multiplayer issues, so now, everything works as expected. Yay. :D

I will develop this game with coop support from the get-go; it's much easier this way, than developing a finished product then try to "patch in" coop support. It would be a headache and waste of time...

[Nash]

Just some random thoughts on dismemberment and locational damage...

As it is, doing limb dismemberment is difficult because of the model format: it isn't skeletal-based, so doing separate things to separate limbs just isn't possible. For example, I can't have a broken arm dangling because there aren't any ragdoll physics.

I can split up a zombie into several models that will then be composited at the exact position and origin*, to make up 1 complete model:

head.md3
torso.md3
arm-l.md3
arm-r.md3
legs.md3

... but they all must share the same animation, otherwise the model wouldn't match up.

If the player decides to cut off the left arm, all the game will be doing is just render arm-l.md3 invisible (and spawn a generic-looking arm that flies out) - or destroy the actor associated with it.

Since the models are all at the exact XYZ*, detecting collision will be impossible. So another set of separate actors will have to be setup and attached for their hitboxes. These invisible actors will have their radius and height setup properly for locational damage.

* Why all in the same XYZ? When the modeler starts exporting, there will be a procedure to separate the main mesh and skeleton into separate files, yet maintain their origin. So to put these 5 models back together, they'd have to be placed all at the same XYZ. Attempting to offset these manually is just too much work. Perhaps to save up on CPU cycles, these individual body parts can be set to "render only", meaning give them the +NOINTERACTION flag, because they aren't meant to collide with anything - they are just there for display purposes. Actual collision and damage calculation will be done on the hitboxes.

This all applies for a zombie who is standing up. When a zombie is lying on the ground (either from a fake death, or from a legless state, where it has no legs and is forced to lie on the ground), the hitboxes will have to be setup differently, obviously.

This is a very messy situation... mainly related to actor parent/child behaviour...

---

I've been playing too much Dead Island...

[SamVision]

---

Dead Island had some great ideas, but the end product felt unpolished and unfinished.

[FDARI]

I don't think Limbs of (G)ZDoom is feasible until such time as somebody exceptional comes up with a stable and proven system for it, and I don't see that happening anytime soon -if at all.
I think a headshot system is the best we can expect at this time.

All graphics in single models.
Cut head from standard hitbox.
Use a generic head-hitbox actor that transfers damage with type HEADSHOT to master. (Main actor may have a damage factor for this damage type)

Have custom states such as death.headshot. Have xdeath and headshot guarantee that the monster stays down. False death states could introduce a similar hitbox actor to finish off the dishonest corpse.

Specifics and niceties are absent from this post. I don't know if you'll be going with anything like this at all (or whether you'll need help with that), so no sense droning on about it.

[Nash]

Yeah, sat down and had a production meeting with my team of artists and we concluded that limbs are out. It's way out of the engines' capabilities.

We came up with a hit box-less solution:

Head shots and legshots will definitely be in - the script that handles this is only 13 lines. :) All it does is check for the Z position of the blood splat. Pretty clever, eh? :D

False deaths can be handled by spawning a separate actor with a much shorter actor height. There is no issue with health transfer, because the zombie had to have its health depleted in the first place before it even got into this false death state. When it respawns, spawn a weaker "live" version of the first zombie (reduced spawn health). DECORATE inheritance will take care of this.

It also means less hassle for our modeler. He only has to export 1 MD3. I will toggle the visibility of the head, legs and torso by changing the models' textures (to make them invisible, just use a texture with transparency) during runtime.