Strategic Primer assistive programs development report and roadmap

It’s been an eventful month 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 an 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.


After the addition of the worker-advancement GUI in the last cycle, this month I mainly worked on improving the packaging and polishing some rough edges throughout the whole suite.

I started with one little usability issue: most applications let you press “Enter” after entering something in a form’s text box to submit the data, but none of the text boxes in either of the applications here did that. No longer; I went through every place I could find the “enter in text box, press OK” pattern in the code-base and added this subtle feature to each one.

Another item that came up was that the arbitrary-text “find” didn’t find a stone deposit if you searched by what kind of stone it was. The reason for that was buried deep in the model, but it was fairly trivial to fix.

The first big, major change in this cycle was the addition of a GUI to let the user choose which application he or she wants. You may recall that this was listed as the “most urgent” item on last month’s roadmap; it took a lot of work to make it work, but I eventually managed it, and that “chooser” application is now the default main class in released binaries. Note that if you want a specific app, you can specify it via a command-line option (though those aren’t documented yet). I considered this so major an improvement that I made a mid-cycle release just a couple of weeks ago including it.

Following up on the effort I did for that, I worked to change the map viewer from a single-window app with a main map and a secondary map, transferring data only between those two, into a “multi-document interface” that’s more consistent with the way other desktop applications work. I made it possible to drag and drop tile fixtures from one window to another, after dropping the notion of the “secondary map” entirely. (That was somewhat tricky.) Then I started reorganizing the menus, and made it possible to close one window without quitting the whole program. I added a “new” option to the viewer, to opena new map (of the same size as the current one) in a new window.

As part of fitting in better with other applications, I changed all the hot-keys from “control-O” (for example) on all platforms to “O-plus-the-appropriate-modifier.” If you’re using the program on a Mac, you should find the hotkeys properly associated with “Command+key” now. I also changed the “go to tile” hotkey from “control-G” to “control-T” (or “command-T”), since “command-G” is the standard keystroke for “find next” on a Mac. (Unfortunately, it’s not possible to set more than one hotkey for a command in Java without a lot of effort and a highly brittle workaround, so I had to choose between the current vi-like set of hotkeys for searching and Control-F and control-G … and the vi interface stays.)

The last major item is one suggested by a user, that I’d thought idly about before but had never looked into. I thought it would be tricky, but when I started searching it turned out to be quite easy. It’s now possible to scroll the map window in the viewer with your mouse wheel, if your mouse has a scroll wheel. If you’re not pressing any modifier keys, you’ll scroll up and down; if you hold down Shift, you’ll scroll left and right. (Scrolling while holding Control or Command will eventually control the zoom level, but that’s a long way off—but that’s why scrolling with the mouse wheel will currently have no effect if Control or Command is held down.)


The “roadmap” of planned features is still largely unchanged, but the “hiatus” is tentatively over; while I haven’t finished running the turn, the last player’s strategy, rather than my own work on producing results, is what that’s waiting on.

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.

A third item is a proper app for players to use for worker management.

Also, now that I can (to some extent) manage workers, the next step is to get resource management (eventually including resource production and resource storage accounting) into the map model.

Once the model supports more worker details than just Jobs and skills, I need to create a proper worker-generation program; I started with PCGen, but when it got really, really slow with fortress populations (from its perspective “party sizes”) only in the thirties, I switched to a shell script I wrote that just generated stats. Since I want more details than that, I need to write a program to produce them.

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.

Another player has asked for a way to zoom in and out; this will probably be quite tricky, but it should be possible.

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.