Member Discussions

As a preface before we go any further: you will
not convince me not to use C#. You just won't.
I've had a dozen arguments of C# versus Java,
nobody will persuade me otherwise. ;)

I am working on a MUD framework in C# that is
inspired by ROM 2.4b6 classic. The framework is
designed to provide a MUD platform for new
generations that is great for rapid design and
prototype. The goal is to allow amatuer would-be
MUD administrators and future programmers to
learn today's technology, as well as allowing
seasoned admin veterans to be able to play
around with even more complex concepts in their
MUDs that are less feasible in and much more
time consuming in other languages, such as C.

That said, the framework, game logic, network
handling, timing, buffering, and so on and so
forth is almost all completely functional. My
next target is to nail down how information
about the game is stored and loaded. The two
technologies I'm debating between at this point
are probably no surprise - XML or SQL.

I've worked with game systems that have relied
on one, the other, or both simultaneously -
there are some significant trade-offs between
the technologies.

On one hand, SQL is by far the fastest and most
efficient technology. For a huge MUD or game
server, SQL is definitely the way to go in
managing massive amounts of stored data
lightning fast. SQL also provides easy
integration to just about everything - your web
server, your blog, and other utility
applications you write - almost all of these
support SQL better than XML. In addition, SQL
provides tools for remote administration, and
also takes up less disk space overall (though
that's hardly a concern these days).

But on the other hand, SQL has a number of
significant drawbacks to the MUD community.
First, it requires a "new" technology that isn't
support by the majority of MUD hosting
organizations. In addition, SQL has a barrier to
entry - setup. With traditional MUD codebases,
you can download and execute, get on your
administrator character and begin toying right
away. With SQL, you would have to install and
configure SQL, learn about how SQL is
maintained, and so forth. I see this as a
significant deterrent to creating a MUD, using
SQL as a newbie can be a challenging and
frustrating experience.

XML isn't as fast by a significant margin, but
provides a number of other bonuses. It's easy to
work with because you're using tools you're
already familiar with - your operating system.
All the files are stored in the OS filesystem so
maintaining and accessing those files isn't
difficult at all. The plain text and human
readable format is nice for MUDs as well,
accessing player data and finding which AC value
is which is no longer a guessing game, because
it tells you what's what in plain English.

XML also provides one huge benefit - shell
accessability. It's a lot more difficult to
access your SQL information from a strange place
or from your smartphone, whereas with XML, you
can telnet into your shell and use your good
friend pico (or whatever you love) and edit
whatever you need to with ease.

Now, there is the opportunity to use both XML
and SQL as a third option, although I'm most
hesitant to do that since it requires the
operator to know and understand both of those
technologies. That option is to store certain
information in SQL, with the rest of it in XML.

SQL:
- Player files
- Persistent map data (not area files, but items
on the floor, dead mobs, etc.)
- Most standard "runtime modified" content

XML:
- Areas
- Object definitions
- Mobile definitions
- Just about everything else, specifically
things that are accessed very infrequently at
runtime, except at predefined intervals (such as
boot-up, reloads, copyovers, etc.)

It's really a tough decision to pick between the
two, but after talking with a few other MUD
developers and implementors, I'm leaning towards
the XML solution. In an application such as a
text MUD, heavy load isn't nearly as big a
concern as in something with more "moving parts"
- such as 3D game with vertices and precise
coordinates that are constantly being
recalculated by the server, leaving less cycles
available for things like processing XML files.

What are your thoughts on the problem presented?
Are there any additional recommendations or
considerations you can think of?


~Polatrite~

IMO, SQL is a much better option than XML for lots of reasons. Just because the MUD community is behind the times, doesn't mean SQL isn't a standard everywhere else, and you shouldn't lag behind with them "just because".

That said, if you're creating this codebase from scratch, then don't do either exclusively. Abstract.

I'm sure you probably know how to do this already, but the basic idea is that you create a data abstraction layer, and all requests in the codebase hit that layer when requesting data. Then, the layer itself is instantiated with a "database object" which knows how to pull the data from either XML or SQL.

Generally speaking...

public class AbstractionLayer {
    public Database db;
    public void AbstractionLayer( Database db ) {
        this->db = db;
    }
    public int getId( int id ) {
        this->db->getValue(id);
    }
}

public class SqlDb extends Database {
    public String getValue( String key ) {
        return sql->execute("SELECT "+key+" FROM table WHERE something");
    }
}

public class XMLDb extends Database {
    public String getValue( String key ) {
        Xml file_contents = parse_xml(filename);
        return file_contents->key;
    }
}

//Somewhere in your startup code
if (dbLayer == "XML")
    backend = new XMLDb();
else if (dbLayer == "SQL")
    backend = new SQLDb();
AbstractionLayer db = new AbstractionLayer(backend);

Then the MUD admin just chooses which backend they want to use by setting the "dbLayer" variable.

Best of Luck,
-Jess

Jess, thanks for the response. I've seen this technique tried on another large open-source game system, OpenTibia based off Tibia, a 2D ORPG.

OpenTibia supported both XML and SQL standards for many years before eventually dropping support for XML entirely because it was too much effort to mirror functionality and still keep things running efficiently. Personally, I only want to support one format and stick with it - since I'm releasing this codebase into the wild once I read legalise and select an appropriate license, someone else could add support for the other half later if they're interested.

As far as SQL being the standard - it certainly is. However I'm not necessarily releasing this codebase for the philosophical good of the MUD community, but more for the practical good. I'm more interested in appealing to would-be administrators than seasoned developers. The more people that get into game design and development renders more games to play, whereas appealing to developers alone just alienates newcomers and doesn't generate new games.

As an aside, many developers that I know are also very lazy and spend most of their time learning instead of developing - that's even LESS games created. ;)


I'm most interested in the technological ramifications behind choosing one technology over the other, as it relates specifically to the MUD platform.

Personally, I only want to support one format and stick with it - since I'm releasing this codebase into the wild

Well, I guess that's your call... but that you're "releasing this codebase into the wild" is all the more reason to create an abstraction layer now -- for others to build on. If you start by tightly integrating with one format, no one is going to come along and pull apart all your code to abstract the data later. Once your project is mature, pulling it apart in that way will be a royal pain, while doing it early on is actually pretty easy.

I'd suggest looking into ways of doing it practically with little extra effort... just because one place abandoned the idea because they thought it was too much effort, doesn't mean your project has to be too much effort too. I'm talking from experience when I say abstraction layers for data are very easy.

But alas, it's ultimately your call.

Good luck either way,
-Jess

I quite agree with Jess on this one, if the code has been designed that way, it's easier than going it from scratch.
However, that said, I also think that if you must have one or the other, you should go with SQL, as it's much easier to integrate with other external applications then. (*cough website cough*)

...I should note that adding an abstraction layer would also allow you to later add cool stuff like adding new backends for other formats (like Diku areas, exported pfiles, etc) without creating extra import/export functionality.

But anyway...

If you're going to use LINQ, it makes less of a difference whether you choose XML or SQL.

I know this is more of a pet peeve than a justified opinion, but personally I think XML is one of the least human-readable formats out there, if you're simply dealing with the files in a text editor. It really does make my eyes bleed. If you want readability use something like yaml or json, or just plain text for that matter.

I'd have to agree with the XML being horribly unreadable. I've seen some perl code that could cause blindness and C/C++ code that gives you horribly unfounded diseases and even all that is better than XML. Plain text files (which is every file in a mud minus the executable, in a rough sense) are easiest manipulated in any given text editor (emacs, pico, nano, vi, leafpad, etc). Anytime I want to add something that's new to the mud that might require something like XML or SQL, I ask myself if the work is worth the effort of that one thing and then if the extended work to bring in more stuff to make the technology used worthwhile...most of the time it's not, and I'll figure out another way that's easier for my time and effort.

If you want readability use something like yaml or json, or just plain text for that matter.

I have to disagree with you guys here... XML is annoying to parse by hand, but I'm not sure what you'd want to do that anyway, and it comes with benefits that can't be ignored.

IMHO, plain text is out of the question. It's slow, has no inherent features, doesn't meet any standard, and so on. At least XML is clearly defined. Some strange custom format in plain text requires learning a whole new scheme.

yaml is notoriously slow (but wonderfully easy to read). It's also not really suited for storing long paragraphs (for room/player/obj descs)... but it would be great for config options or settings. If you're only loading this stuff on boot, then the speed issue won't be much of a problem, but XML is still better for anything but hand-modifying the data.

json doesn't make a lot of sense unless you're planning to use javascript somewhere. Otherwise, you might as well just serialize your data and store it in your own format.

Anytime I want to add something ... that might require something like XML or SQL, I ask myself if the work is worth the effort...

SQL is pretty easy. Have you used it much? I've heard it was initially created for receptionists and clerks with little-no computer knowledge, and I don't find that hard to believe given its ease of use. If you don't have much experience with it, I'd suggest trying to integrate something with (say...) MySQL just to pick up the skill -- the feature set is well (!!) worth the small entry barrier.

XML, OTOH, is a pain in the butt.

Best of Luck,
-Jess

(Comment added by mann_jess on Thu Aug 6 23:44:05 2009)

The first point I was trying to make was that if he's going for a file-based storage scheme (or whatever you want to call it), then IMO XML is definitely the way to go. yaml/ini are great for configs, and json is great for web stuff, but XML does have a boatload of advantages that make it well suited for storing data like game structures.

As much as I prefer SQL, XML does have its place.

It's still a pain in the butt, and the OP should still abstract or go with SQL, but that's another issue...

AS many of the posters have pointed out, the best way is an abstraction layer that can be used which-ever way you want, especially if it is something that you are planning on sending out in the wild. Why would you want to send out something sub-par?

If you are still interested in a C# development I'd suggest you head over to www.wheelmud.net (or is it .org these days?) They are the most elegent C# mud development out there.

Doesn't anyone use object databases any more? I can't see the point of storing data in a SQL-compatible relational database unless you intend to actually run SQL queries against it.

(Comment added by shasarak on Mon Nov 9 6:22:25 2009)

By "run SQL queries" I mean "run SQL queries that do something other than simply read or write persistence information on an object-by-object basis".

shasarak wrote:
Doesn't anyone use object databases any more?

Did anyone ever? The only one I have ever used was Poet and that because it was the only one I could find that had a developer/student non-commercial license. Or are you talking about something else?

>> It's a lot more difficult to
access your SQL information from a strange place
or from your smartphone, whereas with XML, you
can telnet into your shell and use your good
friend pico (or whatever you love) and edit
whatever you need to with ease.

I have never had a problem telnet/ssh-ing in and running SQL queries with ease. I guess my method must differ from yours.