Re: Game idea....

[Michael Day <mikeday@corplink.com.au>]

> In a normal client server setup, the protocol and state at the server is
> the only thing that really matters. Here, the problem is that information
> that can be obtained from combining other information can be considering
> cheating. For most other client server app I can think of, this would
> simply not matter. (Not very clear - I hope you understand what I mean).
> 
> It nags me a lot.

Yes, this is true. But if you look closely at the problem in Quake, it is
because the game *must* be efficient, and sacrifices a lot for that. For
instance, you know what the entire level looks like before you have even
been around it, as levels are loaded client side. The ultimate and final
way to fix this problem is basically put *everything* on the server, not
just the physics. Consider you have a connection of massive bandwidth.
All input data the user generates is sent to the server, which sends back
graphical frames for the client to display. Now obviously this is
impractical and crazy, and bandwidth would be huge and the server load
would be unsustainable. But it demonstrates that there is a potential
solution, it's not *impossible*.

A more practical method is just to send only the data the client needs,
and try to be as smart at working out what it will need as possible. For
instance in Quake you can hack yourself 360 degree vision, as you are sent
to much information, for speed purposes. However as Christian points out,
Quake is a very specific example in which you want everyone seeing
*exactly* the same thing and being judged on the same reaction and aiming
abilities. As everyone will have different mice, video cards, lag, this is
already not going to happen :)

Michael