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

It’s been a little over a month since my last report on the development of the suite of assistive programs for players and Judges of Strategic Primer, and there have been a fair number of bug fixes and new features.

You can download the new (snapshot) release, 0.4.3250, as usual, from BitBucket, and if you want to see the development history in detail you can browse the Mercurial repository online.

Changes

One of the first changes this past month was a bug fix, and one of the last changes was an attempt to fix a bug or misfeature; the rest were largely new features, but I also did a bit of warning fixing.

The bug that I fixed was that when the selected point in the map viewer was in the top row or the left column, it wouldn’t repaint itself when it was told about changes. The misfeature I attempted to work around (I’m not sure I was entirely successful) was that after searching, or (I think) using the “jump to tile” feature, in the map viewer, you’d have to click in the map to get it to respond to the arrow keys again.

The first new feature is that in the map viewer, there are now keystrokes you can use to navigate to the top and bottom of the current column and the beginning and end of the current row. These hotkeys are derived from the sc console spreadsheet: you can use Ctrl-Home and Ctrl-End to jump to the top left and bottom right respectively, Home or 0 to jump to the top of the current column, End or # (though the latter won’t work at the moment, as I just realized, if it isn’t shift-3 in your keyboard layout) to jump to the bottom of the current column, ^ to jump to the beginning of the current row, and $ to jump to the end of the current row.

Also in the map viewer, I added the ability to center the view on the currently selected point.

One extremely-visible but functionally-minor change is that every GUI that has menus now shares the same menus, with options and menus that the application can’t handle grayed out.

The worker management and advancement apps can now take and operate on multiple maps at once. (As with the exploration app and other apps that do this, these assume that the first parameter is a ‘master’ map and the others are ‘subordinate’ maps that are more or less subsets of the ‘master.’) I’m not sure that the logic of my code is quite correct, so if you test this, please let me know if you run into any issues.

I also added a command-line interface for worker advancement, to match the GUI that already existed.

I made the report generator include sections for portals to other worlds and adventure hooks. I believe that the only kinds of fixtures it now skips are hills, sandbars, and oases; is there any reason to include these in the report?

In the tree-formatted report, shown in the worker-management app, I tried to make the report list every point mentioned in a separate item (though I may have missed some cases), and I made it open the map viewer at (or switch to a running map viewer and make that window jump to) the relevant point when you control-click a node in the report tree that has a point associated with it.

I added the exploration GUI app to the main app chooser, which appears when you run the main executable without specifying an app.

I added a command to the query command-line app to count a player’s workers.

The last commit included in this release is the addition of images (all of which I believe to have been in the public domain) for every terrain type. These are not images that would be suitable for representing a tile of that type in a map, but when you select a tile in the map viewer its terrain type is shown in the list of fixtures on the tile. I had thought that images were already generated for that purpose, but I was still getting “image not found” messages occasionally, so I found images to put in the repository just in case.

Roadmap

The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future.

At the top are a few bug and misfeature fixes I thought of while writing the changelog above. But after that:

  • Extract the Window menu code, which is third-party code, back into a library so my static-analysis tools will no longer try to check that code.
  • Change the exploration apps to copy fixtures, without their contents or other sensitive details if they don’t belong to the explorer’s owner, to player maps rather than simply reusing the same model object. (And move caches, since a cache in a player map is supposed to represent one that the explorer picked up.)
  • Determine a definite license under which I’m releasing my code, instead of the currently implied “ask me.”
  • Move development from BitBucket to GitHub, so that I can set up continuous-integration. (This will require switching from Mercurial to Git, which is a slight disadvantage as Mercurial is easier to keep in sync between my laptop and my desktop.)
  • Set up continuous integration to run tests and building on every pushed commit.
  • Add support for ‘implements’ (simple equipment) and ‘resource piles’ to the map format.
  • Change the way unit orders are represented so they can be set per-turn
  • Add support for unit results to the map format
  • Make subset checking treat location as another property, instead of treating a fixture that moved as a ‘new’ fixture in its location in the subordinate map.
  • Fix the performance maybe-issues: that I use Swing APIs that “best practice” (according to my reading) recommends not using for loading images, drawing images, and limiting the drawing area
  • Make the GUI execute some operations in parallel to the GUI-update thread
  • Anywhere the GUI allows the user to cause a fixture to be created, allow the user to enter an ID #.
  • Add a way for the user to preseed the ID-numbers-in-use cache with a map without actually opening that map. (That is, without leaving the map open—I don’t intend to reimplement, or shell out to call, grep and sed!)
  • Convert the “Display …” menu to a panel containing checkboxes that the user can drag to set a custom display-sort order to control what appears on “top”.
  • Make the report generator, or another app, give distance to fixtures from the player’s HQ.
  • As a user requested, when zooming in using the mouse scroll wheel, the zoom should center on the mouse cursor. (The ‘center’ menu item and hotkey help with this, but it’s still a good idea.)
  • The worker stat generator should apply racial stat adjustments.
  • Make the apps behave (more) like native apps (following human-interface guidelines) on the major platforms, starting with Mac OS X. The Window menu is a good start, and finally works, but there’s more to do. I need to enumerate what more needs to be done …
  • Changesets need to become a priority, because maps are no longer immutable from the players’ perspective. First, I need a list of operations that need to be supported.
  • The turn-running helper apps should be able to tell me such facts as how much meat any given animal produces, how much grain should be produced in a harvest, etc.
  • Related to that, “resource management,” eventually including modeling resource production and accounting in the map and the helper apps.
  • Unit (and other) “portraits”—larger images for individual units, towns, and the like.
  • Something like the mine-model-generation program for stone deposits. However, I currently make do with the existing model, just with different proportions for each level.

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.

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