[MUD-Dev] Python script as stand alone MUD server...

[Alistair Riddoch]

On Thu, Jan 22, 2004 at 01:46:26AM -0500, Jason Slaughter wrote:

> Of course, being a scripting language, it will be slower than
> compiled code, but is that really going to be an issue? It seems
> to me the bottleneck in a mud server would be in the game logic,
> not in the lower level server/socket stuff (and the game logic
> would ultimately come down to Python scripting even if I compiled
> the server using C++, and used Python only for scripting)... so I
> would say that as far as speed goes, the loss won't be crippling
> at all (and it would be worth spending an extra $1000 on a faster
> server, at least, if it means saving a 100+ hours in programming
> and debugging).

> What are some other issues that I have to think about using
> Python?

When I joined the WorldForge project about 4 years ago, its only
functional server was written in pure Python, and it worked
extremely well. Python's high level features made it relatively
simple to code complex AI, introspection made it easy to to build a
flexible game object system using native Python objects, and the
whole code-base was completely portable.

Performance was a big problem. As I got involved in development, it
quickly became apparent that we were going to need to do some
serious work if we were going to scale beyond a dozen or so mobs and
players per server.  I started to look at approaches to solve this,
and immediately looked at compiled code as the solution. I am not an
expert Python programmer, but the majority of the code had been
written by another developer who is very experienced, and I had no
reason to believe that the performance was due to bad coding. I
investigated and experimented with a few approaches, including
implementing performance critical components as compiled Python
modules, and finally settled on re-writing the core of the
application in C++, and keeping the high level code as scripts.

I was able to automate much of the syntax mangling from Python to
C++, and the structure of the code remained basically the same. The
automatic conversion was done with simple munging scripts in perl,
and manual fix-ups and debugging took no more than a week of part
time hacking.  The starting point was 12,000 lines of python, and
the result was about 10,000 lines of C++ and 10,000 lines of python.
The resulting code was somewhat less portable, but not fundamentally
so.

4 years down the line the code is working well, and is still our
flagship server. Performance has been improved by a factor of more
than 100, though it is difficult to be precise as the job has
changed a lot over the evolution of the code.

Overall I think Python was an excellent language to build the
original prototype in, given the rapid development cycle, good
readability and ease of refactoring, but it does not seem as though
even now Python is fast enough for a decent scale MUD server. It
also works very well as an embedded scripting language. However if I
was going to do the same job again, I would probably not look to
C++. Its overcomplicated, difficult to debug, and takes a long time
to learn.  Java now feels like a preferable option, especially given
that Jython exists, and makes Python's introspection available from
native Java and vice-versa. Free implementations of Java do exist -
major applications like eclipse are becoming available built with
gcj, part of the GNU compiler collection.

The above probably sounds a bit disjointed. If you would like to
know more about the specifics or either the original or the current
code please let me know.

Al
--
Alistair Riddoch
alriddoch at zepler.org
http://www.zepler.org/~alriddoch/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev