Managing shots.

[polylux]

Hey community!

I am currently thinking of how to implement an efficient manager to basically handle all the bullets / rockets / missiles / bombs / (tbc) "flying" around, hit-testing, adjust health vals of the hit objects, ... guess you get the idea.
But before I start digging deeper I wanted to hear different approaches, what's common, do physics engines already offer something similar what I'm looking for, etc. - maybe YOU can tell me how you've done it? Just wanna make sure I don't work on something that's already available.

Thanks in advance & cheers,
p.

[Lonesome Ducky]

In most fps games, when a bullet is shot, instead of creating a bullet and continually updating a ray is just cast instantly and checked against triangles in models to check for hits. This is because often times bullets would skip right past a model because they move so far in one frame

[polylux]

Thanks for your reply, Lonesome Ducky!
The thing is, the classic approach would totally drop the need for deflection for distant, moving targets which is something I really want to have in my project. To cope with bullets slipping past a target I'd come up with this simple idea:

Code: Select all

1. remember time of last computation step (along with the bullet pos)
2. in the next comp step, carry along the bullet regarding to delta time last / now
3. use the old and the new pos of the bullet to construct a line
4. check for any collision

Moreover the instant hit-testing would even look worse with e.g. rockets.

[Brainsaw]

I've been thinking about adding somthing the way you described to my IrrODE wrapper. I made a "tank" demo where you can shoot bullets at targets, but the bullets need to be real slow to make sure they won't "beam" through the targets. As soon as I need something like that (not for my current game though) I will add that. The only thing is that the line for intersection testing is just an approximation, but it should be realistic enough. If you want a phyiscs simulation where you don't have to bother for that problem yourself you could take a look at trueaxis.

[polylux]

I guess with the idea posted above we won't have any slipping-through glitches.

[Insomniacp]

One thing that may make less calculations is to calculate the time for the bullet to a non moving object (simple raycast to get distance to object then you should have speed of bullet somewhere). If you remember each players bounding box you can move each char and get their new bounding box, by combining the two bounding boxes you can see which players the bullet has a chance to hit and then only do the actual testing on those players instead of all players.

Hmmm, you wanted rockets and stuff also...
I think for that you would need to do a check each time the scene updates. Have a class with currentPosition (if you don't mind straight bullets, so gravity won't pull them down) and then at each scene update calculate their newPosition and do an intersection test, since the time between scenes should be small the rocket will be visible and moving but the bullets will be very fast compared to rockets. If you update player positions before bullets this would prolly work best. Though in 1/24 of a second or less hopefully updating one or the other won't make much of a difference.

I know for some games they actually translate a virtual object in front of moving targets (or just calculate it on bullet fire) and then they do an instant raycast for that virtual object so if they are running you have to shoot in front of them to hit them. This way you eliminate the hundreds of calculations from a machine gun firing (which would be horrible to keep track of) and you still get semi realistic shooting.

Well those are my thoughts, I personally only do an instant raycast right now but that will change in later versions.

[polylux]

Thanks alot for that, that's really helpful. I especially like the approach with the virtual BB in front of the actual character to account for deflection. Downside is though, that it neglects the possibility that the char can change his direction while the shot is virtually "in flight" and could actually possibly miss the char.

Of course my approach is pretty costly but i guess as for rifle fire, a bullet's average "flight time" will only be fractions of a second, so not too many hit tests would be necessary if firing would be simulated every one or second loop.

[Insomniacp]

yeah, you can generally assume that a person won't change direction much in that fractions of a second though, they won't know the difference hahaha and won't have time to change direction since its an instant test. You will have to find a balance between realistic and efficient

[polylux]

You are absolutely right.
I guess it'd depend on a test. Another idea could be to treat e.g. rifle fire and slowly moving stuff (as RPGs, ...) separately.

[Insomniacp]

yeah, for rockets I would do the constant update since they are visible to the eye. A sniper round and pistol rounds you can't ever really see coming at you . Also there should be a lot less rockets and things like that flying around. would do them separate

[roelor]

You can do a sniper round in steps since it usually travels greater differences. just check collision for 20 metres per (3) frame(s).

[polylux]

Yeap that'd also be a big ease on the CPU load to compute this every couple of frames.

[polylux]

I have now fully implemented my idea and I'm pretty impressed with the results. Currently, the shots are simulated every frame and time measurements revealed that when a full magazine of 30 rounds is discharged, the time spent on the computation reaches 4ms max.