Part 2:
I have more time than I thought, so I’ll start on Part 2 now. I should start with a minor correction:
(to the base table)
+ charXP INT(15),
Okay. For most of these systems, my grasp of mechanics is such I can either know them or look them up easily (like I had to do for the next section), but in the case of one (a HERO character), I can’t. Normally, this doesn’t matter, but when writing a database design, a tenet is to only store required information, as anything derived can be performed in calculations. So.
Powers in M&M are rather simple. THey have an Effect (or two, for Linked Powers), feats, extras and flaws. And a Descriptor. In an array, they can be Static (1 AP) or Dynamic (2 AP). They can also be in an Container (more on that later) or Device. So a power table should have a parentID (for arrays and containers). These can have a many-to-one relationship. (Also should list costs. This will be useful later)
CREATE TABLE mmPowers{
charID INT(4) NOT NULL FOREIGN KEY,
powerID INT(5) NOT NULL PRIMARY KEY AUTO_INCREMENT,
parentID INT(5),
pwrEffect TEXT,
pwrExtras TEXT,
pwrFeats TEXT,
pwrStatus ENUM('sta','dyn','non') DEFAULT 'non',
pwrFeatCost INT(4),
pwrEffectCost INT(4),
pwrExtraCost INT(4),
pwrLinkPower INT(5));
The last one, a refrence to another id, should be used on display. (ALso should be used by following powers)
I’m not sure that’ll work, but we can thought diagram a basic Array. Power 0 is Light Control, parent null (top level), and then 1 is ‘Light SHock’, a blinding (Obscure) power with parent ID of 1. ..
.. seems to work. It’ll probably break down during multiuser testing, but..
. .. let’s move on to containers.
Now, containers are weird. They get a total PP value and effects can be assigned to it. FOr the most part, until I re-read Ultimate Power, they can be used as if a power.
Devices will be displayed seperatly. As such we need to add a flag to the table
+ pwrDeviceFlag SMALLINT(1) NOT NULL DEFAULT 0
(I’m pretty sure the php programming for this will mean redoing the current template.)
So. Equipment is simple.
CREATE TABLE mmEquipment{
charID INT(4) NOT NULL FOREIGN KEY,
equipID INT(5) NOT NULL PRIMARY KEY AUTO_INCREMENT,
equipName VARCHAR(255),
equipCost INT(5) };
Now it’s time for..
HQ
The last bit, gets it’s own title because it needs to be two seperate tables. (For the same reason, say, the power table should have several subtables, but I can get to that later, when I do a formal design document). So the first table is simple. A name, a character ID (to tie the HQ too) and a HQ ID (for it’s various effects).
The second one should contain the effect + cost.
(THis table will probably need heavy revising. No books on hand means I cannot verify the needed facts)
(I.E A standard way to handle a many-to-many connection)
CREATE TABLE mmHQ{
charID INT(4) NOT NULL FOREIGN KEY,
charHQID INT(4) NOT NULL PRIMARY KEY
}
CREATE TABLE mmHQEFfect{
baseID INT(4) NOT NULL PRIMARY KEY,
effectName VARCHAR(255) NOT NULL,
effectCOST INT(4) NOT NULL};
That ends this. For Part III (Done later) I will write up a formal design document, convert it into real code, and in that or IV, document it.
No, that’s just going to be a pain.”