The most urgent order of business I faced in this development cycle was a couple of very significant bugs in the version I had released—one prevented released executables from even running (they crashed immediately), and the other made selecting a tile cause all other “identical” tiles to also appear selected. I uploaded two “mid-cycle” releases in quick succession as I fixed these two bugs.
After that, my first priority was the report generator I mentioned last month. While there are still ways it could be improved, I now consider it essentially feature-complete.
Once I got to that point, I turned to the exploration interface. I significantly refactored the exploration “driver model,” and added the ability for a unit to repeatedly explore its current location. But then I started working on a graphical interface (GUI) for exploration, to supplement the command-line interface I developed in the last few development cycles. This took quite a while and a great deal of effort, and I’m still not entirely satisfied with the result, but after all that work it’s functional enough to be usable (more so than the CLI, for most purposes!). And I learned a great deal about the best way in Java to do the kinds of layout that I find most intuitive, which I then put to use to improve the implementation of the map viewer and the worker advancement application.
I also added an icon (an image) for one of the kinds of fixtures that I’ve been missing one for, and made many other minor improvements to the code.
The “roadmap” of planned features is still largely unchanged.
The user interface for editing fixtures now heads the list, because I want to be able to edit fixtures from the exploration GUI.
Beyond that, the most pressing need is to fill in the remaining holes in the table of available drivers, especially writing “a proper app for players to use for worker management.”
Next is (still) UI support for unit details, including moving workers from unit to unit and adding workers in the advancement GUI, and also changesets.
Another item on the list, that I’m probably more likely to get to soon, is “resource management,” eventually including resource production and resource storage accounting.
Once the model supports more worker details than just Jobs and skills, I need to create a proper worker-generation program; I started with PCGen, but when it got really, really slow with fortress populations (from its perspective “party sizes”) only in the thirties, I switched to a shell script I wrote that just generated stats. Since I want more details than that, I need to write a program to produce them—and soon, since I’ve nearly finished running the current turn.
In response to the player request for a way to get a list of items “of interest” (which I hope the “report” that the recently-completed “report generator” addresses more directly), I’d like to either make the “Z-order” (which determines which fixtures are “on top” of a tile) configurable or allow the player to turn off the display of some kinds of fixtures. I also intend to let fixtures have custom images (different icons for different kinds of units, for example). And I hope to add larger images (“portraits”) for units and some other kinds of fixtures.
Among other planned features.
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