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

Coyote Coyote at TimeofDarkness.com
Sun Jan 26 01:28:17 New Zealand Daylight Time 2003

On Friday, January 24, 2003 4:13 PM Ben Chambers wrote:

> Which language is prefferred for mud design?  C/C++ provides speed
> but Java adds a lot of flexibility.  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?

There's arguments for both sides, which give good arguements for
both.  However, I kind of hold a preference for the C/C++ route
myself to tell the truth. Most of this to tell the truth is because
it is what I am familiar with (and yes, I know there's TONS of
similarities between the two). This is one of the strongest things
that I believe you take into concideration. What are you comfortable
with working in.

As for handling incoming commands, I can only really speak from a
RoT (Diku/Merc/ROM derivitive and all that). The whole server is
actually one large loop that tackles one task at a time. When
handling inputs, it starts from the beginning of its lists of
connected users, and checks the input buffer of its socket. It then
interpretes the command, and performs the action the player wishes
to perform (if a valid action was specified).  While this actually
works for the mud, it is based upon the legacy of the code in the
end. To combat any lag in it, it would be possible to improve
it. Adding code to do such things as forking the process(es) to
handle the input while the mud can move onto other things is a
distinct possibility.  Adding an event system might work as well,
however as you said, there's the possibility of adding lag in
handling your events as well.

With the power of more modern servers, this might start being less
of a concern though. Don't get me wrong, tight code should always be
a goal in design, but some features that you may want to add in the
future might be worth a touch of work for the processor. Just set a
point somewhere that you don't let yourself cross. Performance vs
Functionality will always be a tough descision and fight.

Not sure how much, but I hoped this helped, a little at least. Good

Bob Chapin

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

More information about the MUD-Dev mailing list