It’s been far too long since my last blog post. To say that things have been busy, both within and outside Brick Mill Games, is an understatement. For this blog post, however, I will stay on topic and only talk about what Paul and I have been working on.

Correctness is Key

Regular readers (do we have any?) may note Brick Mill’s fixation on having correct data. Incorrect data is the domain of game errata. If you have incorrect data, be they unit strengths, unit identifiers, map terrain, hex numbers, rules abnormalities, incorrect colors… then you will have a flawed product. Having been on the inside of a few game development projects, I can see where errors and inconsistencies can lead to game errata.

For instance, with its reliance on the graphics arts and their tool domain, fixing unit strengths becomes a painstaking (for me anyway) walk across an Adobe Illustrator file to find all of the similar units whose combat strength values need an update. And, worse, some games have unit strengths on both the front and back of the counter. Did the designer find and adjust all of them? If the primary source of data was a spreadsheet, then finding and fixing the non-graphical aspects of the game becomes a simpler problem.

Similar issues exist for rules. I was a playtester for one game where a suggestion to move a rules section from one part of the rules to another, more accessible area, was met with an emphatic, “No.” Why? Because moving the rules section would involve changing all of the indexing and cross-references for multiple rules sections. And if your rules writing tool is a word processor or page layout tool, managing this metadata becomes a time-intensive process.

Maps are easier in one sense, but difficulties exist there as well.

It’s All About the (Meta)Data

One concept that has worked well within Brick Mill, and has been used to assist outside projects that I’ve worked on, has been the use of spreadsheets to manage the unit manifests. Data there can be more easily managed as playtesting reveals irregularities in the unit properties. If your pipeline can support a spreadsheet -> graphics transition, then unit counter management and generation becomes a snap.

Over the past couple of months, Paul and I have been working on other data transitions. After using Apple’s Pages application for our rulebooks, charts and such, we discovered a similar data management problem. Managing rules edits and cross-references became a major version control and data management problem. Reviewing rules for correctness is one thing, but handling the management of metadata and change tracking was eating up our time.

Our solution was to convert our rulebooks, scenario books and charts to a master XML format. At the cost of not being able to use a “look & feel” application, we gained the following abilities:

• text-based file version control using git
• easy viewing of source differences using text-based “diff” tools
• section identifiers and cross-references handled using XML tags instead of hard-coded numbers

Once I wrote an XML -> HTML converter (a PDF converter is on our long-range TODO list), we could read and use our rulebooks in the browser and cross-reference were now a hyperlink click away. No more scrolling back & forth through a generated PDF during game play. This has allowed us to streamline our rules & playtesting development process.

Do Maps Need Metadata?

In a paper-published world, map generation does not need metadata. Maps do not need to be updated as much as rules and counters are. They must still be reviewed, but usually, aesthetically, the map designer is working to match a particular source map. Added features like game-related symbols do need to be reviewed, but the density of such symbols over the whole of the map usually does not warrant any specialized data-driven approach, even without taking into account that maps are much more complex when comparing the aesthetic vs metadata ratio.

However, computer-driven wargaming requires metadata. Well, “requires” may be a bit of a stretch. It really is determined by what level of computer-driven we’re talking about.

For example, Vassal is a nice computer-aided wargaming tool. It is most certainly not a game engine, though. It is, simply, a graphics object manipulation program. You move unit and marker graphics objects on top of other graphics objects, such as maps, charts, etc. As such, there are thing you cannot do in Vassal, such as trace a 6MP supply line where MP costs differ from hex to hex based on the terrain therein. Hex ranges are supported, certainly, but not anything based on information that the wargamer sees when they are using the underlying map.

Game engines/clients need metadata. They need to trace routes as a wargamer drags a unit from one hex/space to another. They need to check for illegal moves. While Vassal will allow a player to move the 21st Panzer Division from Calais to London without so much as a peep, full computer-driven game clients will not allow such a move as the metadata will not support it.

Paul and I have been working metadata support for the maps the we’ve already developed. The metadata for each map consists of a spreadsheet of encoded text which describes the hex and hexside contents of the hex. This data is then loaded into the editor and checked for syntactic and situational correctness. The map editor then shows the results of the metadata as a visual representation of the map as the metadata describes.

In the example above, the village of St. Baussant is shown in the center of the before / navigation pane and in the center of the close-up / editing pane. Surrounding terrain can be seen, shown here as elevation changes and contour lines, elevation values, villages (with names), farmland plots, woods and forest coverage, as well as streams, ponds and lakes. Note that unlike most wargames, each TOCS hex contains three “tiles” of terrain to move within and through, hence the mixed items and orientation of terrain in each hex. (Yes, this does make the metadata language a bit complex.) Note that this is still an early version of the tool; roads, for example, are not shown.

The ultimate goal of this is two-fold. First, this tool shows the map designer what the game client will see when it reads and analyzes the map metadata. Using this metadata, the game client will help the player move across the map and avoid bad terrain and/or show illegal moves as the player attempts to move a unit across such terrain. Player forgetfulness of terrain costs is removed, an especially necessary function when games are played double-blind.

The final goal of this is to do with maps and map design what was done with unit counters. The metadata, combined with a set of palettes, will define the map. With the right set of palettes, different representations of maps can be generated. Seasonal representations become possible with the same metadata. Different styles also become possible as map drawing palettes can be designed and used that mimic one’s favorite wargame artist.

As always, though, reliance on correct data minimizes errata, if not remove it entirely.