>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).
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.
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."
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.
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.
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.
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 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/game...