hitbox support by utilizing methods similar to brightmaps

[kevansevans]

So was discussing how hitboxes were accomplished in the /r/Doom discord and some of us theorized an idea of how hitboxes could be added without the hacky way of checking angle and position, or spawning actors every single frame.

So similar to brightmaps, one could simply draw out the hitbox they wanted like so: https://imgur.com/a/KOseq
Then within say the actors zscript file or it's own lump, the syntax would be something like this:

Code: Select all

Hitbox "right_arm_bullet" {
    painType = "bullet"
    painFactor = 1;
    damageFactor = 0.9;
    frame AAAA0 = HITBOX0;
    frame AAAA1 = HITBOX1;
    frame AAAA2 = HITBOX2;
    frame AAAB0 = HITBOX3;
    frame AAAB1 = HITBOX4;
    frame AAAB2 = HITBOX5;
}

I hope the pseudo code I put out is pretty self explanatory, the only flag I think needs an explanation is the pain one. It's pretty much a self contained custom damage type, so if the actor has a pain.bullet or death.bullet state set, it would tell the actor to jump to that state.

[Graf Zahl]

That cannot and will never work with how the game physics are implemented.

[kevansevans]

Graf if I may argue this for a moment, I think this is possible through what I've observed the engine can do already. I'll drop it after this if you're still firm it can't be done.

First thing I know is that an XYZ position has to be derived to spawn blood and bullet puffs, that means we have a position to use and compare. If we take this position, and apply some math of the angle of where the damage would spawn of said blood/puff to source/direction (source for hit scans, direction for projectiles), and compare it to the angle of the actor that it's facing. This would give us the sprites assigned "hitmap" we would need to compare the position to, and just perform a basic "is this pixel black or white" based on the mentioned XYZ position. This would also mean that for a hitbox to be defined without any issues, all sprite rotations must be defined per box. If the pixel returns false (black), then you could easily use the same function that passes hitscans and projectiles through silent-teleporter-portals, or even for projectiles, temporarily make it noclip through enemies. If the pixel returns true (white) then it would obviously inflict damage.

[Nash]

Then what happens when one player has a differently-loaded "hitboxmap" than other players? Desync hell! I doubt the playsim even knows or keeps track of anything about textures.

[Rachael]

Nash is right, and I will go a step further to say that you absolutely cannot, under any circumstances, use highly subjective render data for game sim decisions. This includes sprite data.

There's one person on this forum who's been arguing with me tooth and nail about this, but he doesn't give a flying fuck about GZDoom's multiplayer (even when it's proven that people do use it) and seems to think everyone should use Zandronum for that, instead. Well - GZDoom has had supported multiplayer since its very first version and while it's had its issues along the way there's no reason to stop now.

[Graf Zahl]

Even disregarding the multiplayer issue it's not that simple. It *may* be doable for hitscans but there's absolutely no way to do it for projectiles which are just regular actors. And good luck with your headshot capable actor which reacts just normally to non-hitscan weaponry. But this renders the entire feature useless.

And that doesn't even consider having to implement hashes for texture content and what not to ensure that in a multiplayer game or demo everybody uses the same assets.

[kevansevans]

I don't know when the last time you guys played zandronum was, but it has a really good enforcer to make sure people use the same assets, as far as I've noticed. Little concerning GZDoom doesn't have this at a minimum by the way you guys make it sound like.

Anyways if it's just flat out difficult on the technical side of things, I'll leave it now

[Rachael]

It's not as much "difficult" as it is "flat out undesirable".

In other words, the engine should not operate this way, and even if you filed a pull request adding full support for it, it would be denied on the grounds that it simply opens a can of worms for problems, and basically just flat out "we don't want it."

This goes way beyond the scope of what a Doom engine should be doing.

[Nash]

A more realistic implementation for this kind of thing (meaning, the chances of it being considered are better, provided someone wants to go through the hard work of actually doing it!) is perhaps some kind of collision mesh system. I mean it would be a crapton of work, and I have no idea how it would work with sprite-based animation (perhaps the collision mesh could be vertex-animated to match sprite frames, not unlike what MODELDEF is doing with its mapping sprite : vertex frame stuff)... but that at least makes more sense from a technical POV, rather than using billboards, which to be honest would only work in 2D games.

Til then, it's not like this idea is 100% impossible. You're still able to setup dummy actors to act as locational damage boxes (while I know hacks are frowned upon, this is literally the only way available with whatever tools you have available with you without massive engine work that no one is willing to invest time into), or if you don't like spawning extra objects to act as collision markers, I guess you can calculate where the blood splat or the projectile is relative to the victim...

[kevansevans]

Maybe instead of using sprites, it can just use a class that just accepts a width, height, and depth, and XYZ positions? I still think the idea that it can be reduced into more of a lump like definition instead of spawning something every frame and cluttering the code up is a very viable idea.

[Nash]

instead of spawning something every frame and cluttering the code up is a very viable idea.

Spawning something every frame? What is this, the ice age? :P The collider would be spawned only once, storing its "spawner" in a pointer. ZScript lets you do this stuff conveniently. Yeah, sure the actor count would go up, but you don't have to spawn something every frame is my point.