3 ms·
Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the p
by mambodog 16y ago
Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the player are updated less frequently (to deal with the sheer volume of objects) but may still be visible to the player, client-side prediction comes in handy here.
Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out.
Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent).
Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might.
[1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop
[2] only for some weapons, a rare exception for the time
[3]http://en.wikipedia.org/wiki/Hitscan http://en.wikipedia.org/wiki/Hitscan
- waterhouse 16y agoCouldn't you synchronize the beginning states of the game on all computers (including their pseudo-random number generator states), and then the only data you'd need to pass around is user input (keypresses, mouse movements, and the exact times--at least down to the frame--at which they occurred)? Given the initial state, the PRNG data, and the user input, games are completely deterministic, aren't they? It seems that could pose a security risk to extremely savvy users (as the game state includes things they shouldn't be able to see, like the opponent's units in Starcraft, and one might be able to make a program to inspect the state of the running game client), but I can imagine encryption and obfuscation dealing with that sort of problem with very little overhead.
- mambodog 16y agoI guess this is one of those "in theory, theory and practice are the same, in practice, they are not" kind of things. I don't know of any triple-A game engine that works that way, and it's not for a lack of smart people working on it. I'm sure that could work for a sufficiently simple game engine, however.
- Retric 16y agoRTS often use that approach combined with check sums. They then resend world state when they don't match. However, FPS that use a little state prediction become much more complicated. Ideally, FPS would run two versions of the game world, what happened, and what the players see, with more information being sent about what happened close to the player helping the version that players see be more accurate. And continuous updating of the version players see based on predictions from the "real" version of the game world. But, getting that working would be extremely demanding and reduce the games ability to do physics in real time etc. PS: Game developers may be smart, but as a rule they have less experience than you might think. Short burn out cycles keep the industry from evolving.
- jerf 16y agoThe problem with your scheme is that to update frame X correctly, I have to have all input for frame X, which is now 200ms ago. Meanwhile, I need to be presenting something to the user now. Prediction is basically a way to deal with the fact that you can't do what you're describing. Also, don't underestimate your users. Encryption is irrelevant, they'll hack into your program's process space and read the stuff after you decrypt it, and obfuscation is at best problematic for the same reason. For a AAA-class game, assume all users have access to all data on the client at all times and you'll not be far wrong. Sort of how like in the encryption world we just assume that the attacker knows the algorithm already.
- enjalot 16y agonever trust the client. but let it do its thing and set it straight if it tries to stray.
- staunch 16y agoThanks for taking the time reply in such detail. Now I'm even more curious about the topic!