The bulk of the changes in the past month-and-a-bit seem to have been warning fixes and the like: declaring parameters and variables by their interface types (and extracting interfaces, for this and other reasons, which I’ll get to below) rather than specific implementations, reducing method length and cyclomatic complexity, and so on. Some of the remaining warnings can’t really be fixed using the standard library’s collection classes, so I’m considering using Guava. I also ran a “dead code detector” a few times, and was able to remove a few pieces of code that are no longer used.
In the past couple of weeks, I resumed work on the new map API. The second reason (the reason other than that static analysis tools often ask for it) for extracting and using interfaces rather than specific implementations is that this made it possible to write a class that implements the same interface as the map and map-view classes that everything now uses but that has a new-API map inside for storing the data. Now, none of this new code is ready for real use yet; there’s no way to even create a non-empty map, there is no test code, and there’s no XML serialization code. But I consider this a very good start on one of the more pressing items on the roadmap.
The list of “planned” features (which has debatable correspondence with the Pivotal Tracker backlog, remains largely unchanged from previous months.
The first item is to make the apps a proper MDI application, with a Window menu keeping track of windows and their status, and to make them behave like native apps (following human-interface guidelines, etc.) on the major platforms, starting with Mac OS X. But because my first attempts failed, I’m still at a loss as to where to begin.
Second, with it possible for players to make changes to a known-world map using the “helper apps” (rather than just a text editor) and send it back, changesets need to become a priority.
Third, I want to “finish,” test, and switch to (once I’ve demonstrated it won’t lose data) the new map API; this may make developing changesets easier, and it’s possible it’ll bring performance improvements, but we’ll have to see.
Fourth, I want to write programs to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting.
That ties into the fifth item on the list, “resource management,” eventually including modeling resource production and resource accounting.
Sixth, I hope to add larger images (“portraits”) for units and some other kinds of fixtures.
Among other planned features.
- Strategic Primer year-end retrospective (shinecycle.wordpress.com)
- Strategic Primer helper apps development report and roadmap (shinecycle.wordpress.com)