[MUD-Dev] Language and platform for Text MUD server

[Patrick Dughi]

From: Andrew Batyuck

> I am doing non-commercial text MUD and rewritten platform from
> scratch several times. Main question is - "What language and
> platform can give good speed and decent extensibility" I
> discovered following in my efforts:

>   - Java - VERY extensible, cross-platform and VERY slow and
>   memory consuming

>   - C# - MOST extensible, cross-platform? =) and rather slow

>   - C++ - extensible, cross-platform with usage of third-party
>   libs and decent speed

>   - C - best speed, but not extensible

I want to describe my experiences with these languages to shore up
my argument a bit more, but I think it would just descend into a
holy war and serve no purpose.

Instead I'll just say C and C++ would be my most favorite choices,
and here's why.

C and C++ can be feisty, but I'd bet that you can compile a C
program on more systems than you could run a java interpreter.  They
may not claim platform independence, but existing free text MUDs
like CircleMUD show that they can be set up to compile cleanly
out-of-the-box for most systems out there.  Though it is not 'Free'
software, it is free, you can find information about it at
http://www.circlemud.org.

Using C also removes you from the rather arcane and difficult
non-platform dependant features of the poorly designated
platform-independent languages; things like features which silently
return when not supported, operate in slightly different ways, or do
not work and fail at runtime due to environmental setup being
slightly incorrect.  Java version changes catch me every other week,
and I couldn't assure you that users are going to be using the
version I developed with - but the standard C and C++ libraries
haven't changed in some time.

As for speed, yes, C and C++, and correctly written, there isn't any
appreciable difference between the two.  Drop too far into
abstraction, and yes, you'll start hitting problems - but that's the
trade off for OO design; bloat vs. ease of development.  The same
goes for memory for all OO oriented languages, as well as this speed
issue.

As for extensibility .. I'm not sure what you're talking about here.

As far as I know, there are many libraries for C and C++, and using
an OS that supports dynamic linking ensures that you can even have
run-time loading of libraries.  Ever try to use the Reflect class in
Java? Not only ugly, but it's not designed to be used in that way
since it breaks the pure OO model.  It's also very very slow
(improvements in 1.4 still show lackluster response).  Remote method
techniques are possible, but involve a nontrivial amount of external
setup and configuration, not to mention resources for
servers/application frameworks.

Or were you just talking about overloading operators?

Of course, if you were going to develop an interface for your MUD
that works through the web, rather than simple, standard Telnet, you
may want to consider the previous threads on Web Clients.  In this
case, C and C++ may not be exactly right for you.

> The only variant i see is to implement own language compiler or
> interpreter that would be extensible and quick - the only choices
> here are C and C++.

I think you are talking about writing a scripting system, so I'll
focus on that.  Scripting systems can be written and compiled in
which ever language you'd like.  Java can lex and compile as well as
C or C++ - in fact, it may even be a tiny bit easier (at the cost of
speed and memory, of course).  You usually don't need speed for
compilation of scripts anyway; it's not something you'd do in game,
on a time table, and memory will be a short-lived issue.

Once the scripts are compiled (whatever that means for you - I
assume a set of bytecode-like instructions or the sort), then it
doesn't matter which language they were originally parsed in, or
even if they mimicked a real language at all.  They can be
lua-based, for example, and be compiled and run through the lua
engine and called directly from a C or C++ program.  You could even
write up your own parser and lexxer and interpret your own language
from scratch.

Either way, unless you're interpreting your scripts continually
during runtime, I don't think the language you choose to represent
the scripts in, or that you use to parse them will make any
difference.

You may want to look at some script-intensive MUDs or MUSHs for
their techniques on scripting systems.


A last set of questions:

  Who is your target audience for this project?

  Are you developing this so only you and perhaps some friends can
  develop it, is it intended for wide (non-commercial or otherwise)
  distributions, or do you just want to get a game out as fast as
  possible for your users to enjoy?

  Where do your priorities lie?

  Will there be any external dependencies like databases, or
  maintenance scripts?

  Perhaps most important, is it intended to run on both Windows and
  UNIX derivatives (inc. Linux)?

These all affect the 'what is best for me' question.

PjD
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev