Strategic Primer assistive programs development report and roadmap

In the month or so since the last development report, I’ve made significant progress in the development of the suite of assistive programs for players and Judges of Strategic Primer. If you’re still using an older version, I encourage you to update to the current version (source on Launchpad for now; binaries—for Windows, for Mac, and cross-platform JAR—on Google Docs for now). And for once I can cross several items off last month’s roadmap.

Strategic Primer: Yet Another Resolution Change (RFC)

Over the past few months of development of the map viewer for Strategic Primer, after going to a great deal of effort to convert to a much higher resolution, populate the map with several “fixtures” on every (smaller) tile, make sure that players’ maps matched the main map, and then keep everything up to date with improvements to the viewer and the map format, I’ve come to the conclusion that the current size and scale make the map far too big to deal with, in practical terms.

Strategic Primer assistive programs development report and roadmap

It’s been almost a month since the last development report, so it’s time for another update.

Plans for Strategic Primer in Ceylon

For a while now I’ve been excited about a new programming language, Ceylon. It’s designed to run on the Java Virtual Machine and be interoperable with Java, but to fix many of the faults of Java that I find most troubling, and introduce some new features I’ve often wished for. As soon as it becomes usable—which I hope will be with the release of the second milestone version of the Eclipse plugin—I plan to begin porting the Strategic Primer assistive programs to it. Here’s a few highlights of the features that make this so exciting for me:

Strategic Primer assistive programs development report and roadmap

In the past month or so since my last development report, there’s been some noteworthy changes to my suite of assistive programs for players and Judges of Strategic Primer.

Strategic Primer assistive programs development report and roadmap

It’s been a few months since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer.

Strategic Primer Map Conversion Report

As I reported in last week’s Call for Strategies, I recently finished converting the map to new format and a higher resolution. Today I’d like to describe that process in somewhat more detail.

The first task in this conversion process was to get just about everything that players’ explorers had discovered or encountered already into the main map, in a more helpful form than arbitrary text. This required a bit of programming in the viewer, to make the map format expressive enough to represent the various kinds of encounters, but once the code support was there converting these “events” and copying them to the main map was fairly simple.

The second task was converting the map to a higher resolution. I wrote a program to do this, randomly distributing everything on each tile (except the rivers) among the equivalent tiles which replaced it, converting forest tile types to forests on the tiles, and (in the main map) adding “ground” Fixtures to say what kind of rock was there. This program was designed to work repeatably, so that when I ran it on the main map and the players’ maps it would distribute the tiles’ contents the same way, but I never could get that to work quite right, though it otherwise worked fine (once I fixed a bunch of design flaws).

And so the third task was to make the players’ maps match the main map. I wrote a program to identify the differences, but I still had to go through them by hand, so this took quite some time. But while tedious, this was not difficult.

The last task, which I’m still working on, and which is still more tedious and time-consuming, is “populating” the map—putting animals, abandoned mines, meadows, groves, and other things explorers may encounter onto the map, so that the table-based (Mark II) encounter model can go away soon. But unlike the previous tasks, this doesn’t require anyone to wait for it to finish.

Unit composition

When I finish the current project in Strategic Primer, converting the map to the new format and a higher resolution (as described in the current roadmap), one of my next undertakings will be adding details to units.

Until now, units—as far as the map and the map viewer are concerned—have just been one of several (and an increasing number of) kinds of what I now call “tile fixtures”, i.e. things that can be on a tile. They have a few properties—an owner, a name, a type description—but are really quite simple. But as the game progresses, this isn’t enough, and sticking with this primitive model will make running the game increasingly difficult as the campaign grows more complex. Here are some of the changes to the viewer that I’m thinking about:

First, I should probably add some sort of unique identifying number to each unit, as in my programming language the statement that “these two units are the same unit, but one is different from the other” would be nonsense.

Second, I’ll add the ability to edit units (and other fixtures) to the viewer. I will want to be able to edit units at the end of this list, and gradually improving the editor along with the model is easier than adding an editor to a complicated model after the fact.

Third, I’ll represent a unit as a group of zero or more “workers”—including soldiers, but I can’t think of a better general-purpose term. These will, for the moment, be simple and opaque objects, like units are now.

Fourth, I’ll also let a unit contain other members, starting with animals (primarily for Herders, but also for mounted units, chariots, and the like) and resource caches (for what an explorer might have found and be bringing home), but eventually including any major equipment (most importantly, in the long run, vehicles). Some of these are already in place as tile fixtures, and I merely need to allow them to be contained in a unit; others need to be implemented from scratch.

And fifth, I’ll start making the model of a unit’s contents more complex—adding “statistics” to a worker, for example, but I’m sure there are any number of things I can do.

Any thoughts?

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

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 diffiulty.

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?

Strategic Primer: Simultaneous Motion and related problems

The Strategic Primer map format changes I talked about in the last assistive programs development report are proceeding slowly but surely (more about that next week—God willing I might even be done by then), but today I’d like to talk about a problem I’m expecting to run into soon after I finish this task.

Soon after I finish changing the map resolution and converting arbitrary-text-based, truly (and too) random “encounters” to elements (“fixtures”) on the map, I intend to add unit motion, so that I don’t have to go in and move units by hand in a text editor.

But, more than simply being able to move units from one tile to another, I have two additional features that I want motion to include, that I don’t even begin to understand how to implement:

First, planned motion. I, or a player, should be able to mark a unit’s route using the viewer, and then execute that route later, and even over and over again if it ends where it began. If the viewer had the more general feature of changesets, I could implement this using those, but I have even less idea where to begin designing that feature.

And second, simultaneous motion and real encounters. As part of the map conversion, I’ll be adding a lot of animals and independent units to the map. If I can get planned motion working, I’ll be able to model their actions a lot more easily, including determining when animals are caught in traps. But to be truly useful for encounters, I need to be able to model multiple actors’ motion at once, instead of (as I do now) moving one, then another. I need to be able to see whether a hunter moving out from a fortress encounters a rabbit moving out from its den, or not. I have a few ideas for how to go about this, but nothing concrete.

Any ideas?