In this last week of the liturgical year, this week’s posts on this blog are looking back over the past year on the blog. We covered the Shine Cycle category on Monday; today we’ll look at posts related to Strategic Primer, and also a report on development since the last update.
First, a look back over the year on the blog.
In previous years I’ve divided this up into sections, but there were so few posts other than “monthly” assistive programs development reports that I can simply list them.
- In December, I made a “statistical summary” of the contents of the world map. It’s now somewhat dated, since it revealed several anomalies that I spent time over the next several months correcting, but may still be of interest.
- We did actually manage to finish one turn (that had been in progress for some time) this year, so I posted the thirteenth turn summary in April.
- I had intended to post a “NEWS roundup” quarterly, but only had any real news to post that first quarter.
- Lastly, just last week I wrote about recently developed tool support for resources and equipment in the map.
As I mentioned, development reports were the most common Strategic Primer-related post this year, as usual. I won’t link to them all, but I’ll summarize some of the highlights.
- Probably the most important change was that development moved from BitBucket to GitHub and releases are now built by the Travis continuous integration service.
- I added support for “adventures” and portals to other worlds in the map.
- Until I added resources and equipment in the last month or so, every kind of thing in the map finally had its own icon. The program itself also now has an icon.
- In the map viewer, there are shortcut keys to jump to the edges of the map and to center the view on the currently selected tile. You can also navigate the exploration GUI with the arrow keys or the numeric keypad.
- I developed, then ported the rest of the code to use, a new map API
- All of the apps in the suite now share a single set of menus, with options not applicable to the current app grayed out.
- Just in the last few weeks, I added rudimentary support for representing resources and equipment in units and fortresses.
- There’s a panel in the worker-management app that shows details of the currently selected unit member.
- Also in the worker-management app, you can Control-click (not Command-click on Mac yet …) on items in the report tree to jump to them in a map viewer window, opening one if one isn’t already open.
Recent and Planned Development
As it’s been about a month since the last assistive programs development report, it’s about time for an update and a new release. This week’s release is 0.4.9002, and can be downloaded from GitHub.
Many of the changes to the code consisted of warning fixes and other refactoring, as usual; more notable changes included:
- Allowing code using the exploration driver model to clear the selected unit
- “Zeroing out” any “sensitive” data, instead of copying losslessly, in the player-map-expansion program
- Making it possible for the algorithm that gives the tiles surrounding a specified tile to return tiles up to different radii, not just a radius of 2.
- Various changes to try to fix building on and for a Mac platform (now that I own a Mac myself—and see also the top of the Roadmap below). In addition to purely build-system fixes, I moved the apps’ menu bars into the system menu bar on Mac, which I thought I’d done already long ago.
- Make the AppChooser window stay open until the app it’s chosen successfully opens, rather than always closing. This means that if you mis-click, then click Cancel in the file-opening dialog that follows, you can choose the app you wanted, instead of having to reopen the entire suite. (At least in theory; the map viewer reports success in that very situation.)
- Making as many apps as possible operate on driver models (which encapsulate one or more map files) instead of handling the file opening and writing themselves. The old code is still there, and in fact still the code path that gets called in almost every case, but I made the first step toward the goal of centralizing the calls into the I/O layer.
- Changing the report to (when describing individual items, instead of listing multiple points for each) print the distance to items from the player’s HQ. I also tried to get them to sort by distance, but there’s enough other sorting going on that I’m not sure whether that worked to the limited extent it could have.
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.
There are also a couple of code-cleanup items that I wanted to wait until just after a release to do (one of which I wanted to make sure to ask my users about first):
- Increasing the Java version targeted by the code from 7 to 8 (if you use the programs and don’t yet run Java 8, please let me know ASAP!)
- Removing the old map API
The remaining 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.
My next development report—the next release, unless someone discovers a significant but easy-enough-to-fix problem—will likely be combined with a civil-year-end summary post. But until then, do you have any thoughts?