Probably the most important item to mention is that I finally added tests of the XML reading and writing code. The tests aren’t complete—I only really test serializing tiles and their contents—but this is a great improvement over having no tests at all, and writing the tests exposed some bugs (easily enough fixed once I found them …). As part of writing the tests, I changed the XML reader to demand a caller-specified root type instead of only a
SPMap, which will let me use it for other programs’ file I/O, and should be helpful when I finally implement
include tags in the map format.
As background for the other visible change, recall that in the last update I mentioned removing the scroll-bars as part of the (efficiency-motivated) change from drawing the whole map each time to only drawing as much as is actually visible. This month, I figured out how to add scroll-bars back and use them to let the user control the visible area of the map.
Other than those two major improvements, most recent changes have been bug and warning fixes and other code clean-ups; if you’re interested, you can browse the code yourself.
Of the four items on the roadmap I outlined last month, I only made any progress on one (fast-scrolling), so the others remain. But I’ve also done some brainstorming, so some additional items an be added, producing the following list:
First, again, finding icon images to fill my remaining needs (aches (of vegetables, jewels, or other treasure, for example), centaurs, djinni, dragons, “events” in general, fairies, fields (preferably showing that the field is plowed), giants, griffins, groves (of trees), hills, meadows, minotaurs, oases, ogres, phoenixes, sandbars, shrubs, simurghs, sphinxes, and “units”). And (after some of the items below) finding more specific icon images for kinds of fixtures I have general images for already, and finding “portrait” images for units, and …
Second, I intend to standardize the XML format somewhat. Some fixtures have a “kind” property while others have an equivalent but tag-specific property. Nearly everything ought to have an “owner” property. Lots of things ought to have a “name” property. And there are probably more ways the model and its file format can be improved.
Third, again, I plan to finally implement editing of fixtures. Once I’ve made some progress on the format standardization, a fairly generic fixture-editor shouldn’t be all that hard to implement.
Fourth, again, I hope to add resource stockpiles to the game’s vocabulary and a more detailed model of units.
Fifth, I hope to add the ability to “include” data stored in other files.
Sixth, I hope to add the ability to find particular fixtures (usually units or fortresses) by owner or name.
Beyond that, I have a long list of ideas I hope to get to sooner or later. But we’ll see …