Strategic Primer assistive programs development report and roadmap

In the weeks since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, there have been a fairly large number of mostly minor changes.

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


The bulk of the changes in the past month-and-a-bit seem to have been warning fixes and the like: declaring parameters and variables by their interface types (and extracting interfaces, for this and other reasons, which I’ll get to below) rather than specific implementations, reducing method length and cyclomatic complexity, and so on. Some of the remaining warnings can’t really be fixed using the standard library’s collection classes, so I’m considering using Guava. I also ran a “dead code detector” a few times, and was able to remove a few pieces of code that are no longer used.

In the past couple of weeks, I resumed work on the new map API. The second reason (the reason other than that static analysis tools often ask for it) for extracting and using interfaces rather than specific implementations is that this made it possible to write a class that implements the same interface as the map and map-view classes that everything now uses but that has a new-API map inside for storing the data. Now, none of this new code is ready for real use yet; there’s no way to even create a non-empty map, there is no test code, and there’s no XML serialization code. But I consider this a very good start on one of the more pressing items on the roadmap.


The list of “planned” features (which has debatable correspondence with the Pivotal Tracker backlog, remains largely unchanged from previous months.

The first item is to make the apps a proper MDI application, with a Window menu keeping track of windows and their status, and to make them behave like native apps (following human-interface guidelines, etc.) on the major platforms, starting with Mac OS X. But because my first attempts failed, I’m still at a loss as to where to begin.

Second, with it possible for players to make changes to a known-world map using the “helper apps” (rather than just a text editor) and send it back, changesets need to become a priority.

Third, I want to “finish,” test, and switch to (once I’ve demonstrated it won’t lose data) the new map API; this may make developing changesets easier, and it’s possible it’ll bring performance improvements, but we’ll have to see.

Fourth, I want to write programs to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting.

That ties into the fifth item on the list, “resource management,” eventually including modeling resource production and resource accounting.

Sixth, 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 or contacting me directly.


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.