In the last few weeks since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, there have been some significant changes; I’ve continued to make great progress along the roadmap.
First, I adapted the new reading framework to also handle writing maps and other objects to file (well, to an intermediate representation, which then writes itself to file); using that framework made it possible to write a map that was read from multiple files to be written back to them properly. The old way of writing—which involved objects writing themselves—is now deprecated. I also expanded the tests to help cover this
Next were a few of minor changes: I made file-not-found in image loading code only print that fact and the file name, rather than a full stack trace; I looked for all the places I cast floating-point numbers to integers (mostly where I’d multiplied integers by floats to try to get slightly more accurate results of fractional multiplication) and switched them to use the rounding function in the SDK instead, since casting just truncates them; and I changed IDs from long integers to simple integers because in practice they came nowhere near the maximum possible integer.
The big change this month was the change from “maps” to “map views” as the main thing most parts of the code deal with. A map view fits the same interface as a map (so most code didn’t have to change much), but it wraps one main map. In addition to that main map, it keeps track of the current player (that was supposedly handled by maps before, but I discovered it wasn’t really …) and the current turn, and can have sub-maps giving more detail about the tiles of its main map.
I wrote a converter that reduces the resolution of a map (as discussed earlier) and create submaps for each of its tiles. However, because this ended up inflating the size of the map on disk by a couple of orders of magnitude (and, if I made each submap as big as I’d originally planned, overflowed the Java memory heap), I plan to take a different approach in the next weeks—more on that below.
As part of that attempt, I added an interface (which nearly all model objects now implement) for creating deep copies of themselves and for recursively changing their associated file-name.
Most of the rest of the changes were warning fixes and attempts to improve performance.
The first, and most urgent, item on the roadmap is my alternative approach to submaps. I intend to create a way of generating an appropriate submap from just the information in a tile—previously the converter created them from the four larger-resolution-map tiles that were being converted into one lower-resolution tile—and then only write a submap to file if it’s different from the one that would be generated. As part of this, in the conversion process I’ll change fixtures’ IDs (which I use to seed the random number generator that places them in the submap) to make sure that they end up in the right quarter of the submap. The one piece of this that I’m still somewhat worried about is rivers, since they don’t have IDs and are a special case in the serialization process.
A second, related, item is a user interface for submaps, so that users of the viewer can actually see and interact with them. This is simple in concept, but the user interface management code has grown quite complicated, so fitting this new feature in may prove somewhat difficult. We’ll see.
Once I’ve gotten that working, and have converted all the higher-resolution maps using the resolution-lowering converter, I’ll move to changesets.
And most of the rest of last month’s roadmap is still planned.