Need help designing fire damage

I’m kind of hung up on how to handle fire damage in my fps and the flame thrower is really crucial to the game mechanics, so I really want to make sure and get it right.

My current idea is that I am going to make a stream of sphere colliders with a smaller sphere that determines if it hits a wall and kills the shot.

This means that it can creep around corners if the center misses the wall and that seems on par for a flame thrower.

I will likely use an animation curve to determine the damage sphere size and damage over life.

And I will also likely have it do damage every frame it is touching an enemy.

Then of course have it apply an engulf value that creates damages over time after you stop hitting them.

The crux is armor.

How much do you feel that armor should protect from fire?

And since it will not be a one and done damage how can I tweak it so that it does damage accordingly?

Im thinking I want the engulf value to only account for armor at the point of applying damage. So that armor will slow the application of engulf, but once on it ignore armor from then on out.

And I’m thinking I want an animation curve to multiply the engulf for how much the target already has and make it a bell curve. So if an enemy has zero engulf it takes little from damage. Then goes up the more engulf it has. But starts to curve off after a point.

As for how to account for armor I’m at a loss.

Maybe just do each frame accounting for armor and just tweak pen until I like the results?

Im sorry if this is a little heady and hard to picture, but I welcome all input.

If nothing else, would you expect armor to have a huge effect on stopping fire?

Also, would you have the damage sphere count as a hit on all limbs it hits? If a sphere hits the chest, biceps, and neck would you just count that as three separate hits?

There is a shocking lack of content out there in what makes a good flame thrower.

EDIT: Oh, and I should mention that my game will allow players to move crazy fast. I did the math and I’m looking at going about a third the speed of sound under the right conditions, lol. Needless to say the player will very likely be able to hit themselves with the flame thrower if they shoot while moving fast. Should I make that a feature? Like using the lightning gun in water in quake? Maybe take on that risk as a factor during balancing?

 

I wouldn't use frames. I'd use an explicitly controlled timer, so that it doesn't become frame rate dependent.

No. Unless there's specific reason to do otherwise, e.g. the armor is specifically said to protect from fire, or e.g. other types of damage also have bespoke handling, I'd have the damage work just as every other type of damage does.

Is this because the projectiles have high drag values? Presumably the projectiles should inherit initial velocity from whatever launches them, so unless they slow down after they're launched the player shouldn't be able to hit them.

 

True, and that is a mechanic I have. Projectiles inherit forward motion and increase damage relative to that value.

But I really want the flame thrower to be dangerous to use so that I can over power it, but demand the player to not run with it.

I have a shotgun if players want to run and gun.

This is one way I want the weapons to be orthogonal.

 

Also, I had the same thought about frames, but to be honest I don’t know the first thing about making my own time cycle that’s independent from the updates.

Any links on that?

 

Any reason in particular doing it in update() while also scaling it with Time.deltaTime wouldn't work?

I agree a timer would be better because you could use it to do things like timeslice the fire damage ticks so that they don't all get calculated at the same time, or trigger vfx and sfx on the damage timer tick which wouldn't make sense doing every frame.

Maybe the flamethrower could have strong pushback and a minimum firing duration for the shortest possible burst so that you have to commit to the action and either the burst slows you down when you shoot forwards or you do a 180 mid flight and us it to boost your speed?

I'd make some enemies weak to fire, so that they take double damage from it, to create an incentive to use it over the shotgun or other weapons.

I'm not 100% sold on the fire harming yourself idea because it might lead to people simply not using it or thinking it is a bug.

 

That’s a good point as about people thinking it’s a bug and finding it annoying.

I suppose I could slow the player while shooting just as easy.

And I kind of already have a commit feature like you said, in that the engulf is applied on a bell curve.

As for a vulnerable enemy I am specifically centering a large part of the game around this already.

I have an enemy type that only has 1 hp and come at you in the thousands.

It is going to be the big jaw dropper in my teaser.

And the idea is that there will be chunks of the map that are nearly impossible to get through without the flame thrower.

So you can see why it is so important to get it right.

 

Hope you enjoy performance optimization

I expect that to be tricky to tweak it to achieve that stated goal without something else breaking balancing wise. I would recommend either trying this out early or having a plan B, just in case it doesn't work out.

 

All tested already. It’s the first enemy I made and I can currently do 2k of them before my potato of a laptop starts to cook.

When I got it working I told my wife “we are going to be rich” she asked why, then I pressed play and she simply said “we are going to be rich”

you’d be surprised how light you can make an enemy on the cpu when it’s just a simple collider with an ai script less than 25 lines long.

I do want to try doing dots with it and see if I can do 10k.

If I could get 10k enemies on the screen coming at the player I’d be printing money.

 

It'll work, it'll just be less predictable / consistent unless the frame rate is super consistent, which is something I don't assume. In practice the difference may be negligible or irrelevant.

Keep in mind also that scaling things by time usually involves dividing numbers by 30 or 60. If the health system is based on integers that will probably involve accumulating values over multiple frames so that they don't get truncated. So then there's the question of whether you'd rather manage that, or just have it work in controlled time slices in the first place?

Particles and/or instanced rendering, no sweat.

 

You can probably get 5 to 10 times more if you can avoid making them GameObjects. It doesn't necessarily have to be DOTS, though I'd certainly give the off-the-shelf solution a go.

Even without DOTS, instead of individual GOs it can be one GO for the group with a list of transform matrices for each enemy (and whatever other variables they need). Each frame, run a loop that updates the behaviour of each instance, then use the matrices for a DrawMeshInstanced call.

The catch there is that you don't get any collision that way. One solution to that, in my experience, is to use a pathfinding system that avoids the need for collision detection.

 

A super easy way would be to put it in FixedUpdate, as the physics system already runs at a fixed time step, and that will be synchronised with other moving things.

You can then specify 1) how much damage to deal and 2) how many ticks between dealing damage, and then it's all simple integer math. E.g. deal 3hp damage every 5 ticks (which will be 30 DPS at the default 50hz phsyics tick rate), and that damage will be consistently spaced out in both space and time.

 

Right on.

Im worried about stressing my fixedupdate, but I will give it a try.

Thanks once again, always a big help!

 

Oh, I forgot to say... the pathfinding solution only does half of collision detection. The other half is detecting hits, for which you'd want some kind of spatial lookup.

 

I don’t want to spill the beans on that enemy yet, but it has no problem at all finding the player as is.

I threw dooms e1m1 in and dropped 1000 of them and they easily followed me around to every inch of the map.

But if they got hold of me they knocked me right through the wall, which I’m sure you remember me talking about. (Unfortunately the problem was the mesh from Doom Builder and I can’t fix it which has wrecked my workflow for level design. And I’m wondering if I should get a level designer on board, but that’s often more of a headache than it’s worth).

 

What's wrong with the unfixable thing?

 

The walls are not connected to the floors and ceilings, and the vertices don’t line up so I can merge them.

I really need to find a better workflow if I’m ever going to make 10 hours of content.

 

Do you gave a thread about that issue?

 

Instead of sphere collider, I will use spherecast

 

Seems unnecessary when I’m doing it every frame regardless.