Strategic Primer assistive programs development report and roadmap

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

This month’s changes include a new GUI you may find useful (though getting to it from a packaged version may be tricky, I’m afraid … see the first item on the roadmap below), and a couple of handy new features in the viewer, so you’ll likely want to download a new version.

For more details, you can see the full history in the Bitbucket repository.


The main focus in this development cycle was automating the most tedious parts of worker advancement. (In this development, I’ve ignored the half-formed ideas for revising the model I described in these two posts … time to take another look at that, I suppose.)

First I created a command-line interface that went over each worker in each of a player’s units in a map and let me say how many hours of experience to add. But that was still quite tedious, especially since the text it had to print before each prompt (to explain how to use it) cluttered the output a lot.

So next I developed a GUI. It shows a list of the selected player’s units. When a unit is selected, it shows a list of that unit’s members; when the selected member is a worker, it shows that worker’s Jobs; when a Job is selected, it shows the skills in that Job; and it lets the user add hours of experience to the selected skill. Getting this usable was tremendously challenging (both of my first two attempts at automatically selecting a reasonable default in a list consistently crashed the application, probably due to some Swing concurrency issues, for example, and I’m getting tired of the limitations of Swing’s layout possibilities), but once I had it in a usable state I was able to finish a player’s long list of workers in a few minutes rather than the hours it would have taken by hand.

I mention this “advancement” view in such detail because, while it’s mainly useful for advancement, and so primarily for me rather than the players, it can be used by players to see the skill levels of all their workers (once I’ve added that information to their maps). I hope to develop a worker-management GUI that’s more useful to players in the future, but this may be useful until then.

I also did quite a bit of refactoring of the exploration application I created in the last cycle, including fixing a nasty bug that allowed a worker to cross an ocean tile if it had a hill or a forest (of mandrakes or kelp, for example), and automatically selecting the only player in a map and the only unit belonging to a player rather than prompting the user in those cases. And I allowed the user to select a unit that’s in a fortress (though it might not actually move in that case …).

I added some new features to the viewer. First, when scrolling using the arrow keys, you can now press the Control key (maybe the Command key on a Mac? If you use the application on a Mac, please let me know, so I can document this properly!) at the same time as the arrow key to scroll by up to five tiles in a direction rather than just one at a time.

Second, I added a “find” command, which allows you to search for fixtures on the map by their ID number (if you happen to know it), their name (if they have one … units, workers in units, fortresses, cities, towns, and villages do), or their “kind” if they have one (units do, as do fields, forests, groves, orchards, mines, mineral deposits, and the like; a worker’s race—human, elf, etc.—is also included). By user request, you can also search backward rather than forward, and/or vertically (down or up) and then across rather than down, and the search is incremental from the currently selected tile.

Most recently, I did some refactoring of the build mechanism, including renaming the targets, building the Mac app in the same “step” as putting it in a “tar” archive, building documentation, and making a “source-and-all” archive, among other things … so please let me know whether this week’s release works for you.

Most of the other changes have been refactorings and other utterly “invisible” revisions and adjustments to the code and the data structures. As in the last cycle, I had intended to suspend development until I’d finished running the current turn, but I again grew exasperated with the tedium of running things using just the viewer.


The “roadmap” of planned features is still largely unchanged, and still on hiatus until I finish running the current turn—before my next development report, I hope, though we’ll see.

The most urgent item is to add a way for the user to select which application he or she wants to run, since Java “applications” that have been packaged up automatically run one “main” class. I have some ideas on this front, but not much time at the moment.

Other than that, the first item is still fixture editing and UI support for unit details (basic model and I/O support for them having been added earlier). I have some ideas of how to go about these, and just need to buckle down and implement them. As part of this, I need to be able to move workers from unit to unit in the advancement GUI and add new workers there (it’s already possible to add Jobs and skills to a worker).

The second item I’d like to get to is changesets. They, too, would make running a turn easier, once some additional code was added, and they would also make it easier to report to a player what of substance an explorer discovered. But, like I’ve said before, I don’t really have a good idea of how to go about implementing them, so they’ll probably just sit for awhile longer.

Another major item, which I think may be the first I get to, is the interface revision I talked about a few months ago. (See that post for more details.)

A player has asked for a way to get a list of items “of interest”; one way to do that is 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. The “find” dialog helps here, but doesn’t entirely solve this request.

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.

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