Strategic Primer assistive programs development report and roadmap

Screenshot of the latest version showing the new detail panel

It’s been nearly a month since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, so it’s time for an update—and there have been several major changes.

The first change, and one of such importance that I’m putting it “above the fold,” is that development has moved from Launchpad to Bitbucket (that link is to the repository), and while I’ve updated the binaries on Google Drive (formerly Docs) the Bitbucket downloads page is now their canonical location; future updates likely won’t go to Google Drive.


First, as I mentioned above the fold, I moved development from Launchpad to Bitbucket; with that came a move from Bazaar to Mercurial. Truly distributed development should be much easier now, and in addition Bitbucket provides an area for downloads (as I mentioned, and more about that later), an issue tracker (which I suggest using if you encounter any problems or have any ideas or suggestions), and a wiki (which I’ll get to eventually …)

Second, as part of preparing this report, I revised the build file to make it produce versioned binaries. As of this writing, the current version is 0.4.1603. (The last number is the Mercurial revision number, and so will continue to increase regardless of bumps to the minor or major number; also, by the way, I picked 0.4 because we’re a bit beyond dismayingly-incomplete 0.1, but nowhere near quasi-stable 1.0.) If you want to build the code from source, you’ll probably need to edit to change the location of Launch4J, the directory of the project itself, and (unless you’re running Gentoo Linux) the JUnit and Hamcrest JARs (for the tests).

Third, I replaced the “detail panel,” which showed the contents of the currently selected tile using “chits” that could themselves be selected to display their description, with a more straightforward panel using a standard list control—which shows the description without the fixture having to be selected, and allows multiple fixtures to be selected at once. Implementing this properly (between showing the full text of each description, no matter how long, without using more space than necessary, and handling drag-and-drop between the panels representing the tile on the main and secondary maps without allowing the fixture to be dropped on the component it came from) took a great deal of effort, but it’s conceptually quite simple (with only a couple of hackish bits) and (the primary advantage from my point of view) doesn’t require me to do something to that code every time I add a new kind of thing that can be on a tile.

Other changes were mostly warning fixes and other cleanups.


The number one item on the roadmap is unit details and fixture editing. I have some ideas of how to go about these, and just need to buckle down and implement them. These head the list because they should make running the current turn in the campaign much easier. (For my own reference, I note that I hope to make some way of defining unit types and referring to them later.)

I’d like to either write a new (i.e. yet another) XML serialization layer—I’m fairly satisfied with ReaderNG/WriterNG, but to help ensure correctness I always maintain both the current and the previous XML serialization layers, and SimpleXML (the currently deprecated one) requires a Node class for every XML tag a map can contain (though similar-enough tags, like meadows and fields, can share a class), as well as requiring an extra method in each class that is serializable to XML. Having to deal with that hassle is part of why I’ve been stalling on implementing unit details, since while I can leave them entirely an implementation detail not shown to the user in the UI (as how to show them in the detail panel is another frustrating problem that I’m not looking forward to trying to solve), they have to be written to and read from XML to be useful at all. My first attempt at a new serialization layer utterly failed; I have a few other vague ideas, but nothing concrete yet.

Another big item I’d like to get to is changesets. They, too, would make running the turn easier, once some additional code was added. But, like I said in my last report, I don’t really have a good idea of how to go about implementing them, so they’ll probably just sit for awhile longer.

I hope to add a “find” feature, so players don’t have to search the (increasingly “busy”) map by scrolling.

I hope to add larger images (“portraits”) for units and some other kinds of fixtures.

And I hope to let fixtures have custom images (so that different kinds of units use different 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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.