2017 Goals Second Quarter Report: Strategic Primer

It’s nearly July already, the year half gone, and since one of my goals for 2017 was to “After each quarter, assess progress and note any necessary amendments to goals in a blog post,” this week I’m going over my goals for the year to see how my progress so far compares. On Monday I looked over my progress on the Shine Cycle; today, a look at what’s happened with Strategic Primer.

Year-Long Goals

While “getting back to normal” on the Shine Cycle merely required recovery of motivation and habits, my illness in the first quarter came when I had lots of tasks at the top of my main “miscellaneous” task queue, pushing anything related to Strategic Primer down and out of sight until I’d regained some respectable “velocity.” My work on “assistive programs” development was mostly driven by needs, or wants, uncovered as I used those programs to further the campaign.

Here are the goals I set back at the beginning of the year:


For the campaign:

  • Goal: Finish at least three turns, including the present fifteenth turn, in the current campaign.

Three turns this year is looking increasingly unlikely; two still looks possible.

  • Stretch Goal: (Successfully) recruit at least one more player to join the campaign.

And I still think this looks unlikely. But again, we’ll see.

Assistive Programs Development

  • Goal: Implement, or definitively decide against, at least a quarter (i.e. at least four) of the items in the most recent “roadmap”
  • Stretch Goal: Implement, or definitively decide against, at least half (eight) of those items.

As I mentioned last quarter, I had technically accomplished the “goal” that first quarter, and my development priorities had changed enough that I’m not focusing on that particular “roadmap” anymore.

  • Goal: Implement changesets.

This is still sitting on my list as something I really, really want to have, but that, because I didn’t design them in from the start, I don’t see how to start implementing without starting the whole project over from scratch.


  • Goal: Get the new blog set up and publicly visible, with at least thirteen posts (scheduled) on it, by the end of the year.
  • Stretch Goal: Have at least twenty-six posts (scheduled) on the new blog by the end of the year.

I’ve done some content-conversion work in the last few months, but haven’t actually put anything up on the new blog, let alone made it public yet. I don’t think this’ll happen this year. But we’ll see.

  • Goal: Finish my initial pass through the advance database estimating advance difficulty and listing (immediately obvious) dependencies.

I feel like I’m making good progress on this, and my task tracker thinks I’ll finish the last currently-listed task in this project by the middle of next January, so I’ll say this seems eminently possible. But again, we’ll see.

  • Stretch Goal: Finish my pass through the old advance database, translating its advances into the current database.

Since that’s scheduled for after the difficulty-estimation project, it’s vanishingly unlikely that I’ll get to it this year, let alone finish it.

So to sum up, Strategic Primer has progressed about as well as I had expected, but not nearly so well as I had hoped.

Assistive Programs Development Report

I’ve done a little development on the suite of assistive programs since the last snapshot release-cum-release candidate; as I mentioned above, this has mainly been fixing bugs I encountered while running the campaign, but some was also simply addressing minor points that I’d left “TODO” comments about in months past. You can download the third release candidate for version 0.4.9014 from GitHub as usual.


  • First, addressing what had been a shortcoming of the Ceylon port, when loading a file that might be bundled into the app itself (an “encounter table,” for example), unless it’s definitely test data (and so shouldn’t be user-supplied), apps now look on the filesystem first, and then on the “classpath” bundled with the app.
  • In the report generator, resources within a unit should be grouped with others of the same “kind.”
  • If a map contains two items with the same ID number, the warning about this will now give the location of the second item in the XML.
  • The subset-checking apps now check animal populations’ age and population count.
  • A warning is now printed if a single player has multiple fortresses on a tile (which isn’t supposed to be possible).
  • There was a bug in the exploration CLI that caused direction choices to not actually match the menu printing them, which I fixed by adding an “ordinal” field instead of relying on the compiler’s automatic ordering.
  • Animals now only report anything about their age in their “short description” (used all over in GUIs and CLI apps) when their date of birth is valid (non-negative)
  • The XML writing code now only writes an animal population’s size if it’s greater than 1.
  • In several parts of the subset-checking code, the code that was supposed to report what broke the subset actually only reported the context but not the immediate cause. This is now fixed.
  • In the “query” CLI, the worker-counting feature had been broken, probably ever since it was ported to Ceylon; it compared the player the user was interested in to the worker itself, instead of the worker’s owner, and so always reported a total count of zero. This is now fixed.


As I mentioned before, I’m again declaring this a “release candidate”; if I get a chance to test it on each platform I’m concerned about, unless bugs surface, I’ll probably release version 0.4.9014 soon.

The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future. Here are some notable items:

  • On Mac, making the program stay open, showing a menu bar with suitable options available, when all windows are closed, as is usual on that platform.
  • Extending the “community population” modeling to cover former contents of non-active communities, and adding a similar data structure for battlefields.
  • Making sure that the test suite is sufficiently complete.
  • Adding a feature to allow a user to edit results of unit orders (which can be stored in the map format, but not edited in an app)
  • Extending the map format to include roads.
  • In the worker management app, allowing the user to apply orders to multiple units of different kinds, or multiple kinds of units, at once.
  • Adding a resource-entry feature to the map viewer.
  • In subset checking, reporting moved units (or other fixtures) as such instead of “extra” in their new location.
  • Creating a “fortress-design” or “tile-planning” app.

I’m not currently planning to spend much time on adding new features soon, however.

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 or contacting me directly.


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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.