Strategic Primer assistive programs development report and roadmap

It’s been quite a while since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, and in that time there’s been a great deal of progress to report.

As usual, you can download the new version from Bitbucket, and if you want to know more details than I list below, you can see the full history in the Mercurial repository.


Most of the changes have to do with one of two things: worker stats, and the worker management GUI.

You may recall that my last list of changes ended by mentioning a program to let me enter worker stats. I continued to improve that (at the time I’d forgotten to make it write the stats back to the map file, for example), and I added references to worker stats to various places across the suite, including the report generator. I also made most places using worker stats describe them in terms of the modifiers they offer, rather than the raw numbers.

The other big item is a new “app” in the suite. (I intend to write a “user’s guide” for it next week.) This application lets a player manage his or her workers (reorganizing them among his or her units), record orders for units, and export a “proto-strategy” containing those orders. It also displays an abbreviate version of the player report (omitting the player’s own fortresses and units), for the user to refer to while drafting the orders.


It isn’t all that urgent, but now that Java 6 is end-of-life, I’m thinking seriously about bumping the required JRE version to Java 7 so I can use new features like the diamond operator and the try-with-resources statement. If you use these programs and you still only have a Java 6 JRE, please let me know.

The first thing I’d like to get to is reworking the worker-advancement GUI using the tree component I used in the new worker management GUI.

With it now possible for players to make changes to a known-world map and send it back, changesets are becoming somewhat more urgent.

Fairly soon—before the current API gets even more deeply ingrained—I want to properly implement and switch to (once I’ve demonstrated it won’t lose data) the new map API I developed a while back. Among other reasons, this should make implementing changesets somewhat easier.

Another fairly urgent item is “resource management,” eventually including resource production and resource storage accounting.

In response to player requests, I’d like to either make the “Z-order” (which determines which fixtures are “on top” of a tile) configurable or allow the player to turn off the display of some kinds of fixtures in the map viewer. I also intend to let fixtures have custom images (different icons for different kinds of units, for example). And I hope to add larger images (“portraits”) for units and some other kinds of fixtures.

Among other planned features.

If you have any features you’d like me to add, or you run into any problems with the software, please let me know—perhaps using the issue tracker.


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