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

Alistair Riddoch alriddoch at zepler.org
Wed Jan 28 02:01:58 CET 2004


On Tue, Jan 27, 2004 at 04:20:45PM -0500, Jason Slaughter wrote:

> Where you doing something extremely elaborate with the mob AI? Or
> was there some overhead because WorldForge (as I understand it) is
> a 3D graphic game? Or is Python performance really that bad? I
> remember playing a mud (a DIKU mud I believe) back in the day
> running on and old 486 machine with 16 megs memory. It seemed to
> handle 50+ players and n number of mobs without a hitch. Even my
> Xbox can handle more than 16 mobs or players in a full 3D online
> action game! :)

We are dealing with full 3D free form coordinates and some pretty
neat AI code, though there was no physics to speak of at that
stage. A lot of the CPU time was propagating events between
entities. My example here was not intended to be indicative of the
kind of load a text MUD server written in Python could handle.

> Am I misunderstanding something, or am I correct in that (from
> your experience) Python is ORDERS OF MAGNITUDE slower than
> compiled code?  YIKES, that doesn't sound good at all!!!

Python advocates will tell you that this depends very much on what
you are doing. If you write python like you would write C then it
will be much slower. Python's power lies in making good use of the
powerful built-in types like lists, dictionaries and objects, and
making good use of the standard libraries, many of which are
compiled modules.  If you end up having to implement a lot of the
details of your task, it is likely to be slower. If you can make
good use of built-ins and libraries, your code may well be faster
than if it was coded in C. Many of the built-ins and libraries have
been very well optimised, and are of course very reliable compared
with similar application specific code written from scratch for the
purpose.

> Hmmm... my second choice was to write the server in C++ for
> Linux... if this is the case, I will probably eliminate scripting
> (and keep it all C++ for simplicity), and just have a huge amount
> of pre-written and easy configurable behaviors that I can attach
> to mobs and objects.

By this do you mean a data-driven approach, where there server
contains this large toolbox of behaviours that can be specified by
the designer when building a world or game? Sounds like a workable
approach, though I suspect major for-thought would be required when
specifying the required behaviours.

Embedded scripting can be enormously powerful, as can be inferred
from the number of servers which are using it. Much of the AI code
we have makes use of some powerful high level features of python,
and would be enormously difficult to implement in C++, while they
were easy in Python.  If you wanted to avoid the complexity of a
Python interface, a simpler language like lua might make a better
scripting language. One major reason we have explicitly listed
scripting in the requirements whenever we have discussed server
design is because we wanted to be able to add new behaviours without
a server restart.  Technically possible in C++ using dynamically
loaded modules, but the technical complications of dynamic modules
in C and C++ outweigh the advantages in my experience.

I am not quite sure what conclusions to draw yet. If you are already
a competent C++ programmer, and you really want your server to scale
up well on modest hardware, then I am inclined to say you should
stick with C++. If you want to try some adventurous new concepts and
are not too concerned about massive scale then you may find working
with Python interesting. Hardware has got a lot faster since the PII
266 I used to run the Python server on back in 2000.

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



More information about the mud-dev-archive mailing list