Again, it seems too long between posts, but I have some news to report, and mightily bored you might be reading about it… but here goes. As mentioned before, we had finished implementing the GameBox metadata that describes the AttM (Advance to the Moselle) and OMGN (Operation Market Garden – Nijmegen) game modules, by defining the game constructs in XML. When you think of a game, you think of campaigns and scenarios that have a bunch of rules that define the time it starts, how many turns until it ends, where do you setup, what forces do I start with, which is a lot to go through before you get to move that first piece. The advantage of a ‘computerized’ game system is it allows the game system to assist making things easier, hopefully much easier. It does this through metadata descriptions that drive the behavior of the game module, essentially making it data-driven by following a defined set of rules. To cover all aspects of what game modules might include, this rule set became large, requiring us to write the Wiki Design Specification, so that we followed our own rules when creating Game Modules.

But who’s to say we wrote those GameBox rules correct, or consistently across scenarios or across all Game Modules. Here is where the GameBox metadata schema comes into play. It is a set of ‘rules’ that checks the GameBox metadata to enforce consistency. This XML schema and a rule enforcer (script) was added into our development pipeline so that each time the Game Module is built, the rules are checked for validity. If we make a mistake, we will know it the very next time it builds. This follows the “break it early, fix it early” philosophy of Agile development.

The schema ensures that all of the GameBox metadata adheres to the Wiki specification for all scenarios, for all Game Modules. It was even extended to the UB (Utah Beach) Game Module, that is currently in development but not yet completed. All modules today build error free, which is a good thing. It is a good thing, because software that reads the metadata is guaranteed that it will be ordered a specific way and that each section adheres to the design spec. This should help standardize the code that interprets the metadata elements, attributes and values.

Although this may seem boring and tedious, it should pay off in the long-run by making Game Modules that are well written and behaved. It also adds an important validation tool needed for folks to author a Game Module that would be licensed and run on the TOCS server. Ultimately we would want to provide a complete toolset and automate the GameBox.xml including a friendly GUI Module Builder utility, but until that time, this will keep developers from going off the tracks. Boring… perhaps, but an important part of the infrastructure needed to create consistent Game Modules. However, watching the build process produce a message saying “the GameBox had zero errors” belies the amount of work that went into producing that message for all three Game Modules. That will be left to the imagination of the reader…