Strategic Primer assistive programs development report and roadmap

It’s been almost a 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 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. I should also mention that I’ve started using Pivotal Tracker again, so if that trend continues you can follow my progress in the “SP Helpers” project.

There is one “above the fold” change: these programs now require Java 7, not merely Java 6.

Changes

The most significant changes in this release came toward the end of the cycle. To begin with, as I mentioned above, I bumped the Java version requirement from 6 to 7, and went through making the improvements that this enabled: “diamond” operators, but especially the “try-with-resources” statement. (Unfortunately, one of my static analysis plugins doesn’t know about that yet, so I had lots of “unused imports” warnings from it until I turned that check off.)

Beyond that, I fixed one of the major limitations of the worker-management app I introduced in the previous release, that it only let the user work with the units belonging to the player the map thought of as the “current player.” It now has a menu item that, when selected, prompts the user for a different player.

Because the worker-management app and the worker-skill-advancement app share menu code, the latter also now uses that method for switching the current player, instead of the drop-down list that it had used. And I also changed it to use the unit and unit-member tree that I created for the worker management app, instead of a list of units and a list of unit members, like I said I wanted to in the roadmap section of my last report.

Speaking of menus, there was a bug in the code that handled the “open viewer window” menu item. While it did open a viewer window, it didn’t attach a menu to that window, so none of the hotkeys would work. To fix that, instead of adding the missing code to the call site (as I could easily have done), I the map viewer—and every graphical app—responsible for setting up its own menu.

In the worker-management app, I made a couple of cosmetic improvements. First, the stats (or, rather, stat modifiers) printed when the user holds the mouse cursor over a worker in the tree now always have a sign in front of them, as is fairly standard in at least the tabletop RPGs I have played, instead of only when negative. And second, the units in the tree no longer display their owner’s name, because they are, after all, always owned by the “curent player.”

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

Roadmap

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.

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.

In response to player requests, I’d like 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 in the map viewer. I also intend to let fixtures have custom images (different icons for different kinds of units, for example). And I hope to add larger images (“portraits”) for units and some other kinds of fixtures.

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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