Python newbie

[Amit Patel]

 John Ratcliff <jratcliff at worldnet.att.net> wrote:
| 
| My goal is that I will have a core engine on the client and on the server
| side.  The basic game logic should all be written in some kind of general
| purpose scripting langauge which can be modified to invoke any of my native
| methods as if they were extensions to the language itself.  My reasons for
| this are primarily as follows:
| 
| (3) Game content is not static.  In a multiplayer environment this is
| absolutely critical.  If you buy a single player game and it provides a
| certain amount of content for your money, that's just fine.  But, in a
| pay-for-play multliplayer game, players demand and expect a constant flow of
| new content.  Moreover, game balance must constantly be monitored and
| changed as a game world evolves in an online environment shaped by hundreds
| of thousands of people.
| 
| Having all of the game logic represented as compiled byte code means you can
| easily download and patch the gaming system, even as it's running, on
| demand.   While it is true that ultimately you could simply download new
| pieces of game logic as compiled code, as either DLL's or simply patches to
| an executable, this doesn't work very well when your product targets
| multiple processors and operating systems.

Hi John,

I've been thinking about scripting languages for games as well, and
one of the issues that you may need to be careful about is the
potential for users to patch the gaming system themselves.  Being able
to download game logic is a great idea, but in a multiplayer game
there's some incentive for highly motivated individuals to change the
local rules on their client and affect the server in some way.  (I had
to deal with a lot of cheating in multiplayer BBS games I worked on.)
With Python bytecode, it's even easier because users can get their
hands on the bytecode format without spending time reverse
engineering.  What I ended up designing (but never implementing, alas)
was client-side code for interacting with the player -- bringing up
dialog boxes, displaying information, preparing a transaction, and
sending messages to the server -- but server-side code for verifying
that changes to the database were legal.  That way, Python code that
was downloaded (and possibly modified) in the client can't change the
rules of the game.  I tried to make each message to the server
preserve correctness regardless of the parameters passed.  For
example, instead of set-money() and set-tanks() messages, I used
buy-tanks(amount).  If the buy could not proceed (perhaps because the
amount of money had changed in that time, or the price of tanks had
gone up), the server would return an error flag.  If the user hacked
the bytecode, he wouldn't be able to do anything terrible, because the
server doesn't depend on the parameters being consistent with any
other data.  (In fact, if your client-server protocol is protected in
this way, you could open up the protocol so that people can write
third party clients...)

| Is it easy to build a version of the source that contains *only* the byte
| code interpreter, and not the run time parser and compiler?  Much of the
| Python stuff seems geared towards the interactive command line interface,
| which is nice if that's what you need, but I want to use the standard model
| of compile source to byte code, and then run only that byte code in my
| virtual machine.

I think the last time I looked, Python took up 500k of run-time, but
some people were able to get it down to 350k-400k by removing modules.
It'd be nice if there was only a byte code interpreter, but I don't
think it's been done.  When I last looked at this, 500k was a big
deal, but it doesn't seem to be a big deal on PCs anymore.

      - Amit