It’s been about 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, which was combined with year-end goal-setting, so it’s high time for an update, and a new snapshot release. This week’s release is 0.4.9004, and can be downloaded from GitHub.
There have been a fair number of changes since version 0.4.9003, but most were warning fixes or similarly minor changes. (Speaking of warning fixes, every so often there was a commit doing nothing more than changing wildcard imports to lists of single class imports, because IntelliJ IDEA, the IDE I’m primarily using now, automatically replaces imports with wildcard imports sometimes despite this misfeature supposedly being turned off.)
Two groups of changes had to do with using Java 8 features more often and fluently:
- I made sub-interfaces for driver classes that could be marked @FunctionalInterface, so that in the future I can maybe use lambda methods or method references instead of full classes in some contexts
- I changed code to use Streams APIs instead of loops or Iterables where I saw that this was possible. This work is still ongoing as I see opportunities I missed.
I made two minor changes—improvements, I think—to the format of players’ reports:
- The list of villages is now grouped by owner, instead of merely “belonging to you” and “belonging to others”
- The report on towns (cities, fortifications, etc.) is now split up by status, with the towns in each status sorted by distance from the player’s HQ.
The other changes included the following:
- Making the XML reading code look for a specific namespace, and ignore tags and attributes that specify some non-default but different namespace. (XML using only the default namespace will continue to work.) In addition, the XML writing code now writes XML that uses this namespace.
- Warnings were handled using a class
Warningthat had an enumerated
Actionto specify what it should do; the functionality of the
Warningclass and the enumerated nature of the
Actionenum have been merged.
- Adding automated tests of the helper interface for command-line programs and of the conversion code that can turn an old version-0 map into a version-1 map and a version-1 map into a version-2 map.
- In the worker-management and worker-advancement programs, merging the similar, identically named, but subtly different
ProxyUnitclasses, one of which represented all units of a given kind, and the other of which represented corresponding units in different maps.
- Fixing what I think was an off-by-one error that let the user scroll the map viewer, using the scrollbars, to one row or column beyond the maximum number of rows or columns in the map.
- Splitting the
HasKindinterface, so that objects that have a “kind” don’t have to be mutable. I plan to do the same for other similar interfaces soon.
The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future.
At the top of the list is making a Mac-native “application bundle” that actually works (I would say “fixing,” except none of the versions I could test worked at all), followed by other adjustments to make the suite behave like a native app on the Mac platform.
Other items on the roadmap are:
- Add images for implements and resource piles
- 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,
- 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”.
- 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.