-
Notifications
You must be signed in to change notification settings - Fork 12
Database Design
The database format used for the game consists simply of a basic text file, aka 'flat file'. (default name is "db.txt")
Within that file is a collection of lines. Each line specifies information for a single game object. The game objects in the code are of the type MUDObject (or one of it's sub-classes).
Data for game object(s) is represented by individual fields separated by the '#' symbol. Some fields are simply a string, some are integers, sometimes it consists of comma separated values, whereas others may contain array data. Certain fields use comma separated values where the text between each pair of commas is an element.
If a line is prefixed with an ampersand symbol/character ('&') the line will be partially ignored when the database is loaded, which process will be described further below.
The flat file method of storage used has a number of prominent limitations, namely that it requires that certain reserved characters not generally appear in the data. The number sign (#) is one of them as is the comma (,). While the latter may appear in plain strings like the description, some fields are treated as a set of elements with the comma as a separator. As such it should always appear only between two distinct elements.
Example (a player):
19#Nathan#P#This is an admin, it is also a player and a builder.#8#ckfpgtcnckvpgttqvgxcvequktfk#12,12,12,12,12,12#25,950,0,0#4#3#10#IC#0
19 <- The Database Reference Number (DBRef), roughly equivalent to the line number in the text file.
Nathan <- The name of the object, in this case it is the name of a player.
P <- The single character 'flag' (see Flags) that indicates this is a Player Object
This is an admin,.... <- A description of the object (String)
8 <- The location of the object, which is also a Database Reference Number (DBRef), identifying the "parent" object it is located within (generally a Room).
ckfpgtcnckvpgttqv,... <- Password Data (obscured by simply encryption, a hashing of sorts -- only intended to help prevent plain text of passwords being a problem if the database were to be compromised in some fashion, this wouldn't prevent an admin from enabling the code to let them change your password).
12,12,12,12,12,12 <- Player ability scores (for MUD purposed): STR, DEX, CON, INT, CHA, WIS ?
25,950,0,0 <- Information about player money, this is fairly specific the way money is hard-coded at the moment. (In theory there is some code in place for flexibility, but a change would require some moderate code modification)
4 <- Player permissions (0 - USER, 1 - BUILD , 2 - ADMIN, 3 - WIZARD, 4 - GOD)
3 <- The player race (there's an enum for this)
10 <- The player class (there's an enum for that too)
IC <- Player "status" string, there is where **IC** (In-Character) or **OOC** (Out-of-Character) would go as well as other status types. E.g. **EDT** (Edit)
0 <- Player state (enum): alive, incapacitated, dead, ?
Not every line is identical, despite a certain level of similarity.
Essentially the first 5 fields are identical for every object (MUDObject) and any additional fields belong to or describe data for a particular unique type.
Loading the database in the code consists largely of calling the constructor to get an instance. Generally speaking that would be a "static" instance, in the sense that there is only one. You cannot get a second one by calling it again.
Once you have a database instance, you can invoke it's loadObjects(...) method with the appropriate parameters (not shown here).
The current design of the database is a static instance of ObjectDB (Java class) that holds various maps and collections of the game objects and methods for accessing objects in it. Generally speaking, you can access a given object in the database by name or it's database reference. Using a name has some ambiguity to it as you'll get the first object named that, whereas using a DBREF (database reference) which is an absolute reference will you the object with that ID and no other. I.e. the latter implies zero ambiguity.