Integrated Footsteps - what was the actual design?

[neoworm]

I am looking into implementing TERRAIN based footsteps and since the last time I looked there are another set of values for TERRAIN defs concerning step sounds and frequency. Effectively two separate ways to define frequency of sounds.

What is the actual reason to have a frequency and left and right footstep sounds defined in TERRAIN and not on player pawn?

I get a generic sound for footsteps, but left and right step sounds and frequency of steps is heavilly dependant on playerpawn definition you are using.
I wanna implement this for HeXen - each class have different speed and fighter have a armored metal boots. That means almost everything defined in TERRAIN is useless and have to done by hand on playerpawn. Not to mention possible morphs or implementing footsteps for enemies.

I would expect to have just a material, or a sound mask - something like "*METAL" similar to class sounds - and leave the step frequency for an PlayerPawn/actor definition.

Is there any deeper thought behind this decision?

[Enjay]

You might find this post (and the rest of the thread to a lesser extent) answers some of the questions: viewtopic.php?p=1261413#p1261413

Perhaps, most importantly, "Keep in mind that the stock MakeFootsteps() code is essentially a placeholder for mods."

I have modified the stock code slightly to stop it playing the splash sounds on water (because I have terrain "wading through water" sounds for those and generating splashes with every footstep as well makes it complete audio overkill (which is what I was concerned about in that thread).) I also didn't need the left/right sounds; a single sound type per terrain was fine for me.

The system has certainly been working well for me, but I'm using a player pawn that is quite close to the DoomGuy one, and I only have one type of player pawn. What you want to do is (obviously) more complex. I also wonder if morphed pig/chicken players might also be an issue for you?

Judging by the post I linked to, the intent seems to be "here's a system, it works, adapt it for your own needs if it doesn't suit you". Perhaps it might be possible to use the code base but add in a ZSCript check for which player class is active, and then play different sounds accordingly. That would be beyond my level of ZScripting, but it certainly seems like something that should be doable.

[neoworm]

What I was mainly complaining about is not the old properties added ages ago, but the new ones that have the same flaw in implementation as the old ones. Stuff that by all logic should be in player pawn is defined in TERRAIN. It doesn't even make sense to have different step distance defined per terrain, generally you dont change your step lenght depending on terrain unless that terrain is somehow difficult, which again would change the speed of player pawn and thus the logic should be handled there.

I can work around it, but it currently looks like another layer of bloat that in the end will still need another solution.

I would also appreciate some expanded support for splashes, because for a long time I would like to add an even bigger splash for explosions hitting water or really big enemies falling in water. That is something that should probably be handled by TERRAIN and not doing the detection in projectile/enemy which seems to be the only way currently.

[Enjay]

For me, what we have right now covers my needs: I only have one Doom-like player pawn and putting stuff in TERRAIN by building on the older is a convenient, and relatively easy way to do what I want. But, I guess that's the problem you're facing: it's a simple system built on to the existing TERRAIN stuff. To be fair, it seems like that's what it was intended to be.

I'm not saying "it works for me, so it doesn't need to be better"; simply that I'm lucky that (with a minor change - that took me far too long to figure out) I can use the system that exists to do exactly what I want, and I think I'm using it more-or-less in the way it was intended (i.e. as a base for my mod).

However, I totally see your points; particularly in a game where different player pawns are going to be used. There does, of course, need to be some way to define "this is a rocky surface and it makes a hard sound, this is gravel and it makes a crunchy sound, this is mud and it makes a squelchy sound" etc, and TERRAIN seems to be the logical place for that. Part of the consideration would also be the fact that some PlayerPawns will make different sounds depending on who/what they are - so that needs to be covered too, perhaps being able to add class identifiers to the sounds for a TERRAIN makes sense:

Code: Select all

terrain Whatever
{
...
StepSounds.fighter		floor/fighter/tile
StepSounds.cleric		floor/cleric/tile
StepSounds.mage			floor/mage/tile
}

Or something?

But, yep, speed/frequency of footsteps and so on make sense to be in the PlayerPawn. I never thought about it when I was doing my stuff (because it wasn't on my radar for what I was trying to achieve), but tying how fast footsteps are to the terrain definition does seem limiting - especially for a multi-class game, because all player classes, regardless of type, always make the same sounds with the same frequency. There's certainly a big difference between an armoured beast of a fighter stomping across the land in full plate mail versus a ninja-like player tip-toeing across the same ground in a pair of tabi. However, some kind of "this terrain has a multiplication factor of X" for slowing/speeding up footsteps might have some mileage?

All that being said, a lot of the handling is actually in the player definition. If you look in player.zs in GZDoom.pk3. That's where I found the code that I modified to remove the forced always splashing on liquid surfaces, and I added my modified code to my player definition to override the default. So, perhaps what you are looking for is tailor-able to your needs (or to be closer to your needs). Perhaps you could look at what is needed and put different, relevant code in each of your player pawns? I don't know enough about ZScrip handling to say whether that is workable or not.

Some of the really old footstep systems were essentially done in the player pawn using ye olde DECORATE definitions too. However, they were far more clunky/primitive than a proper ZScripted solution.

Anyway, I'm just musing to myself really, but the basic tools might already be there. A more advanced footstep system is not in GZDoom already, but it does seem like the kind of thing that might be doable via ZScript. Of course, it would be a reasonably involved task, and not for everyone (certainly not for someone with my limited ZScript skills), and I totally get that a system where you could add a few properties to the player pawn to easily access existing code would be far more modder-friendly, but - with a bit of work - something could be doable.

I also like the idea of being able to add bigger splashes, or actor/impact-type specific splashes. Again, it wouldn't surprise me if that was also doable via ZScript.

The more I think on this, the more it seems like it could probably be best as a "third party" footsteps library than something built-in to the engine release (like several libraries and "starter kits" that already exist for other things). The existing stock system fixes/enables what was there already and provides limited expansion (and that's all it was intended to do). Doing more seems like the territory of a bolt-on library mod to me. Of course, that would require someone with the time and skills to be willing to create one (as, indeed, would adding it to the engine).

But, like I said, that's all just me musing and carries no weight whatsoever.

[inkoalawetrust]

I am looking into implementing TERRAIN based footsteps and since the last time I looked there are another set of values for TERRAIN defs concerning step sounds and frequency. Effectively two separate ways to define frequency of sounds.

What is the actual reason to have a frequency and left and right footstep sounds defined in TERRAIN and not on player pawn?

I get a generic sound for footsteps, but left and right step sounds and frequency of steps is heavilly dependant on playerpawn definition you are using.
I wanna implement this for HeXen - each class have different speed and fighter have a armored metal boots. That means almost everything defined in TERRAIN is useless and have to done by hand on playerpawn. Not to mention possible morphs or implementing footsteps for enemies.

I would expect to have just a material, or a sound mask - something like "*METAL" similar to class sounds - and leave the step frequency for an PlayerPawn/actor definition.

Is there any deeper thought behind this decision?

Good question, I have no idea, you'd have to ask Marisa. The definitions for step intervals were there from before ZDoom even used Git (They might literally be older than me), they were just broken, same with the left and right footstep sounds. And yeah, this setup makes very little sense (Wtf, why is it terrain instead of speed dependant, are separate foot sounds really necessary?), maybe Heit was intending to add this as a feature in like 2004 and gave up almost immediately I guess? There is a CF_STEPLEFT "cheat" after all with this comment:

[RH] Play left footstep sound next time

I just went ahead about 15+ years later to fix the broken parsing, added a generic footstep sound type, and made the footstep virtual and flags. On my end the intention was basically to just have those crusty ancient unused TERRAIN properties actually do something out of the box (If you turn on the flag on the player pawn), and especially to just have a generic overridable virtual for footstep handling on players that can then be used to implement a system that makes sense.
I do plan to eventually PR a set of universal TERRAIN archetypes eventually™ though, like flesh, metal, etc. And then maybe I could also add a second special footstep mode that functions like how such a system probably should, by timing footsteps based on speed and maybe also playing generic sounds based on the TERRAIN type.