Strategic Primer: Assistive programs progress report and roadmap

In the last month since my last report of my progress designing and implementing my suite of assistive programs for players and Judges of Strategic Primer, there have been significant changes.

Recent Changes

First, following up on last month’s work, I finished implementing the single-control Map GUI and switched to it; I eventually removed the many-control (GUITile) version from the project entirely once the single-control version implemented all of its features.

Second, I finally added a feature I’ve been wanting for a long time: drag-and-drop copying of Chits from one map to another. (Thanks to Jess for suggesting the search terms that finally pointed me to an actually helpful tutorial.)

Third, along with the many-control map GUI, I also removed the old map converter that was to convert from the XML map format to a new one (which I’ve been using in the computer-version-of-SP project, so this removal let me drop the dependency on that project) and the (old, bit-rotted, unfinished and so practically useless anyway) character management program. That last was because (in addition to the bit-rot) I’m going to go a different direction for worker management that wouldn’t have let me use the old code in any case.

Fourth, I did a bunch of refactoring to remove circular dependencies between packages and improve separation of roles between the model, view, and controller.

Fifth, and probably most notably, I added support for a new map version. It replaces mountain and forest tile types with plains and (a new tile type) steppe with mountain and forest Fixtures on the tiles, and prefers Fixtures (which I created for almost every “encounter” that any player has seen so far) to arbitrary-text results. I created a new UI helper to draw tiles for this new version, since it’s designed to show one (uppermost) Fixture on each tile. As part of this, I’ve made each Chit use an icon it loads from file, if one is available, instead of drawing (simple, unintuitive) icons and making everything except units and fortresses share the same icon. Since the new fixtures aren’t version-2 specific, I converted all the players’ maps to use them.

Map viewer showing a version-2 map
Map viewer showing a version 2 map

I had feared that I’d have to drop support for the previous version to be able to keep the terrain-type editing menu and the terrain-type key while changing which terrain types are supported from format to format, but I eventually discovered and implemented a solution to that difficulty.

Sixth, I made each model type know how to write itself to XML, instead of maintaining a separate intrusive XML writer; this mixes a controller function into the model, which I don’t like, but simplifies file I/O significantly.

And seventh, I created a rudimentary driver to convert maps from version 1 to version 2, increasing their resolution. I found that a resolution increase of ten subtiles per tile per axis created unreasonably large files (100 MB for the main map) and caused the XML reading code to run out of memory, so I reduced that to six subtiles per tile per axis. This loses the easy coordinate conversion I’d hoped for, but does give a nice round number for each subtile’s approximate size: roughly four acres.

Roadmap

Yet to come is the rest of the conversion: new content for each tile, to replace the old encounter-generation model. Also, I’ll keep looking for icons to fill my remaining needs. (Missing icons cause the program to run significantly slower and actually to run out of memory.)

On the programming side, first I plan to add the ability to add, remove, and edit Tile Fixtures from the GUI. (You can see from the screenshot that I’ve removed the ability to edit the arbitrary-text; this is because each tile can have more than one arbitrary-text Fixture, each associated with a particular turn on which it occurred.) After that, I intend to start adding support for resource stockpiles and unit details to the viewer, replacing the character management program I removed. I hope to implement unit movement and vision soon, now that I understand Swing’s drag-and-drop API.

What do you think of these plans? Are there any features that you think I should implement sooner rather than later?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s