Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • 0
hardcore_gamer

A question about 3D enemies and hitboxes

Question

So one of the advantages of using 3D enemies in games instead of sprites is that you can use hitboxes for specific body parts. Gzdoom supports MD3 model enemies, so is it possible to take advantage of this? Would it be possible for example to give the arms their own hitboxes and then have those hitboxes turn 90 degrees if the enemy itself does so?

 

How do hitboxes work for 3D enemies differently than they do for sprites if they do at all that is?

Share this post


Link to post

4 answers to this question

Recommended Posts

  • 0
Posted (edited)

Graphics are completely independant on physics. Appearing as a sprite or a model doesn't change anything related to physics, such as how hitboxes work.

Share this post


Link to post
  • 0

Ok, but is it still possible to do some kind of trick like Brutal Doom where you have each enemy spawn an extra actor that you can't see at different heights/angles that have their own hitboxes? Something like this:

 

ygstkQ0.png

This is how Brutal Doom did it right? The thing is though I have no idea exactly how this was implemented. All I know from what I can gather is that in Brutal Doom each monster supposedly consists of more than 1 actor, with the other actors being basically "fake monsters" that spawn at specific locations around the parent actor/monster but have no actual sprites, and yet can still be killed by damaged thus playing a specific death animation.

 

Or at least I think that is how it works. I would be extremely interested in understanding this process better and then hopefully find some way to implement it for my 3D models.

Share this post


Link to post
  • 0

Through use of ZScript, it should be pretty simple to have a single hitbox be the "primary" actor, which then creates the rest of the "secondary" actors through an PostBeginPlay() override and maintains their position in its own Tick() override - you'd want to do it that way specifically as otherwise you run the risk of desyncing some hitboxes by a tic.

 

Furthermore, proper locational damage multipliers would be a lot easier than in Decorate, as the secondary actors could override DamageMobj() to intercept the damage dealt to them, then deal it altered to the primary actor.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×