4 ms·

>Keeping everything and all variables on the server is impossible, mainly due to lag the game would become unplayable, and due to having so many variables to ca

by feral 14y ago

>Keeping everything and all variables on the server is impossible, mainly due to lag the game would become unplayable, and due to having so many variables to calculate there is always something you have to trust the client with (position being the biggest one, you can't take all user input, send it to the server, and then send back where the character should now be). Why not just take the user input from the client, and send it both to the model of the world on the server, and also to a non-authoritative model of the world on the client? The client is then immediately responsive, as the client model of the world is what is rendered, but if the model of the world on the client diverges from the model of the world on the server, the server overrules it. This would ensure the client did not violate position rules, while still keeping it responsive, at the cost of an occasional noticable update when models get too far out of synch. As far as I know many games have done this, since Quakeworld. I might be wrong, my knowledge is a little rusty? Other issues remain that this doesn't solve (e.g. aimbot). EDIT - Here's a wiki article this: http://en.wikipedia.org/wiki/Client-side_prediction http://en.wikipedia.org/wiki/Client-side_prediction which links to this article describing client side prediction in Half Life (so you can presume there is something at least as sophisticated in Source): http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...

jiggy2011 14y ago
The approach you have suggested is actually very similar to what is used in the THQ game "Supreme Commander". In this case they use a fairly P2P architecture and have clients exchange hashes of the game graph every so often and check that they match. The problem with this is that the game needs to be fully deterministic and you'd be surprised how many games use random numbers to help determine outcomes like damage etc. This can also cause problems when you have complex physics models, many physics engines are not deterministic and small changes between the ways that different CPUs deal with floating point numbers can cause the game to generate a completely different hash.
- gms7777 14y ago
  It seems as though the problem with determinism could be solved with random number seeding. If the server generates seeds, the two could stay synced even with random numbers. The physics engine is a bit more difficult hurdle I suppose.
- feral 14y ago
  As gms7777 points out, for the RNG, surely you can just share seeds? Your comment about the differences in how CPUs deal with floats is very interesting. I found the following interesting comment, from a GPG employee, talking about how they take care to ensure their float math is deterministic: "I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor." http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p16480 http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p164...
  - ricree 14y ago
    Interesting link, feral. For anyone else reading, I'd also suggest reading some of the followup posts such as this one: http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&sid=f28239cd878276e8016d10817cfb9c42&start=10#p16662 http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&...
  - derleth 14y ago
    > floating point math is deterministic. This is news? Isn't this the entire point of the IEEE754 standard, to save us from the days when programs that were well-conditioned on a VAX would become numerically unstable on a Cray? 'Cray instability' sounds like a Star Trek episode but it is apparently something that could happen. http://www.jargon.net/jargonfile/c/crayinstability.html http://www.jargon.net/jargonfile/c/crayinstability.html
    - tedunangst 14y ago
      Depends on compiler options. x86 floating point is 80-bit internally, but 64-bit in memory. Compile the same function with different optimization, for a different CPU, or whatever and get different answers. For gcc, the answer is to use -ffloat-store. But you have to remember to use it.

by feral 14y ago

jiggy2011 14y ago

The approach you have suggested is actually very similar to what is used in the THQ game "Supreme Commander". In this case they use a fairly P2P architecture and have clients exchange hashes of the game graph every so often and check that they match. The problem with this is that the game needs to be fully deterministic and you'd be surprised how many games use random numbers to help determine outcomes like damage etc. This can also cause problems when you have complex physics models, many physics engines are not deterministic and small changes between the ways that different CPUs deal with floating point numbers can cause the game to generate a completely different hash.

gms7777 14y ago
It seems as though the problem with determinism could be solved with random number seeding. If the server generates seeds, the two could stay synced even with random numbers. The physics engine is a bit more difficult hurdle I suppose.
feral 14y ago
As gms7777 points out, for the RNG, surely you can just share seeds? Your comment about the differences in how CPUs deal with floats is very interesting. I found the following interesting comment, from a GPG employee, talking about how they take care to ensure their float math is deterministic: "I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor." http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p16480 http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p164...
- ricree 14y ago
  Interesting link, feral. For anyone else reading, I'd also suggest reading some of the followup posts such as this one: http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&sid=f28239cd878276e8016d10817cfb9c42&start=10#p16662 http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&...
- derleth 14y ago
  > floating point math is deterministic. This is news? Isn't this the entire point of the IEEE754 standard, to save us from the days when programs that were well-conditioned on a VAX would become numerically unstable on a Cray? 'Cray instability' sounds like a Star Trek episode but it is apparently something that could happen. http://www.jargon.net/jargonfile/c/crayinstability.html http://www.jargon.net/jargonfile/c/crayinstability.html
  - tedunangst 14y ago
    Depends on compiler options. x86 floating point is 80-bit internally, but 64-bit in memory. Compile the same function with different optimization, for a different CPU, or whatever and get different answers. For gcc, the answer is to use -ffloat-store. But you have to remember to use it.