Strategic Primer assistive programs development report and roadmap

In the month or so since the last development report, I’ve made significant progress in the development of the suite of assistive programs for players and Judges of Strategic Primer. If you’re still using an older version, I encourage you to update to the current version (source on Launchpad for now on Bitbucket; binaries—for Windows, for Mac, and cross-platform JAR—on Google Docs for now also on Bitbucket). And for once I can cross several items off last month’s roadmap.


The first major change was a significant expansion of the XML I/O test suite. (Saying that I “finished” it would feel like tempting fate, and isn’t quite true, as I keep extending the format that’s being tested.) Following that, I brought the new ReaderNG framework up to feature parity and made it the default. Based on the results of my tests, it appears to be much faster.

I also continued improving the XML format and the model it represents. All towns, villages, and so on can have names (and warnings are issued if they don’t), and (as I mentioned in last week’s post) nearly all fixtures have unique IDs.

Because I still had some old map files lying around in the obsolete version 0 format, I hacked together a program that converts from it to the version 1 format; version 1 is deprecated, but the viewer is at least still able to read it.

As I mentioned in my post about software testing, I ran into bugs in HashSet and TreeSet that were causing fixtures to be lost. I tweaked the tests to figure out the cause of the problems I was seeing, then worked around the bugs in the SDK.

I improved my “subset driver”, which tells me whether one map (a player’s map, for example) is a “strict subset” of another (usually the current main map), largely by adding more exceptions to how strict a subset a map needs to be to qualify.

I mostly implemented support for the <include> tag; the readers now handle it fine (though I implemented this at the level of the “XML events” themselves, not in the readers that parse those), but there’s no way to write a multi-file map back in more than one file yet. To let me test this, I added a hack to both readers: when a “filename” consisting of “string:” followed by XML code is passed to them, they read the XML code from the “filename” itself rather than opening the file it purports to name. And while the readers support indefinite levels of inclusion, I’ve unfortunately found no way to prevent infinite recursion.

And I fixed large numbers of warnings and a few other minor code-quality FIXME and TODO items.


I have several hopes for the next while:

First, I hope to find (or be pointed to) images for my remaining icon needs. (See this earlier roadmap for the list.)

Second, as I mentioned last week, I plan to add “sub-maps” for individual tiles, to be loaded from and saved to separate files, in preparation for reducing the map’s resolution.

Third, I hope to continue the XML vocabulary standardization and improvement (owners for most fixtures, unit details …)

Fourth, I plan to implement editing of features.

Fifth, I hope to add a “Find” option.

And sixth, I plan to add larger images (“portraits”) for some kinds of fixtures (units, possibly cities, perhaps animals), and more generally the ability for some fixtures to have custom images and icons.

Among other planned features.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s