On Mon, May 16, 2011 at 6:49 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > If your answer is "No cheating is acceptable", then you have to do all > the computation on the server, nothing on the client, and to hell with > performance. All your client does is the user interface part. > > If the answer is, "Its a MUD, who's going to cheat???" then you don't > have to do anything. Trust your users. If the benefit from "cheating" is > small enough, and the number of cheaters low, who cares? You're not > running an on-line casino for real money.
The nearest I've seen to the latter is Dungeons and Dragons. People can cheat in a variety of ways, but since they're not playing *against* each other, cheating is rare. As to the former, though... the amount of computation that you can reliably offload to even a trusted client is low, so you don't lose much by doing it all on the server. The most computationally-intensive client-side work would be display graphics and such, and that's offloadable if and ONLY if there's no game-sensitive information hidden behind things. Otherwise someone could snoop the traffic-stream and find out what's behind that big nasty obstacle, or turn the obstacle transparent, or whatever... not safe. There's an old OS/2 game called Stellar Frontier that moves sprites around on the screen using clientside code, but if there's a bit of lag talking to the server, you see a ship suddenly yoinked to its new position when the client gets the latest location data. That's a fair compromise, I think; the client predicts where the ship "ought to be", and the server corrects it when it can. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list