It’s been almost two months since my last report on the development of the suite of assistive programs for players and Judges of Strategic Primer, so even though there’s very little to report it’s past time for an update. And it’s about time for a quarterly look at where I stand on my goals for the year, and for a NEWS update, but each of those is a subject for another day.
A new (snapshot) release, 0.4.3060, 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.
Previous development reports have mentioned that I was maintaining a parallel line of development with everything I had ported to Ceylon removed. While the port is not yet ready for general use, as far as the Java version is concerned it’s “complete,” so I have closed that “branch” off. The Ceylon version needs many bug-fixes (a few in the Ceylon compiler and runtime, but probably mostly in my code), but nothing remains to be ported.
The only real change in this release is the addition of preliminary support for portals to other worlds. Each “portal” tag in the map includes a note indicating what world it is a portal to and what coordinates in the other world it connects to. (At this point, because I don’t have maps for any world but the main game-world, those coordinates are all going to be (-1, -1), to show that they need to be generated when someone discovers a portal and goes through it.)
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.
My current top-features list is mostly the same as the last couple of months:
- Find icons for the remaining kinds of fixtures that don’t have them: oases, “adventure hooks,” and (though I haven’t added support for them yet) portals to other worlds.
- 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 new map API. There are a few tests, but first I need to write the XML I/O layer.
- 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.