obviscating python code for distribution

Chris Angelico rosuav at gmail.com
Mon May 16 05:10:20 EDT 2011


On Mon, May 16, 2011 at 6:49 PM, Steven D'Aprano
<steve+comp.lang.python at 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



More information about the Python-list mailing list