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

It’s been several months since my last report on the development of the suite of assistive programs for players and Judges of Strategic Primer, so it’s long past time for an update.

A new (snapshot) release, 0.4.3190, accompanies this post; you can download it, as usual, from BitBucket, and if you want to see the development history in detail you can browse the Mercurial repository online.

Changes

Most of the changes between the last release and this one have to do with the new map API, which I finally finished implementing and ported everything to use. This shouldn’t affect users at all, but it’s entirely possible that I broke something in the process.

Perhaps the most user-visible change is the addition of images for sandbars, adventure hooks, oases, and portals; I believe that there are now no kinds of fixtures left that should have images but don’t.

Another user-visible change is that I finally fixed a long-standing bug in the worker-management app. Previously, when the user made certain kinds of changes, such as renaming a unit or worker or (most notably) dismissing a worker, the tree of units and workers would not update properly. The workaround was to make the tree reload its data, using a menu command I provided for the purpose, but that had other side-effects. This week I finally found how to make the tree update properly, and the tree now works as it should.

While debugging some issues with that, I discovered that Java’s developers strongly recommend that all code having anything to do with the graphics library, Swing, be run on a particular thread. I had previously thought that all calls that might involve drawing should go on that thread, but that initialization didn’t need to. So to follow the experts’ advice and forestall any subtle concurrency-related bugs, I changed the app-initialization logic to run everything touching graphics code on that thread from the very beginning.

Earlier, I wrote a simple program to add populations of a particular kind of fixture throughout the map. It’s designed so that I only have to change three methods to adapt it to a new purpose. I’ve used it to add populations of two kinds of animals that existed only in one or two places in the map before, and plan to use it to add veins of minerals I had overlooked when I initially populated the map.

Two last potentially-user-visible changes are that all apps that can be reached through the AppStarter app (which is the default when you run a JAR or platform-specific executable) now must be run through the AppStarter, and that if any of the GUI apps runs into trouble any error message will be reported using an error window, rather than just printing messages to the command line.

Roadmap

The top items in the Pivotal Tracker backlog are currently some performance issues, a couple of fairly-urgent bugs that I mentioned in December and still haven’t fixed.

The performance issues are that I currrently use several APIs that best practice recommends not using for loading and drawing images and limiting the drawing area, and there are places where the GUI calls time-consuming operations that could be but aren’t yet done in parallel to the GUI-update thread.

One other bug that I haven’t added there, and that I’ve tried to debug with limited success, is that some apps don’t quit (shut down the Java process) when the last window closes.

My current top-features list is mostly the same as the last couple of months:

  • 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”.
  • Apps that allow the user to create units or other fixtures should allow him or her to either specify an ID number or pre-seed the cache of used ID numbers, to avoid (for example) giving a new unit an ID number that is used by a fixture that player doesn’t know about.
  • In the worker-management app, the user should be able to use the “report” tree to find an item in the map viewer.
  • As a user requested, when zooming in using the mouse scroll wheel, the zoom should center on the mouse cursor.
  • 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