Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 11-09-2009, 03:45 PM   #1
Graham
New Member
 
Join Date: Apr 2009
Posts: 9
Graham is on a distinguished road
Persistence in a MUD server

Hello everyone,

I've been programming for around a total of 9 years now, and programming Java for around 3 years. Recently I've wanted to develop a MUD server (in Java), mainly for experience and the fact that it'll be pretty cool, and perhaps there is a remote chance that I might actually run it.

I've had a look through several Java codebases, and found them to mostly seem incomplete or pretty old (and therefore not able to take advantage of some more recent additions to the Java API e.g. NIO). One that seems more complete is CoffeMud, however, that seems to be very large (and maybe over-complicated) and I'd rather not spend time stripping things out and understanding how the whole thing works.

So basically, I've decided to work on my own. I can handle the networking code (having done that in other projects) but one thing I am having problems over is the persistence code.

I've attempted a few attempts but none of them seem to work the way I would like, and am wondering if anyone here has any input on the methods I've been using or perhaps have some great idea that's better than the things I've tried :P.

The options I considered were:
  • Java Serialization
  • Object Relational Mapping library (e.g. Hibernate)
  • Traditional relation-database approach (i.e. using JDBC with MySQL or whatever)
  • Flat-file based system
I didn't do anything with Java's inbuilt serialization, anybody who has used it will know that it isn't really going to be suited to this sort of thing - problems usually manifest if you add more fields to objects, take fields away from objects, etc.

The next thing I looked at was using something like Hibernate, which maps your objects into tables in a traditional RDBMS (more info about ORM can be found here: Object-relational mapping - Wikipedia, the free encyclopedia).

I wrote a basic server which used the ORM approach but I found some problems: I ended up writing a lot of XML to tell Hibernate which objects and fields to map. This became cumbersone, so I switched to Hibernate Annotations which can automatically do this for you, but that didn't provide the correct level of configuration I wanted. I also had problems getting the keys set correctly without manually inserting SQL (and the whole point is to avoid it!), which would cause performance issues as my DB grew larger. Inserting the SQL cannot be done manually afaik, you had to write it into the config files, as Hibernate makes changes to the tables each time you start it in case you add new fields to your objects etc.

So I've gone back to choosing between a RDBMS and a flat-file based system. Most MUDs, especially the more traditional C or C++ ones, use flat-files but I'm wondering how good this is. Some of the file formats used for configuring areas seem less than ideal, probably as they were hacked together quickly, although I guess that they are edited by the server themselves with the online editing functionality.

The main problems I'm seeing with an RDBMS or flat-file system is that I'll have to write the persistence code for everything manually (if you can get an ORM tool like Hibernate to work correctly, adding a new class to be persisted it or changing it is supposed to be easy).

At the moment, I'm leaning towards a RDBMS because it'll allow much greater capabilities: data can be sorted/organized easily, and there could also be some form of web interface done easily. Also you don't have to worry about corruption, redudancy, etc. as a properly-configured db server can do that all for you.

This leads me into another point: how the persistence code actually works on the server. I haven't studied the code from existing MUDs in a lot of detail, but most seem to cache a lot of things such as areas into memory upon startup. I'm thinking this is the best approach, but just wondering about people's views on it.

So essentially, what I'm wondering about is people's opinions on how the persistence in the MUD should work. Which system do you feel is more appropriate? If you could scrap all the past versions of MUD servers which may be restricted to a particular technique for historical reasons, which one would you use in a brand new server?

Any tips/ideas/suggestions would be appreciated, however, I've tried the easy way out (ORM) and believe that I'm going to have to put some hard work into a relation database system :P.

Also a quick thing which is loosely related to what I am talking about, but I'd also be interested in, is an approach to how the objects would work in the actual server code. Most MUDs use an approach with classes for an Item, Area, Room, Player, Npc, etc. However, I've also seen a pretty cool use of a more monolithic system with a single MudObject class which was used for everything. (In the 16k MUD written in Java somewhere on this page 16K MUD competition - results).

This post is pretty long (sorry about that!), and perhaps I seem like I'm moaning about how none of this persistence stuff is any good for getting something down quickly and simply, but I'd like to hear about other user's experiences on the subject (rather than looking at other MUD's code) and perhaps gain some more useful insight into the subject.

Thanks!
Graham is offline   Reply With Quote
Old 11-09-2009, 04:38 PM   #2
Hephos
Senior Member
 
Join Date: Feb 2003
Location: Sweden
Home MUD: www.sharune.com
Posts: 359
Hephos is on a distinguished road
Re: Persistence in a MUD server

We used Java Serialization for the java server we made for "Aeonfalls". Due to lack of players and builders we did never put the game live however. But the server is fully functional.

Serialization worked okay. Remember to give the classes a serialization id (so it is static if you change the class). Then in the deserialization methods (cant remember the name correctly) you can just initialize any new values you have added to the class that is not in the saved object. So we never had any problems adding or removing fields. The problems are that the saved objects are not easily readable, which is the only drawback i can think of (and that you can't access it with queries like in a database). Or easily modify large chunks of stuff (like in a database).

If i were to do it again, i would probably look up hibernate and saving the stuff into a mysql database instead. So much easier to have everything in a real database.
Hephos is offline   Reply With Quote
Old 11-11-2009, 03:42 AM   #3
noodles
Member
 
Join Date: Nov 2002
Posts: 30
noodles is on a distinguished road
Re: Persistence in a MUD server

I've done it several ways, none of which were in Java however.

When working in an LPC MUD, it had flat file based persistence. You could save an object to a file, where the .o file was text based and human readable (the format was called mudmode, you can find a good enough description here Mudmode transport protocol specification). The format is quite robust, allowing removal and addition of new fields as long as the logic in the overlying object does not change to be incompatible with existing persisted data. I'd only go with this approach in future if I really wanted to keep things simple or to use as an interim solution for the sake of prototyping.

Object relational mapping was too heavyweight and coupled for me. If I wanted to implement a feature, it required too much work doing the persistence support and the feature tended to be affected by that support.

Relational databases are my solution of choice. Straightforward database tables, with one layer of abstraction provided by the stored procedures used to access them. Another layer on top of that which wraps the stored procedures and if necessary and practical, caches and wraps access and modification of that data. Then the game logic over and above that. At first, I might prototype the service to execute SQL inline and when the data needs are concrete, solidify it into the final tables or stored procedures.

I wouldn't cache at all actually. Given a good way to profile where the database load comes from, plugging in caching where needed is a decoupled action that happens in the stored procedure calling layer between the game logic and the database that you can just do when needed.
noodles is offline   Reply With Quote
Old 11-28-2009, 12:21 PM   #4
Graham
New Member
 
Join Date: Apr 2009
Posts: 9
Graham is on a distinguished road
Re: Persistence in a MUD server

Okay guys, thanks for your reccomendations, I think I'm going to look into doing it manually through JDBC as it looks like it is going to be one of the better routes, especially since querying the DB will be easier.
Graham is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 07:15 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014