Strategic Primer assistive programs development report and roadmap

It’s been four weeks 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 another update.

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 or look at the task tracker.


One early minor change that you might notice is that the “app chooser”—the first window you’ll see unless you specified a particular “app” using a command-line option—looks a little better, with the buttons all now of uniform size.

In the worker-advancement program, I replaced the lists of a worker’s Jobs and Skills with a tree. While this does remove the nice accidental feature that as soon as the user selected a worker the first Job and the first Skill in that Job would also be selected, this gets rid of a fair amount of code that I consider “brittle,” and it should improve usability slightly for cases other than that “optimal” case.

I think I’ve mentioned in the “roadmap” a hope to support custom icons for individual fixtures. And I finally implemented that in this cycle: an image filename can be specified in the map file, and will be preserved across loading and saving. If the image exists, it will be used to represent that fixture. But I’m not sure I have the fallback behavior (that, if the image doesn’t exist, the default image for that fixture type should be used, not the image that’s used when that doesn’t exist) quite right.

I added some classes to let me lay out panels in a more functional style: a panel that uses a BorderLayout and takes the components that go on the various “borders” as constructor arguments, for example.

I added a button to the worker advancement program that lets the user create new workers. This should make my job of running strategies, which includes creating (in some cases large numbers of) newcomers, much easier.

Villages now have a “dominant race,” which should be mentioned in players’ reports. As I mentioned earlier, recruits from a village will most likely be of its dominant race. And if a village doesn’t have a race defined, the program will decide one for it “at random” using its ID number as the random seed (so not really randomly at all).

Lastly, the biggest new feature in this release is filtering of the view, and of search results, in the map viewer by “kind” of fixture. If you deselect, for example, “Animals” in the new Display menu, you no animal will appear “on top” of a tile. (They’re still there, and will appear in the tile-details list, of course.) Similarly, if you deselect everything but “Units” in the new list in the Find dialog, your search will only find units.

Most of the other changes are warning fixes and other cleanup.


At the top of the roadmap (now that I have one that’s not just in my head, namely the Pivotal Tracker backlog) are a couple of interface issues, one somewhat simple, the other quite complex. First is to make the apps a proper MDI application, with a Window menu keeping track of the windows and their status. And second, for users running Mac OSX, I want to improve the program so that each app behaves like a proper OSX app, adhering to the human interface and design guidelines. But these will take much thought, since my first “plans of attack” have foundered.

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.

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

As one player asked, I want to make it possible to collapse sections of the report in the worker management program, and also to organize units … perhaps by somehow making the organization it implicitly provides (by unit “kind”) explicitly visible.

I want to write programs (just command-line interfaces for now, I think) to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting. 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 )

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