Original Post
I've been working on my own next generation MUD server for years, but I've finally gotten down to brass tacks and want to complete it. The issue I am running in to now is data storage. I am definitely going to use an RDBMS back end, but how do you make it extensible? I can release the MUD server with a sane default data storage setup, but what if the new MUD administrator wants to add new properties to his Player object? I don't want them to have to update the database tables to reflect this. So I came up with the idea of making the data store a bit more property driven. For instance, rather than storing Player to a Player table, I store it to a Thing table, which has a bunch of foreign key references to a ThingProperty table, which stores free form properties for the object. Two issues I worry about with this: What is the definer of the object "base class", so to speak? Do I simply use reflection to basically serialize the object to the data store? Do I use .NET attributes to determine what properties of an object are actually persisted? Do I store something like a "ThingClass" in the database, that determines exactly what properties of every object type should be saved? Currently I am going down path C, defining every object "class" in the database, using a tool I call my MUD Schema Editor. Part of that editor is the ability to create the partial C# class stubs for those object types (honoring the hierarchy the MUD administrator decides on). Does this make sense? Is it over engineering? Is performance going to be an issue? Obviously the ThingProperties table could get huge, as it will contain a row, for every property, of every object, in the MUD world. Also, there has to be a differentiation between a blueprint of an object and the instances that have been created of the object. The instances need to also be persist-able, raising the number of rows that table could have even higher. In the "old world" of MUD servers, you really had two ways to define things: The DIKU way, which were this space delimited text files, that changing the format or storing a new property was very painful. And the LPC way, where every entity in the MUD world was a complete code object that was loaded at runtime (and probably sub classed from a system object, like /Sys/Lib/Mobile). Some projects like ColdC have come along, and what I am trying to achieve is sort of a hybrid. I want my data definition separate from code (so not LPC style), but I want my data store to be flexible to the world the MUD builder wants to make (not DIKU style), without a ton of code changes. I guess I'm not really asking a question, so much as looking for validation of my ideas (or invalidation of them, which serves my purposes just as well at this point).
