Strategic Primer assistive programs development report and roadmap

It’s been a few 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 an update.

As usual, you can download new 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.


My work in this development cycle followed up on last month’s changes, but many were also prompted by my writing the second installemnt of the “tour of the code-base”, since I didn’t want to document an idiom there only to change it later.

One user-visible new feature that I should mention first is zooming. If you’re using a mouse with a scroll-wheel, you can zoom in and out by holding down Control (or Command on a Mac) and scrolling; whether you have such a mouse or not, you can also use menu items or the hot-keys Control- (or Command-) Plus and Minus. This is fairly rudimentary, and all it does is make the tiles’ visible representation bigger or smaller, showing fewer or more of them on the screen at once; even when each is very big, it only shows one of the things on the tile scaled up to that size, not (as you might expect) several things displayed at more reasonable sizes.

“Under the hood,” I substantially refactored the application model, moving toward each driver having its own “driver model” tailored to its needs but sharing as much code as possible, instead of working around the “map model” designed only for the map viewer.

I added a requirement to give usage information to the interface all the drivers implement, and started using that to improve the app-chooser class.

Previously any “Save” menu item was really “Save As,” since it didn’t know what file the map had been loaded from and you had to specify it again; I finally implemented a proper “Save” in the map viewer. (I still recommend putting anything you run this on under version control, as I do, just in case.)

Long ago, every tile displayed a tool-tip showing some information about it if you held your mouse over it long enough; I’ve added a similar thing back to the map viewer—but it’s implemented almost entirely differently. (As you’ll see in next month’s installment of the “tour of the code base,” I hope.)

There had been a half-functional MapUpdater driver that was supposed to update players’ maps with changes made to the main map; because it didn’t really work, and (more importantly) it added a significant amount of complexity to the model, in the classes where my static analysis tools complain most loudly about code complexity, I removed it.

I did some refactoring to make each Tile no longer need to know its location. This significantly improved the model, from a long-run perspective, I think, but it did have the side effect that (because the tile’s location is stored as part of it in the XL) it’s no longer possible to simply write a tile to XML.

I added a couple of rudimentary GUIs for formerly CLI-only utilities, checking maps for errors and seeing whether maps are subsets of a “main” map. If a user is just interested in the results, the GUIs may be somewhat easier, especially since they’ll eventually be available from the AppChooser (and are available using command-line options), and they colorize the output, but for working with the results the command-line versions are still better because it’s not possible to copy text off a label, which is what I’m using to display the output. (Because I can format it using HTML.)

I extended the build script to generate DMGs (Apple disk images); unfortunately, from what my one player who uses a Mac tells me, they apparently don’t work.

The last thing is a report generator, to take a map file and produce a report that a player might find more useful—listing more important things first, listing things by category, and omitting terrain information except where it’s most relevant (the surroundings of fortresses). This isn’t quite finished yet, as there are some more sections I want to create, and the whole thing is far too complicated, but it’s mostly done.


The “roadmap” of planned features is still largely unchanged.

One item, however, is definitely new (in at least this version of the list): finishing the report generator, and most of the remaining holes in the table of available drivers. That includes what was third on last month’s list, “a proper app for players to use for worker management.”

Other than that fairly general priority, 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).

Another 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.

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.

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.


2 thoughts on “Strategic Primer assistive programs development report and roadmap

    • That tarball includes the source, the compiled class files, the built Javadocs, and the build apparatus … basically what you’d get if you downloaded the repository at that particular revision and ran “ant build doc”. It’s provided so a user doesn’t have to use Mercurial, or interact with the source repository at all, to start working with the source.

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