Strategic Primer assistive programs development report and roadmap

It’s been almost a month since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer, so it’s time for an update.

As usual, you can download the new version from Bitbucket, and if you want to know more details than I list below, you can see the full history in the Mercurial repository.

Changes

The first change was an improvement to the way units (and other “fixtures”) are described throughout the suite: wherever a player’s name is used, and the player in question is “the current player,” the player is now referred to as “you” rather than by full name—unit descriptions, for example in the advancement GUI, had a tendency to be cut off before getting to the important information, while reports created by the report generator can be very repetitive, so abbreviating this way is very helpful.

I also did quite a bit of redesigning of the most “venerable” graphical interfaces. In the map viewer, I got rid of the “tile detail panel” that only listed the tile’s coordinates and terrain type, since the terrain type is also listed in the list of fixtures; the coordinates are now printed in the header above that list. And I almost entirely reimplemented the layout of the advancement GUI using “split panes” rather than the hacked-together manually-resizing system I had originally used.

In the map viewer, I made it possible to edit the name, “kind,” and owner of “fixtures” that have them. To use this, right-click on the fixture in the list in the lower left hand corner of the window. I also made it possible to change the ownership of villages in the exploration programs.

I added a convenient way to access non-graphical programs in the suite: if --cli (or -c) is specified on the command line but an option indicating a particular program is not, it will prompt the user with a text menu of command-line “drivers,” automatically generated from their usage information.

I did quite a bit of code reformatting, reorganization and other maintenance on the “TODO” and “FIXME” items in the code (actually dealing with a couple), and other “cleanup.”

I created a program to let me run players’ trapping. I intend to extend this to cover other workers’ time expenditures, but that’s a fairly low priority item on the roadmap at this point.

And, lastly, I added rudimentary support for worker “stats,” and a basic interface for entering stats for existing workers and creating new workers with randomly-generated stats.

Roadmap

The most pressing item on the roadmap is to “fill in the remaining holes in the table of available drivers,” and in particular to write an app for players to manage their workers.

Next is UI support for unit details beyond the trivialities of name, “kind,” and owner, and in particular moving workers fro unit to unit.

And changesets.

Another fairly urgent item is “resource management,” eventually including resource production and resource storage accounting.

In response to player requests, I’d like to either make the “Z-order” (which determines which fixtures are “on top” of a tile) configurable or allow the player to turn off the display of some kinds of fixtures in the map viewer. I also intend to let fixtures have custom images (different icons for different kinds of units, for example). And I hope to add larger images (“portraits”) for units and some other kinds of fixtures.

Among other planned features.

If you have any features you’d like me to add, or you run into any problems with the software, please let me know—perhaps using the issue tracker.

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