This week I’ve been fran­ti­cal­ly try­ing to final­ize some of the data­base struc­tures so that I can (hope­ful­ly) move off of data­bas­es com­plete­ly, and work only on art. I say data­bas­es, because all of our game’s prop­er­ties, stats, effects, etc are pro­duced by cre­at­ing mas­sive spread­sheets that are export­ed as CSVs and pack­aged with the game builds. I will prob­a­bly nev­er be total­ly rid of these spread­sheets (in terms of my work­load) — but it’s real­ly nice to feel like I’m almost done with the design work required to set them up.

In writ­ing this, I’ve just real­ized that our design process has moved almost 100% from writ­ing game design doc­u­ments (which I have always thought of as an out­dat­ed process any­way) to doing game design entire­ly via spread­sheets. More specif­i­cal­ly, we use Google sheets, so the entire team can edit them at the same time.

Spread­sheet design­ing may seem odd, but think about it this way: if the spread­sheet data­bas­es con­tain all of the prop­er­ties that can make a game enti­ty behave in a cer­tain way, then all we need to do to design a new prop­er­ty is add that prop­er­ty to the sheet, give it a descrip­tion, and mark it as new. Then at some point our pro­gram­mer will be going through that data­base, adding sup­port for any of these new / unsup­port­ed fea­tures. Anoth­er ben­e­fi­cial byprod­uct is that the design­er / scripter can cre­ate data for this prop­er­ty before it’s even been pro­grammed (as in the image below), so that the moment this fea­ture comes online it can be tested.

I want­ed the character’s Spe­cial Meter points (SP) to drain when the play­er per­formed a shield dash. So I sim­ply added a columh for this prop­er­ty / fea­ture to our char­ac­ter data­base spread­sheet. By leav­ing the”KEY” row blank, and using con­di­tion­al for­mat­ting to flag the emp­ty key in red, our pro­gram­mer will know that he needs to add sup­port for this fea­ture. He will val­i­date the key row (the code pulls infor­ma­tion via key row terms) with a unique entry when he’s ready to sup­port it.

I won’t say it’s the the absolute end-all-be-all best prac­tice, but it has been work­ing for us. Either way, design doc­u­ments are dead to me, and have been for years. Using a lin­ear doc­u­men­ta­tion for­mat (game design docs) to design a non-lin­ear expe­ri­ence (a game) is a fool’s errand. It is impos­si­ble to orga­nize per­fect­ly, leads to redun­dan­cy when writ­ing, neces­si­tates edit­ing in mul­ti­ple places when any change is made, and caus­es mis­com­mu­ni­ca­tion with the team (none of whom read it more than once, so edit­ing lat­er is point­less). Try­ing to parse a para­graph to extract data that can be com­mu­ni­cat­ed through a table of infor­ma­tion is a sil­ly prac­tice all around. Why spend all of a design­ers’ time writ­ing doc­u­ments (which the team then has spend time read­ing, digest­ing, and  imple­ment­ing), when the design­er could sim­ply wear a scripter hat and simul­ta­ne­ous­ly add new fea­tures via the data that is lat­er read into the game?

I used to attempt to boil my design doc­u­ments down to as many bul­let point lists, out­lines, and tables of data as pos­si­ble so that they rep­re­sent­ed game data more than a nov­el describ­ing the game… but this prac­tice only went so far. The nat­ur­al evo­lu­tion of attempt­ing to boil a design doc­u­ment down to (main­ly) bul­let point­ed lists and tables was, obvi­ous­ly, to turn these doc­u­ments into spread­sheets. If I under­stood code well enough to do so, I would sim­ply design games by writ­ing com­ments into our C++ code. (I’m the lead-ish artist, by the way, so code is not my territory).

In the long term, I plan to nev­er write a “design doc” again, unless it’s a 5‑page-max sum­ma­ry of the game’s core con­cept to kick off a project. Oth­er­wise, (as long as we are still using spread­sheet data­base CSVs), I plan to keep adding fea­tures and props by sim­ply adding spread­sheet columns. If we move away from that prac­tice, I think the only oth­er options for game design doc­u­men­ta­tion would be a data­base tech­nol­o­gy that can read  data­bas­es (XML or sim­i­lar) and direct­ly add prop­er­ties and flag them as unfin­ished, then allow the pro­gram­mer to look up all unfin­ished prop­er­ties at once. Or one could pos­si­bly use a wiki to cre­ate a non-lin­ear doc­u­men­ta­tion struc­ture for our designs. We exper­i­ment­ed with this briefly and it was work­ing fair­ly well, but requires a bit more effort due to the dif­fi­cul­ty of mak­ing changes to page names, etc. I still think this could work in spite of being a bit unwieldy, and obvi­ous­ly there is no way to export wiki infor­ma­tion into any form of script­ing data.

Any­way, we’ll let you all know when the data­base struc­ture is done-ish, since it would be an inter­est­ing post. FYI, Delver’s Drop can be eas­i­ly mod­ded by edit­ing these spread­sheets. We will even­tu­al­ly make all of them pub­lic for those who pur­chase the game, for mod­ding or just for ref­er­ence. http://delversdrop.com/preorder