Strategic Primer assistive programs development report and roadmap (#29)

In the month and more since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, there’s been fairly few noteworthy developments, but it’s time for a new release and report anyway.

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 my effort on the software in this period went toward porting to Ceylon, starting with the sections of the code least intertwined with the rest. But as I’m developing the Ceylon implementation in a separate repository, none of those changes should be “user-visible” until I finish the port.

The only two really notable changes were very minor features: first, that when an exploration program moves a unit through a tile near another unit or a town or village that belongs to another player, the program will print a message indicating this. And second, in the program that generates workers’ “stats,” I made the branch of the program that puts new workers in an existing unit offer to load worker names from file just like the branch that puts them in a new unit.

I also tried to fix some things that have never really worked with the “Window” menu, but to no avail.


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 behave like native apps (following human-interface guidelines, etc.) on the major platforms, starting with Mac OS X. I’ve made something of a start on this, but getting any farther will be tricky.

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. I started writing tests for the new API this month, but I disabled them because they require XML I/O to be in place.

Fourth, I want to write programs to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting—the latter three are much better now, but how much meat any given animal produces, for example, still has to be looked up by hand.

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.

Seventh, as I mentioned earlier, I want the mine-model-generation program to produce something suitable for stone deposits as well.

And eighth, I want to make some way of recording fixture ID numbers as used in player maps without actually adding fixtures (or the file-size that fixtures take up).

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 )

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