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.


Most of the changes were related to converting the map to the new higher-resolution, more expressive format, which I reported on in December, and then populating it with a large quantity of flora, fauna, and so on. I eventually adapted the old exploration program to generate the “events” I wanted to put on each tile, changed the tables to produce proper XML, and then (fortunately) discovered Nailgun, which let me run it repeatedly and efficiently—without Nailgun, the process would have taken an order of magnitude longer at least, simply because of the time Java takes to start itself before it starts the program.

Then, last month, I made a major change, hoping to significantly improve the viewer’s efficiency. First (because otherwise this would have gotten very complicated) I dropped the “map subset” feature, which had let the user tell the viewer to display only a specified rectangle of tiles. Then I changed the main map-displaying control to only draw as many tiles as it could actually display, instead of drawing the whole map and then wrapped with scroll-bars. The user must now scroll the map by navigating it with the arrow keys, unfortunately, but this should be much, much faster than before, and I also added a way to go to the tile at specified coordinates.

Nearly all, if perhaps not quite all, the other changes were cleanups, warning fixes, and the like.


First, I hope to find icons to fill my remaining needs soon. (For the record, I need images for: caches (of vegetables, jewels, or other treasure, for example), centaurs, djinni, dragons, “events” in general, fairies, fields (preferably showing that the field is plowed), giants, griffins, groves (of trees), hills, meadows, minotaurs, oases, ogres, phoenixes, sandbars, shrubs, simurghs, sphinxes, and “units”.)

Second, I intend to add a way to scroll more quickly than the arrow keys permit. I have some ideas here, but this’ll take some digging to find how to use the relevant APIs.

Third, I plan to finally implement editing of fixtures. I’d like to reduce the amount of boilerplate code in the repository (for every kind of fixture, there is a class for the fixture itself, a class to represent the XML that produces it in the XML reader, and a class to represent it in the “fixtures on the tile” part of the UI … and probably now a class to let the user edit it) and somehow generate all the relevant classes from some sort of schema, but I’ll probably just go the simpler route and add yet another parallel collection of largely-boilerplate classes. Sigh.

Fourth, again, resource stockpiles and unit details. Unit details, at least, are becoming an urgent priority.

What do you think of these plans? Any suggestions for my difficulties?


Leave a Reply

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

You are commenting using your 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.