Once again, Paul and I had to extend one 3-week sprint into the next one due to outside influences. Unfortunately, this is what happens when you’re trying to balance day job needs with trying to get a new company off the ground.

Truth be told, we were both trying to burn the candle at both ends. We were play-testing the game system and trying to develop the TClient application to facilitate online game play. Personally, I had a hard time doing this. I wasn’t able to focus on game client software while also trying to juggle version control for the rules, charts and what-have-you required to play a game. Our Vassal module had these charts embedded, but they were obsolete and neither of us wanted to spend time updating the module.

Partway through the sprint, I abandoned the game software epic to focus on the development of the TOCS game system and its infrastructure. I wound up converting all of the rulebooks and scenario mission briefs from Apple’s Pages format to XML, then built a Ruby script to generate cross-referenced HTML from the XML source documents. The results were dramatic. We can now use our browsers to navigate through all of the rules and charts w/o relying on obsolete information in Vassal nor scrolling wildly through the PDFs we were generating. An additional benefit is that, since XML is a text-based coding format and not a binary format, our source code control system can show the textual differences between versions as we make edits. It is improving our productivity, albeit against the cost of immediate word processor feedback.

One such benefit is the lack of hard-coded footnote and rules cross-references. Instead of typing (3.2) in the rules, our documents use an xref tag, such as <xref ref=”Night Rules”>. This tag will reference a rule by heading, not by numbering within the rules hierarchy. The result is that we can move entire rules sections around without having to retype and re-cross-reference by hand. The process is automatic. When the HTML is generated, the cross-reference will be an internal link to the rule, written as the rule number. As the numbering system is not hard-coded, but generated internally by the script, it all just works. External document cross-references are possible as well, but I haven’t written that support as yet.

Our charts have also been XML’d as well. And finally, all separate rulebooks and charts can be collected together into player documentation packs tailored to each game module & scenario. This will make our playtests more productive.

All this work has come at a good time. Paul and I are preparing our next playtest. We have numerous rules edits to make based on our past experience. Plus, we’re looking at some additional tweaking of some of the systems based on that experience.

Map Metadata

The map metadata project has slowed, again, due to outside influences. We’ve discovered that entering metadata by hand is error prone. There’s a lot of information to be entered and checking for the accuracy of that information is difficult.

To try to address that, I created the TOCS Map Metadata Editor using HTML/CSS/Javascript technologies during a creative burst of energy. (I’d recently completed a day job milestone.) When it is fully feature-complete, it will allow a map designer to enter the metadata for a map hex and see what it would look like within the context of other hexes. It will also validate the data to make sure that no errors creep in. Right now, it can read/save files, allow hex data editing and do data validation. Drawing the hex based on the metadata is forthcoming. Again, this will allow us to be more productive by using better tools.

Summary

In between all of this, we’re also analyzing our combat tables and creating a private wiki to track internal information and a raft of other things.

In summary, while we’ve been quiet, we’re certainly not inactive. Stay tuned.