First, I overhauled the logic for panels sending and receiving notification that they ought to update; previously this had been done with specialized methods on the panels, which were called by whatever part of the view kept references to them; now, instead, I use the standard Java (Swing) protocol of PropertyChangeListeners. This should let me change either end of the protocol much more easily. For example, I want to move back to a single map component rather than one component for every tile (more on that later); previously that would have been much more difficult if not impossible, because of the way I kept track of “the current tile”, but now I can just make sure that the MapComponent emits the proper PropertyChangeEvent and it should work fine.
Second, I added a UI to show the contents of the current tile on the secondary map. I intend to let the user copy items from one map to the other using this, but Java’s drag and drop protocols are complicated enough that I need a good tutorial—and I could not find a single one that helped my use-case in the slightest.
Third, I dropped a bunch of old CLI front-ends that haven’t been used, or more than minimally updated, in months; they existed primarily to let me see the terrain of the map without waiting for the main viewer to draw the map back when that took several minutes.
And fourth, I moved tile-drawing logic out of the GUITile class into a helper class. I made an interface for this, so that I can switch implementations at compile-time at least, and added a second implementation that doesn’t create and cache Shape objects (which seems to be faster, for some reason). I then modified the old MapComponent single-component map UI to optionally use a helper, and created a driver method to run some performance tests to compare the various implementations. (Results have been mixed, and may depend on the JRE.) As I said above, I’d like to move back to the single-control version, so as to avoid the overhead costs of (at present) over five thousand GUITile components. With a helper class handling the drawing, I don’t have to do much to update the MapComponent’s drawing method, which hadn’t been updated since before I added rivers; all the class now needs is logic for a “currently selected tile” and keyboard navigation, which will be somewhat more complicated than the multiple-component version.
A month ago I announced a plan to change the resolution of the map “as soon as I finish running the current turn.” Unfortunately, my work on running AI strategies stalled, then once I resumed it took longer than usual, so I still haven’t finished the turn. I’m still planning on this. Because the plan has taken longer than I hoped, here’s some more details:
First, we’ll go with ten subtiles per tile on each axis (so a hundred subtiles per tile in total) and use decimal coordinates rather than renumbering the map completely if I can figure out a way to easily read and write fixed-point decimal numbers in Java, to make the transition easier on the players.
Second, I’ll add model objects for the various things explorers encounter that have previously only been reported in the “results text” associated with tiles, and create a canonical list of the “major” things on each of the 6072 tiles. (For example, each tile has a villages, except perhaps if it has a town or city.) Then I’ll randomly place those on the tile’s subtiles.
Third, I’ll determine the terrain of the various subtiles. Since there are villages everywhere, even deep in the forests, there have to be fields or at least meadows; similarly, in the plains there have to be at least some trees.
Fourth, I’ll add data about wildlife. Each (former, i.e. “big”) tile will have several populations of “large” animals; each subtile will have at least one population of “minor” animals. And each subtile will have dominant plant species (trees at least in forest, grass or shrubs at least elsewhere). I haven’t yet figured out how to make encounters with animals that live nearby but have wide ranges (or with parties from the village, for example) work.
And fifth, I’ll add a new tile drawing helper (see above), which will draw these subtiles properly, showing only the terrain type and the topmost item (which we need to do so we can have small subtiles, as well as for performance reasons). Using a drawing helper will let the viewer continue to support old maps, as I can select which helper to use at run-time based on the map version.)
Once I’ve done this, I plan to start adding support for resource stockpiles and unit details to the viewer, probably replacing the (stalled) character management program. I hope to implement unit movement and vision soon, though movement is also likely to require an understanding of Swing’s drag-and-drop API, which (as I said above) I’ll need a good tutorial for, something I’ve looked somewhat extensively for and been unable to find.
What do you think of these plans? Are there any features that you think I should implement sooner rather than later?