It’s been four weeks since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, and at least one of the “apps” in that release (though not the map viewer) was severely broken, so I’m making a new release today.
Most of this month’s changes are an outgrowth of the fact that I finally upgraded to Eclipse 4. There are several patterns of arguably-dubious code (“warnings”) that the IDE can now check for, and, more importantly, it now offers “null pointer” analysis to show where my code makes unreasonable assumptions about the validity of parameters and return values. And so my first task was to turn the “nullness” checking on project-wide, assert that anything not explicitly marked as “nullable” would never be null, and fix what the errors and warnings this produced.
But while working my way through this process, or perhaps even before (I might have downloaded Eclipse 4 and started investigating nullness-checking to help me track down some errors), I discovered that the worker-advancement “app” was badly broken. Trying to use its basic functionality led to “null pointer exceptions,” which led to it simply not working. While it didn’t actually crash, it was hardly better. One of these “exceptions” was fairly easily fixed; another was less so, but eventually came down to what I might call an “off-by-one” error caused by counting objects and then referring to the last one by a number one too high.
When I thought I had fixed all the errors and warnings produced by the nullness analysis that Eclipse does, I opened the map viewer to make sure that it still worked … and found that it didn’t. Merely opening the map threw a barrage of null-pointer exceptions, which were easily enough fixed. Another intermittent bug produced such an exception on occasion when scrolling very quickly; I think that one’s also fixed, but I found it hard enough to reproduce in the first place that I’m not entirely sure.
While working through the nullness-analysis warnings, because Eclipse assumes that any object coming from a standard library method might be null, I got very frustrated with having to check in every event-handler method whether the event object it was handling was null. And I also came to the conclusion that my common practice of making nearly every inter-object asynchronous communication request be modeled as a “property change event” was bad design. So I created a new set of event-listener and event-source interfaces, and went through replacing old “property change” usages with the new idioms. It’s entirely possible that I failed to “wire” something correctly, so if you notice something doesn’t work like you’d expect it to, please let me know!
I also changed the idiom for setting up such event listeners. Previously, panels and widgets generally took event sources as constructor parameters, and passed them on to their sub-panels, widgets, or model objects, which added themselves as event listeners at the bottom level. After my changes, the listening-relationship is set up (more or less) at the level where it makes the most sense, at the lowest level that contains both listener and event source; this is made possible, in some cases, by panels or components implementing the listener interface and passing events on to the model objects or sub-components that they contain.
Another benefit of Eclipse 4, or perhaps of using the Eclipse-supplied binary rather than a version compiled from source on my computer, is that one of the static-analysis plugins I use has started working again. And so much of my work this month has been fixing warnings; it would have been better to write the higher-quality code the first time, but I’m glad to have another QA tool back in my arsenal, even somewhat belatedly.
As part of my warning-fixing, I had Eclipse do a mass “reformat” and “clean up.” But somehow it decided to apply these operations to the images I use as icons as well as to the code; this caused the map viewer to break, and was fairly hard to track down, but easy enough to fix, because with version control all I had to do was revert the affected files to an earlier version.
The “roadmap” of planned features (which mostly agrees with the Pivotal Tracker backlog) is largely unchanged from previous months.
At the head of the list are a couple of interface issues, one somewhat simple, the other quite complex.
First is to make the apps a proper MDI application, with a Window menu keeping track of the windows and their status. And second, for users running Mac OSX, I want to improve the program so that each app behaves like a proper OSX app, adhering to the human interface and design guidelines. But these will take much thought, since my first “plans of attack” have foundered.
With it now possible for players to make changes to a known-world map and send it back, changesets are becoming somewhat more urgent.
Fairly soon—before the current API gets even more deeply ingrained—I want to properly implement and switch to (once I’ve demonstrated it won’t lose data) the new map API I developed a while back. Among other reasons, this should make implementing changesets somewhat easier.
Another fairly urgent item is “resource management,” eventually including resource production and resource storage accounting.
I hope to add larger images (“portraits”) for units and some other kinds of fixtures.
I want to write programs (just command-line interfaces for now, I think) to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting.
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.