Mud data store

Started by
6 comments, last by MoTherNuBBeR 18 years, 7 months ago
I just need to know what the most efficient way to store character data, world info, etc. I have seen many ways but what i was thinking using xml and filling an abstract class for each character that logs on. I have the connection working and asynchronous socket connections but now i need to know what is next. Thanks in advance!
Advertisement
I would highly recommend XML. I've used it in two mud servers so far and a couple telnet clients for setting data. It has an initial learning curve, but once you get the hang of it, its not so bad. The major plus I've found is that it lets you add things to your character data at a later time in a way that won't invalidate older character files (granted, these files should probably be updated). Generally, I've just found it very handy.

Try to get a copy of tinyXML and play with it a bit. I use Xerces often times, but a lot of people will tell you it's overkill (it is), and that its a massive library where a smaller one will do the job just fine (which is also true). So just avoid the hassal and get Tiny ;)
My MUD kit heavily relies on XML for world data. The entire world data, including items, rooms, players, npcs, etc. was stored as XML.

I used XML because it's easy to read as human and usually easy to parse without your mud server.

Alternatively, you could go with an SQL server(Such as MS SQL or MySQL) to store all data. The pro of using an SQL server over XML files is that you can quickly selectively select data(Such as just checking the username/password) without loading the entire profile. Another pro is that you can display specific info about players even when they're offline(And their profile is unloaded).

Toolmaker

Quote:Original post by Toolmaker
My MUD kit heavily relies on XML for world data. The entire world data, including items, rooms, players, npcs, etc. was stored as XML.

I used XML because it's easy to read as human and usually easy to parse without your mud server.

Alternatively, you could go with an SQL server(Such as MS SQL or MySQL) to store all data. The pro of using an SQL server over XML files is that you can quickly selectively select data(Such as just checking the username/password) without loading the entire profile. Another pro is that you can display specific info about players even when they're offline(And their profile is unloaded).

Toolmaker


Also, a good number of free SQL servers have an XML interface, something to think about.
Sounds good guys. Thank you for the suggestions! Another thing is a MudLib a necessity because it seems that i could do this a lot more light weight than other open source muds that i have seen out there. If i would need a mudlib what are some things i should include or is there somewhere that explains that?
Quote:Original post by MoTherNuBBeR
Sounds good guys. Thank you for the suggestions! Another thing is a MudLib a necessity because it seems that i could do this a lot more light weight than other open source muds that i have seen out there. If i would need a mudlib what are some things i should include or is there somewhere that explains that?


I'm not exactly sure what you mean mudlib. As far as other open source muds go, there's usually a few reasons they're large and complex.

The first is that many of them have been around for ages, or are derivitives of other works(speaking from mostly ROM and DoT experience here), so the general style of coding is usually either straight C or C with some C++ thrown in / converted, which can tend to be a bit longer than the C++ equivalents sometimes (and other times shorter, granted)

Another reason is that many codebases dont use a lot of dynamic code, they program in every single spell and skill statically, and have blocks of special code all over the place to handle that one item. Take a weapon flag for instance (lets say 'fire'). The fire flag might have special code written in several places in the fight functions: calculating to hit, extra normal damage, chance to blind or damage equipment, elemental damage, etc. A seperate flag, like 'ice' would use completely different blocks of code to determine it's effects.

This is how a good number of MUDs have been programed, and I agree, there are a lot of ways this could be streamlined and made more dynamic and compact, it just depends on how you want it to run and how you want the code to look.

I dont know if I answered your question or not, but I hope this helps some!
Quote:Original post by MoTherNuBBeR
Sounds good guys. Thank you for the suggestions! Another thing is a MudLib a necessity because it seems that i could do this a lot more light weight than other open source muds that i have seen out there. If i would need a mudlib what are some things i should include or is there somewhere that explains that?


A mudlib is just the name that a certain type of mud uses for game-specific code, as opposed to the lower level database and networking code. The idea is that you can swap the mudlibs without altering the underlying system. But it doesn't really have any relevance to what you're doing, if you're just coding a mud. Just code what you need, and don't worry about what other systems do.

Thank you all for the help. All of my questions have been fully answered.

This topic is closed to new replies.

Advertisement