Spreadsheet Game Design
How Making CSV Databases Changed Our Design Process
This week I’ve been frantically trying to finalize some of the database structures so that I can (hopefully) move off of databases completely, and work only on art. I say databases, because all of our game’s properties, stats, effects, etc are produced by creating massive spreadsheets that are exported as CSVs and packaged with the game builds. I will probably never be totally rid of these spreadsheets (in terms of my workload) — but it’s really nice to feel like I’m almost done with the design work required to set them up.
In writing this, I’ve just realized that our design process has moved almost 100% from writing game design documents (which I have always thought of as an outdated process anyway) to doing game design entirely via spreadsheets. More specifically, we use Google sheets, so the entire team can edit them at the same time.
Spreadsheet designing may seem odd, but think about it this way: if the spreadsheet databases contain all of the properties that can make a game entity behave in a certain way, then all we need to do to design a new property is add that property to the sheet, give it a description, and mark it as new. Then at some point our programmer will be going through that database, adding support for any of these new / unsupported features. Another beneficial byproduct is that the designer / scripter can create data for this property before it’s even been programmed (as in the image below), so that the moment this feature comes online it can be tested.
I won’t say it’s the the absolute end-all-be-all best practice, but it has been working for us. Either way, design documents are dead to me, and have been for years. Using a linear documentation format (game design docs) to design a non-linear experience (a game) is a fool’s errand. It is impossible to organize perfectly, leads to redundancy when writing, necessitates editing in multiple places when any change is made, and causes miscommunication with the team (none of whom read it more than once, so editing later is pointless). Trying to parse a paragraph to extract data that can be communicated through a table of information is a silly practice all around. Why spend all of a designers’ time writing documents (which the team then has spend time reading, digesting, and implementing), when the designer could simply wear a scripter hat and simultaneously add new features via the data that is later read into the game?
I used to attempt to boil my design documents down to as many bullet point lists, outlines, and tables of data as possible so that they represented game data more than a novel describing the game… but this practice only went so far. The natural evolution of attempting to boil a design document down to (mainly) bullet pointed lists and tables was, obviously, to turn these documents into spreadsheets. If I understood code well enough to do so, I would simply design games by writing comments 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 never write a “design doc” again, unless it’s a 5-page-max summary of the game’s core concept to kick off a project. Otherwise, (as long as we are still using spreadsheet database CSVs), I plan to keep adding features and props by simply adding spreadsheet columns. If we move away from that practice, I think the only other options for game design documentation would be a database technology that can read databases (XML or similar) and directly add properties and flag them as unfinished, then allow the programmer to look up all unfinished properties at once. Or one could possibly use a wiki to create a non-linear documentation structure for our designs. We experimented with this briefly and it was working fairly well, but requires a bit more effort due to the difficulty of making changes to page names, etc. I still think this could work in spite of being a bit unwieldy, and obviously there is no way to export wiki information into any form of scripting data.
Anyway, we’ll let you all know when the database structure is done-ish, since it would be an interesting post. FYI, Delver’s Drop can be easily modded by editing these spreadsheets. We will eventually make all of them public for those who purchase the game, for modding or just for reference. http://delversdrop.com/preorder
Pingback: How Pixelscopic Dumped The Game Design Doc Process | IndieHangover
As a game designer, I couldn’t agree more! I find that “game design documents” rarely tell the art team or the programmers what they really need to know. It’s only really good for getting publishers, clients, or backers onboard. I find spreadsheets much more practical in actually designing game systems and conveying that information to the team.
I myself have been moving towards Google spreadsheets lately, as I find it a really elegant and quick way of manipulating game data. I still believe some basic documentation on features like AI behaviour or GUI functionality should be in place (for which we use our internal dokuwiki), but faor anything that can be expressed via sheets, I 100% agree that it’s just better.
The best thing about your use is that you use one row for keys by which the game reads the cells. I was thinking I would export to a CSV and read the data sequentially, but your approach is 100% better and more flexible.
Thank’s for the great ideal. One of the hardest parts of starting a project for me has always been trying to write what I thought was a ‘good’ design document for whatever ideal I am working on. This will benefit me greatly on not only the design side but in the actual development side as well.