mudlab.org: Database options

Link: Database options.

This is how it is done in EVE Online. We also have a web based interface which all game design, game mastering and general live game state browsing/modification is done within which we call ESP (EVE server pages).

We initially started off when we built one of the intermediate prototypes of the game by serialising the complete state for objects (using Python's pickle module). Like the character's state and the state for a ship which the character might own.

The pickling was ditched as a matter of course once we got a database server hooked up. However, where we have pickled blobs into the database for certain features (other programmers than I) it has resulted in confusion and pain. The problem encountered was that it made the saved state dependent on the implementation of the object, which is definitely something to avoid. Since the programmer who did it left the company, the next programmer who inherited the system proceeded to make changes which were incompatible with saved state which was then erroring when unpersisted. It was very difficult to track down, considering that only a few rare persisted blobs were incompatible.

Our objects are authored by content with values in this manner:

typeID, attributeID, valueInt, valueFloat

And attributes are defined in this manner:

attributeID, attributeName

And values for object instances are persisted in this manner:

itemID, attributeID, valueInt, valueFloat

We started off with valueString as well. But it turned out we had no need for it, so it was dropped along the way. In a text MUD I can see that this would of course not be the case.

If there is one thing I could change about this in retrospect, it would be to create some manner in which a set of attribute values could be defined as a group. And then rather than having to set all of those values on a type, you could just associate the attribute value sets with the type. This achieves several things. It reduces the work which the content department has to do to author new types and maintain existing types where all these attributes had been authored in a similar manner. But the key reason it has been discussed is that the sheer number of types and attribute values defined for types in EVE Online makes for a huge amount of static data which has to be sent to every client which connects. I personally care less about the latter reason and more about the former.

Another area discussed where it has been appealing to allow the content department to author sets of attributes for types, but in a different manner, was for the scenarios they author. The problem here was that if they wanted an existing type to be spawned, but with some type attributes changed, they needed to copy the type and modify those attributes. By allowing spawning of types but with overriding sets of attributes (something which wouldn't be too hard to implement for EVE but hasn't been done), this removes that need to copy.