Jump to content

  • Log In with Google      Sign In   
  • Create Account


hit-scan versus simulated bullets


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 nordwindranger   GDNet+   -  Reputation: 168

Like
0Likes
Like

Posted 30 November 2007 - 02:48 PM

I'm fleshing out the design work for my current project: a third person tactical game. most of the action will be centered around ww2 tank combat, although there will be a lot of infantry combat. The player is just an individual rather than a rts style commander. This means that the majority of the fighting is going to be done by the ai (as the player is just one person in a big war). Since I'm interested in working on realistic ww2 armor simulation, any gun larger than a machine gun will fire "real" shells with physics and the whole deal. What I'm trying to decided is if its worth making all the guns fire "realistic" bullets (like in the game Red Orchestra), or if I should just use hit scanning (HL2, counter-strike). Since the game is going to be third person, you can't really look through the gun sites or anything. I plan on modeling simple bullet penetration for all objects (in other words wood crates no longer make good cover), but I don't see any particular difficulties in doing this with hit-scan bullets. There is of course the very real problem of doing collision detection with bullets that travel at upwards of 800 meters per second. but we can ignore that for this debate if you want. I know there are a lot of people out there who don't like hit-scanning, so I challenge you nay-sayers to convince me why realistic bullet modeling is worthwhile.

Sponsor:

#2 JasRonq   Members   -  Reputation: 156

Like
0Likes
Like

Posted 30 November 2007 - 03:51 PM

In third person you cant lead a target so hit scan is better there. Even if it were first person, if the maps are small enough, hit scan is still fine. its only when there are large maps that it makes a difference.

#3 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
0Likes
Like

Posted 30 November 2007 - 04:08 PM

Quote:
Original post by JasRonq
In third person you cant lead a target so hit scan is better there.

That depends how the 3rd person is setup. If it provides a cross-hair and accurate fire from the muzzle to the cross-hair, I don't see a real problem with leading.

I have never been fond of hitscan weapons, especially if the maps start to grow, as the instantaneous hits on moving targets just don't *feel* right.
(also interesting to note that Wikipedia has a nice entry)

#4 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 30 November 2007 - 05:10 PM

I say go for the real deal. There's no reason not to. It would be harder to fake it well than to actually do it.

You can divide your world up into a grid, then do ray-cast optimizations that allow you to only check for collisions against objects in specific cells of that grid. If done well, each bullet would only need to check against a maximum of one or two objects per update.

You can also bend the rules to further increase performance. For example, after a bullet checks collision against one object, store its remaining time in a buffer and make it wait until the next frame passes before it can move again. You can also cut bullet velocity down below realistic speeds to reduce the length of ray cast tests. Still more realistic than hit-scans.

Quote:
Original post by JasRonq
In third person you cant lead a target so hit scan is better there.

Auto-targetting. Leading is still a tactical issue, because a target can make itself very difficult to hit with unpredictable movement and zigzagging.

I can't believe how lame this Wiki-entry is:
Quote:
Original post by Wikipedia
This is actually faster than a hitscan shot in computer games, since a computer can not process all necessary commands as fast as light travels from one point to another. The time which a packet takes to travel from one computer (called latency, but informally referred to as 'lag') to another also makes a real instant hit in computer games impossible.

What a load! Games process their own relative game-world time. If objects like characters and physics are modeled with a timer, then simply processing a projectile in one frame without changing that timer would be instant travel.

#5 shurcool   Members   -  Reputation: 439

Like
0Likes
Like

Posted 30 November 2007 - 06:01 PM

Quote:
Original post by Kest
I can't believe how lame this Wiki-entry is:
Quote:
Original post by Wikipedia
This is actually faster than a hitscan shot in computer games, since a computer can not process all necessary commands as fast as light travels from one point to another. The time which a packet takes to travel from one computer (called latency, but informally referred to as 'lag') to another also makes a real instant hit in computer games impossible.

What a load! Games process their own relative game-world time. If objects like characters and physics are modeled with a timer, then simply processing a projectile in one frame without changing that timer would be instant travel.

I'd have to agree with the Wiki entry on this, even though there's really no difference as it's so quick anyway.

But if you really wanna get picky, I'm sure it takes light less time to travel a few hundred meters than it does your computer to execute two consecutive calls to getTime() or some such.

#6 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 30 November 2007 - 09:35 PM

Quote:
Original post by shurcool
Quote:
Original post by Kest
I can't believe how lame this Wiki-entry is:
Quote:
Original post by Wikipedia
This is actually faster than a hitscan shot in computer games, since a computer can not process all necessary commands as fast as light travels from one point to another. The time which a packet takes to travel from one computer (called latency, but informally referred to as 'lag') to another also makes a real instant hit in computer games impossible.

What a load! Games process their own relative game-world time. If objects like characters and physics are modeled with a timer, then simply processing a projectile in one frame without changing that timer would be instant travel.

I'd have to agree with the Wiki entry on this, even though there's really no difference as it's so quick anyway.

But if you really wanna get picky, I'm sure it takes light less time to travel a few hundred meters than it does your computer to execute two consecutive calls to getTime() or some such.

Let me say this clearly. Within a simulation, you can make anything travel instantly. Even if it takes the computer five months to process the data that makes a projectile travel from point A to B, the time laps in the simulation can still be zero. The characters and other moving objects have zero time to move or otherwise react to the projectile. It is instant.

#7 liquiddark   Members   -  Reputation: 316

Like
0Likes
Like

Posted 01 December 2007 - 06:06 AM

Quote:
Original post by Kest
Let me say this clearly. Within a simulation, you can make anything travel instantly.

Assuming, of course, that you have a single timer with perfect authority, and that your own measurements are sync'd to that timer.

In a network situation, that isn't the case. There are at least 2, often 3, timers involved:

1. your client
2. the remote client
(optionally)3. The (usually authoritative) server timer.

Unless you're doing turn-based combat with sub-second resolution of turns (which seems to me to be an edge case), you have to find ad-hoc ways to make those three match up most of the time, and the answer to that sacrifices any absolute notion of "instantaneous" in return for allowing the game to resolve itself in realtime.



On a different note, light travels a few hundred meters in a microsecond (300m/300,000,000 m/s = 1/1,000,000 s = 1 microsecond). This is long enough to process lots and lots of instructions in a modern processor. If you're gonna get nitpicky... :)

#8 liquiddark   Members   -  Reputation: 316

Like
0Likes
Like

Posted 01 December 2007 - 06:17 AM

Quote:
Original post by nordwindranger
There is of course the very real problem of doing collision detection with bullets that travel at upwards of 800 meters per second. but we can ignore that for this debate if you want.


Not sure why this would be a large issue. After a certain point you extrude bounding volumes through space or use a simple hitscan-style test, but parameterize it so you can deal with a line segment rather than a ray. I guess if you're doing enough of these calculations you can saturate the processor. Do enough hit scans and the same will be true. Lots of ways to batch up operations to avoid the need for extra scans if you're desperate for speed.

I don't think there's any real point in using realistic bullet models, all the same. In almost any circumstance, the tricks that you can play to simulate the net effect are going to be just as effective at the scale on which it's going to matter to the player.

Having said that, you're doing tank simulation, and my understanding is that armchair generals are a funny bunch, so maybe you should think of an investment in realistic bullet modeling as a bone to the "hardcore" audience.

#9 nordwindranger   GDNet+   -  Reputation: 168

Like
0Likes
Like

Posted 01 December 2007 - 09:38 AM

wow this post is really flying :) if i didn't just waste 10 hours working at a gas station, I would have replyed earlier.

when I mentioned that doing collision on realistic bullets would be difficult, I was thinking of simple bounding box intersection tests. 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). I admit that I'm completely new to using hit scanning. In the past I've always done simple interection collision.

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.

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.

but I might be wrong on that, because I'm rather new to this debate.

p.s. to reiterate from the original post, I will be using realistic projectiles for all of the guns that are bigger than machine guns (because there aren't as many of them, and they fire a lot slower, so performance isn't an issue).

thanks for all of interesting posts so far

#10 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 01 December 2007 - 10:10 AM

Quote:
Original post by liquiddark
Quote:
Original post by Kest
Let me say this clearly. Within a simulation, you can make anything travel instantly.

Assuming, of course, that you have a single timer with perfect authority, and that your own measurements are sync'd to that timer.

If your simulation is built to make it happen, it can happen. Even if implementing real instant hits correctly causes the game itself to become less fun or annoying, it throws the "real instant hit in computer games impossible" line out of the window. They just didn't know what they were talking about.

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.

#11 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 01 December 2007 - 10:33 AM

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.

#12 nordwindranger   GDNet+   -  Reputation: 168

Like
0Likes
Like

Posted 01 December 2007 - 11:08 AM

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]

#13 et1337   Members   -  Reputation: 1363

Like
0Likes
Like

Posted 01 December 2007 - 12:47 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.

#14 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 01 December 2007 - 01:17 PM

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.

#15 liquiddark   Members   -  Reputation: 316

Like
0Likes
Like

Posted 01 December 2007 - 02:10 PM

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.

#16 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 01 December 2007 - 04:34 PM

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.

#17 liquiddark   Members   -  Reputation: 316

Like
0Likes
Like

Posted 01 December 2007 - 05:35 PM

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.

#18 Kest   Members   -  Reputation: 547

Like
0Likes
Like

Posted 01 December 2007 - 07:56 PM

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.

#19 liquiddark   Members   -  Reputation: 316

Like
0Likes
Like

Posted 02 December 2007 - 10:29 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS