I’ve been playing Warhammer 40K now for a few years, with my main activity being army building. That may seem a bit lame, but I find myself enjoying collecting, assembling, organizing, and painting an army somewhat more than I do actually playing the game. However, I do find that I have missed our Thanksgiving Apocalypse game, as it used to give me better opportunity to put the “organizing” part to work, which was always a lot of fun for me. When I built my first initial armies, I used spreadsheets, like many others, but, for me, it became very quickly apparent that Warhammer 40K really needs a database if you want a tool to do the heavy lifting for you.

The Spreadsheet

My Warhammer spreadsheet was pretty basic, and didn’t really have anything exciting to it. It was basically three columns – quantity, description, and cost, with a “sumproduct” over the quantities and costs at the end. It computed the final army cost, but you were required to fill in all the costs yourself. As a newcomer to the game, what I really needed was something to bring to the table to help me with all the little details after creating my army as well.

The Problem

I knew right away that this feature, “help me bring something useful to the table,” was not going to come from Excel. Specifically, I needed to know which models I was bringing to the table, what special weapons they had, what their stat lines were, and how much they cost so that I could add/remove/substitute things as needed. This last part was key, especially for the yearly Apocalypse game, because while the game was always planned far in advance, there was significant army mangling the day of the event as everyone figured out exactly what they had available and points were adjusted for each side so that things were at least close.

The Database

My initial stab at a database in Microsoft Access worked fairly well, and I used the reports feature to design some nice printouts for the game. I had the ability to print out a report that provided my complete army breakdown (listing each squad’s stats and cost, along with each piece of equipment and its cost), as well as some things that were more concise, such as a list of all the model-types in my army with their statlines on one page, and a list of all the equipment and its relevant information on another. These quick-references were invaluable to me as I learned the game.

One thing I didn’t count on, however, was the amount of data-entry that would be required to make this database function usefully. The database required every model-type, their cost, stat lines, and special abilities to be listed, as well as all the possible equipment and how much it cost. Since equipment costs, availability, and occasionally even descriptions varied by model-type, I had to create tables for these mappings and populate them with information from the codex. When my codex was updated, I basically had to wipe these tables and reenter it all again. I really wanted to crowd-source this part of the project, but I was never really motivated to do so enough to actually put out a call for work.

The other thing that always bugged me about my first database, was that it basically managed everything from the squad level rather than the model level (looking back, this feels a lot like maintaining collection level metadata rather than granule level metadata). That meant that if I wanted to organize my models in a different way, I basically had to construct a new squad and re-add all their equipment. On creation, this was actually intentional – I thought a lot about the reports I wanted from this database, but the only way I had to get information into the database was row-at-a-time creating and editing tables, so I wanted to minimize the number of records I would need to keep track of.

Noting the problems with my first database, I have since redesigned it. While my new design doesn’t solve the data entry problem, it does provide model-level management, and fixes some of the things that annoyed me about the old design (like the fact that infantry and vehicles were in two different tables, so anytime I wanted to create a report with both, I had to union the two – this was basically all the time). The main caveat with the new design is that it doesn’t really lend itself to direct table editing. While it’s totally possible to do, there are a lot more things to keep track of, and was designed with a UI in mind – a UI that I have yet to create. The main bottleneck on this front is that I haven’t yet decided whether I want a web interface or an application interface. The main hurdle to writing a web interface is porting the database out of Access (to something like postgres or MySQL), then writing the perl or php to make it happen. I’m pretty sure that I could tackle the perl once I had something to work against, but I haven’t really made the time to learn what I need to port the database…