hit-scan versus simulated bullets
Author
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.
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.
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)
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.
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:
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.
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.
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.
Quote:Original post by shurcoolQuote: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.
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... :)
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.
Author
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
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
Quote:Original post by liquiddarkQuote: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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement