Damage over time of exposure

I’d like to apply a certain damage to a (2D) vehicle over time (of exposure) but I’m not entirely sure at the best way to do that.



For now everything works fine (for testing purpose) but damage is inflicted at every frame. No need to say that’s very lethal. :wink:



The damage applied is different on which environmental event it happens.



The gist of it is: the vehicle is driven in 2D over a quad while on the “map” environmental events happens. Lightning, acid rain, freezing rain, quakes, etc. Each type of event applies different amount of damage. The goal is to have each damage applied vs exposure.



Basically, for quakes, the damage is 2 * size (1-3) per second of exposure. I know I could use a timer and damage the vehicle at every second, but I’d rather use tpf and derive the damage from that at every frame.



Am I wrong thinking that’d be the best way to tackle this or should I simply use a timer, accruing damage over a 1 sec period then applying it?



Thanks. :smiley:

I’d rather use tpf and derive the damage from that at every frame.


2 * size (1-3) * tpf would calculate the damage per frame for quakes, then you can accumulate that if you want. If that's what your asking?
2 Likes

You know what? When I posted it that (damage * tpf) didn’t make sense. But then, it does.

2 Likes
@madjack said:
You know what? When I posted it that (damage * tpf) didn't make sense. But then, it does.


Just remember that your "units" are "damage per second" and the * tpf is fine.
@pspeed said:
Just remember that your "units" are "damage per second" and the * tpf is fine.


It's the dumbest thing I sometimes do of over-thinking things. I was thinking of calculating the given damage over a second, divide that by 60 then extrapolate the tpf to a second and... Well, you see where this is going.

It's an ailment I have of thinking that usually things are a whole lot more complex than they really are. ;)

In code simplicity is something to aim for.



I was working with a programmer last year and a lot of the time when I reviewed his code we’d end up stripping half of it out. He kept building these complicated houses of cards that just weren’t needed.

It’s something I’m trying very hard to stop doing, usually I’m ok, but sometimes–like the above–my brain goes into a spin. :confused:

Yeah but this is normal. Usually, you have multiple iterations for a piece of code until it runs as it should and has this “beauty” when you look at it :wink:

@madjack said:
It's the dumbest thing I sometimes do of over-thinking things. I was thinking of calculating the given damage over a second, divide that by 60 then extrapolate the tpf to a second and... Well, you see where this is going.

It's an ailment I have of thinking that usually things are a whole lot more complex than they really are. ;)


I did exactly the same thing on my end, and gave up multipying everything by tpf. Just as you said, it didn't make sense at the time, but afterwards it did. I wrote 3 methods to solve that for me, to change it for 4 lines.

In the end try to go back to multiplying the units:



http://i.imgur.com/a2BwM.png



(sorry for poor quality) :stuck_out_tongue:

@wezrule said:
In the end try to go back to multiplying the units:

http://i.imgur.com/a2BwM.png

(sorry for poor quality) :P


There is something wrong with your math because the final result is incorrect. The whole bottom part looks sketchy.

? theres nothing wrong with it

@wezrule said:
? theres nothing wrong with it


You're right... your terms are just a little weird.

tpf = time / frame... which is really: 1.0 / frameTime

So in the final thing where you show dmg / frame that's really dmg / frameTime which is the same as dmg * tpf.
2 Likes