obviscating python code for distribution

[Ian Kelly]

On Mon, May 16, 2011 at 12:17 AM, Littlefield, Tyler
<tyler at tysdomain.com> wrote:
>>Write your "game" for the "web".
>>Write is as a SaaS (Software as a Service) - even if it's free and open
>> source.
> I understood you loud and clear. And that makes a lot of assumptions on my
> game and the design. I don't really care to host this over the web. I want a
> centralized server that would perform the logic, where I can offload the
> playing of sounds (through a soundpack that's already installed) to the
> client-side.
> Not only that, but a lot of web technologies that would be used for this
> wouldn't really work, as I am doing this for the blind; Flash as well as a
> lot
> of the popular setups are not very accessible.

Probably the best thing you can do is just to treat your client as
untrusted.  That means:

1) Avoid sending it any data that you would not want the user to have.
 If they want it, they'll find a way to get it.

2) Don't rely on the client to restrict the user.  If they're not
supposed to be able to send a command 10 times a second, that should
be enforced by the server.

If the client has no useful data beyond what is normally presented to
the user, and if every input that the server will accept can be done
with the vanilla client, then there is no way to cheat, and the only
reason remaining to hack up the client that could be detrimental to
gameplay is for botting.  For that, I'm afraid you'll just have to
employ detection algorithms and enforce a strict no-botting policy.

Cheers,
Ian