[MUD-Dev] Programming Languages and I/O Algorithms

Udo SchrXter udo.schroeter at trionic.de
Thu Jan 30 18:54:31 New Zealand Daylight Time 2003

Ben Chambers:

> Which language is prefferred for mud design?  C/C++ provides speed
> but Java adds a lot of flexibility.

I'm currently developing a mud in Delphi (although work always
interferes and so I'm making no progress). From my experience:


  - it's easy to get things done

  - language is very powerful but tightly structured, you can do
  high level things easily but you can also descent into the depths
  of the OS if you need to

  - lots of freeware components and objects for networking and other
  stuff, lots of classes available in standard installatin

  - native String type, easy string manipulation (good for muds),
  also protection from buffer overrun exploits

  - Kylix (Delphi compiler & IDE for Linux) is free for personal use


  - not as platform independent as Java

  - compilers available for Windows and Linux only (free Pascal
  implementations largely suck and/or have bad OO design [mail me if
  you found a good one])

  - Windows IDE&compiler is not free (although Personal edition is
  not expensive, you don't really need the super-expensive
  Enterprise version anyway)

> Furthermore how do most muds handle incoming commands in order to
> minimize lag?  I was thinking some sort of queue sorted by
> criticality of the type of event, but then you have to pre-process
> all the events and sort the queue which then creates lag in the
> process.  What are some common solutions?

I think the priority queue for commands (sorted by criticality) is
not neccessarily a good idea because it introduces much complexity
for an uncertain gain.

Maybe experienced MUD programmers disagree with me on this one, but
I always try to stay with the simplest solution that could possibly
work (well, the code should also be elegant).

My approach is, that once a request rolls in and the server socket
has received the command, the command is instantly launched or
queued for execution by the command thread(s). Once the command
finishes, it sends results either directly to the socket or it
triggers an event handler that lets the server component do the

I don't know if that's common, though. My experience with
client/server programming suggests that overhead and complexity of
priority queues does *NOT* reduce lag - especially for
short-running, non-cpu-intensive remote calls (such as MUD

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list