mapping ArmorTypes = ([
"Type" : "Light",
"Name" : "Padded",
"Cost" : ([
"Platinum" : 0,
"Gold" : 5,
"Silver" : 0,
"Copper" : 0
]),
"AttackBonus" : 1,
"DefenseBonus" : 8,
"ArmorClass" : 0,
"SpeedFactor" : 0.05,
"Weight" : 10
]);
CREATE TABLE Costs (
CostID SERIAL NOT NULL PRIMARY KEY,
Platinum INTEGER,
Gold INTEGER,
Silver INTEGER,
Copper INTEGER
);
CREATE TABLE ArmorTypes (
"Type" TEXT NOT NULL,
Name TEXT NOT NULL,
CostID INTEGER NOT NULL REFERENCES Costs(CostID),
AttackBonus INTEGER,
DefenseBonus INTEGER,
ArmorClass INTEGER,
SpeedFactor FLOAT,
Weight INTEGER
);
BEGIN
INSERT INTO Costs (Platinum, Gold, Silver, Copper) VALUES (0, 5, 0, 0);
INSERT INTO ArmorTypes("Type", Name, CostID, AttackBonus, DefenseBonus, ArmorClass, SpeedFactor, Weight)
VALUES ('Light', 'Padded', LASTVAL(), 1, 8, 0, 0.05, 10);
– LASTVAL() is the most recently inserted/updated sequence value in PostgreSQL, others may have different ways to get this.
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Type', 'Light');
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Name', 'Padded');
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Platinum', '0');
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Gold', '5');
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Silver', '0');
INSERT INTO Properties (ObjectID, Key, Val) VALUES (1, 'Copper', '0');
…
MUDObject -> Item -> Armor
Armor is the class for the object that you carry around and wear. ArmorType is an enum class where each enum represents a defined type of armor and holds basic properties of that armor like it's type (ex. light, medium, heavy, etc), cost, weight, etc.
Unfortunately, it recently occurred to me that this might present some problems. Namely that the current way of handling what Armor is is to assign it an ArmorType which is referenced when I want to know, say, what the Armor's armor bonus is. This is useful in that all padded armor, for instance, would be the same or it would be easy to tweak the "balance" of the equipment. Unfortunately this also means that new armor must be defined in that enum and care taken to not mess up the current arrangement (the "db" uses the enum ordinals for persistence) and differences must be handled as adjustments to the standard. Not a whole lot of flex here with regard to additional properties, etc.
I'm kind curious how other people would handle this kind of stuff in the code.
* I have been using some D&D/d20 stuff so far, just because it's a system where how combat and stuff works is defined for you.