hit-scan versus simulated bullets

Started by
17 comments, last by liquiddark 16 years, 4 months ago
Quote:Original post by nordwindranger
I guess the biggest reason why I might not use realistic bullet simulation is simple performance issues. A german mg42 machine gun has a rate of fire of aproximately 1200 rpm. Thats 20 rounds being fired every second.

You can cheat here by combining every two or three of the rounds into one test and adjust the damage accordingly. The sound effects will sell it, and the realism is still all there.

Quote:I guess the difference between realistic bullets and hitscan bullets in that scenario is that the hitscan bullets only need to be tested for collision once, whereas the realistic bullets need to be checked for collision over the two seconds or so that they would have enough velocity to punch through some poor soldier.

It's usually harder on performance to check longer rays than shorter rays, so it doesn't really make a big difference. The longer the ray is, the more collision testing needs to be done, the harder the processor needs to work. Dividing that work over several frames is actually a good thing.
Advertisement
Quote:Original post by Kest
You can cheat here by combining every two or three of the rounds into one test and adjust the damage accordingly. The sound effects will sell it, and the realism is still all there.


This is generally a smart idea, but its one thing that I've decided to stay away from. The reason is that I am using realistic damage modeling ie: if you get hit with a 7.92mm round from a mg42 or a k98 you are going down hard. adjusting damage to simulate several bullets with only one wouldn't work because the target would probably be killed by the first one. This would make the other two (or whatever) bullets completely meaningless. If you model all three bullets you have three times the chance of getting the kill (assuming that they weren't fired in a perfect line).

Quote:Original post by Kest
It's usually harder on performance to check longer rays than shorter rays, so it doesn't really make a big difference. The longer the ray is, the more collision testing needs to be done, the harder the processor needs to work. Dividing that work over several frames is actually a good thing.


Hmmm good point. well I guess there's a good argument for going realistic vs straight hitscan

[Edited by - nordwindranger on December 1, 2007 6:08:48 PM]
Quote:Original post by nordwindranger Since the bullet travels so fast, it could intersect and then move through another model in one move increment. Of course I didn't think of hit-scanning along it's path, but if the bullets following a balisitic curve, wouldn't this be a big mess? (because rays are straight).


This is actually a negligible problem. Think about it: due to the bullet's speed, the slope of the trajectory will change very slowly. Any one section of the trajectory curve can be accurately represented by one or two straight lines.

Quote:Original post by nordwindranger I guess the biggest reason why I might not use realistic bullet simulation is simple performance issues. A german mg42 machine gun has a rate of fire of aproximately 1200 rpm. Thats 20 rounds being fired every second. Each round is traveling at aproximately 755 meters per second out of the barrel. So in one second of firing a MG42 would have to use 20 objects, and the game engine would have to do collision testing on 15,100 meters of space (755*20). I haven't tested it yet, but even if I was a lot better at coding than I am, I don't think that would be an efficient use of resources.


This is also not an issue. As Kest pointed out, some simple optimization (such as a grid system) will reduce the amount of collision tests dramatically. You don't need to check the bullet against every meter of empty space. You should compile a list of the closest objects and test against them.
Quote:Original post by nordwindranger
Quote:Original post by Kest
You can cheat here by combining every two or three of the rounds into one test and adjust the damage accordingly. The sound effects will sell it, and the realism is still all there.


This is generally a smart idea, but its one thing that I've decided to stay away from. The reason is that I am using realistic damage modeling ie: if you get hit with a 7.92mm round from a mg42 or a k98 you are going down hard. adjusting damage to simulate several bullets with only one wouldn't work because the target would probably be killed by the first one. This would make the other two (or whatever) bullets completely meaningless. If you model all three bullets you have three times the chance of getting the kill (assuming that they weren't fired in a perfect line).

If the bullets are being fired 50 milliseconds apart, what makes the difference? The chances of every two hitting the same object are extremely high.

Just because you test for collision using two or three projectiles as one doesn't mean you have to treat the impact effects and character reaction the same way. Think about it this way: If your player has a low framerate (30 FPS is about 33 milliseconds of time per frame), two bullets can actually hit at the exact same time anyway. So testing both at once can work the same as that situation, except you do only half of the work.

I test one bullet at a time in my project as well (don't combine them). But bullets can still be flying at a character from twenty different weapons, and any number of them can impact the character at the same time. The character can be "triggered" to be knocked down or killed by the second bullet, but five more could impact afterwards, all in the same frame. You just have to deal with those situations in a real-time simulation. Hit-scan won't make it any easier.
Quote:If I really wanted to, I could create a real-time shooter that sends data over email, and still achieve instant hits. It would be practically unplayable, but it would prove the concept.


At a certain point it would stop being a computer game and start being a thought experiment. I'm with wikipedia on this one. The pedant in me agrees with you, but I've written enough real-time and near-real-time systems (2 or 3, depending on how you count) to believe that for all practical purposes, if the real time isn't there then the system effectively ceases to be what it originally was. In pretty much every case, "instant" is an impossibility if networks are involved.
No Excuses
Quote:Original post by liquiddark
Quote:If I really wanted to, I could create a real-time shooter that sends data over email, and still achieve instant hits. It would be practically unplayable, but it would prove the concept.


At a certain point it would stop being a computer game and start being a thought experiment. I'm with wikipedia on this one. The pedant in me agrees with you, but I've written enough real-time and near-real-time systems (2 or 3, depending on how you count) to believe that for all practical purposes, if the real time isn't there then the system effectively ceases to be what it originally was. In pretty much every case, "instant" is an impossibility if networks are involved.

I'm just trying to make it easier to understand. You could stop all time-relative processes for a single frame while an instant weapon is fired, and no one would even know what happened. That proves the statement is wrong.

You actually don't need to stop all time relative processes. By simply processing the projectile in a single frame, whether on one computer or after information is sent to another, no other physics on that computer has time to react between the time it is fired and the time it hits the target. By no time, I mean zero, not 0.00001. That means that relative to the simulation itself, the projectile is instant, regardless of what perspective you use.
Quote:Original post by Kest
You actually don't need to stop all time relative processes. By simply processing the projectile in a single frame, whether on one computer or after information is sent to another, no other physics on that computer has time to react between the time it is fired and the time it hits the target. By no time, I mean zero, not 0.00001. That means that relative to the simulation itself, the projectile is instant, regardless of what perspective you use.


I don't think you're getting it.

50 ms after you process it on Client A, the packet describing the firing gets to client B. Client B then has to figure out the meaning of receiving that packet. Its timer is inherently desynchronized to client A, so it can't simply take the timestamp on the packet and use it to retroactively apply the end result. The simulation is 50 ms further on on client B, so the hit has a different effect on that client. The effects have to be manually synchronized.

It's a well-known problem in network physics. Being pedantic about the possibility of doing the simulation correctly while ignoring the basic problem that it doesn't happen that way in any real-time game seems to me to be a little foolish.
No Excuses
Quote:Original post by liquiddark
It's a well-known problem in network physics. Being pedantic about the possibility of doing the simulation correctly while ignoring the basic problem that it doesn't happen that way in any real-time game seems to me to be a little foolish.

It's pedantic to claim that simulated instant projectiles are not instant in the first place. How can an argument against the claim be anything else?

Let's just scale the problem up to make it more obvious. What if the latency was extremely bad? If it took 1 second to send the packet, can characters being controlled on another computer move out of the way of the instant projectile? Can AI on any of the computers see the projectile and move out of its path?

Network lag should be handled in a way that simulates a delay in event recognition. Not a delay in the actual events. So if it takes 1 second of time to send an instant hit, then the recieving computer's character just needs to realize they were shot 1 second ago.
Quote:Original post by Kest
Network lag should be handled in a way that simulates a delay in event recognition. Not a delay in the actual events. So if it takes 1 second of time to send an instant hit, then the recieving computer's character just needs to realize they were shot 1 second ago.


I agree that this is one way to handle it. It is at best difficult to accomplish, since the packet itself doesn't know how long it took to travel. Nonetheless, assuming you overcome that problem, from the pedant's point of view, that is sufficient to say the hit is instantaneous

What does it mean, however, for a simulation to enact past events in the present moment? I mean, I played Quake 1 multiplayer, and that's basically how things worked, but it was completely unrecognizable as a simulation because of it.

You're talking about the internal representation of events, but those are utterly meaningless without some perception of them, and that perception is inherently desynchronized, unless you have some way to simulate things ahead of time. Some FPS engines have even attempted this, though not, to my understanding, to any significant gain.

Let's continue your example: Assume player A sees player B at position C. Assume they both have the same time listed, but there is a 1 second delay in receiving communication over the network. Assume at time t player B changes his direction of movement by 90 degrees. Player A shoots at time t + 0.5. In her mind, she is shooting directly at player B. The turn arrives at time t+1. Player B teleports to his "true" (off-by-one-second) location on A's screen, and A realizes she has not hit her target. Player B doesn't realize the shot has occurred until time t + 1.5, by which time he probably has less than a second to dodge A's next shot.

The above scenario is why most weapons in a networked shooter are spread-effect weapons, and also a big part of why the point-effect weapons tend to be so much better per-shot. There is this spread-out notion of where someone is, what is happening, and what the net effect was. It isn't meaningful to say that something happens instantaneously because of that spread-out effect. If you rely too heavily on truly instantaneous effects, your game falls apart. The key balance is between making things playable and making the physical simulation relatively true to each person's perception of events - it would not do to have player B dead on player A's computer but not on his own.

No Excuses

This topic is closed to new replies.

Advertisement