Strategic Primer assistive programs development report and roadmap (#32)

It’s approaching a month since I last reported on the development of the suite of assistive programs for players and Judges of Strategic Primer, as part of my civil-year-end summary, so it’s time to make a new release and describe recent changes. 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

As I’ve mentioned in at least the last couple of reports, I’ve been maintaining two lines of development in parallel for several months now, one with and one (which I use to create the files I upload to the downloads area) without any code that’s been ported to Ceylon removed. Porting to Ceylon has been a major focus of my development efforts, but I won’t describe that in any more detail here.

There are only three changes in this release that users should notice:

  • The map can now contain “adventure hooks,” which represent things that a player can send representatives to investigate or explore, such as a “dungeon,” a rumor of a legendary artifact, or a change in behavior of a local group of immortals, for example. At the moment portals to other worlds are also represented as “adventure hooks,” but adding separate support for those is high on the roadmap below. By the way, there are about 500 “adventure hooks”—mostly “TODO: create” placeholders at the moment—in the current campaign’s game-world map.
  • The user can now navigate in the map viewer using the numeric keypad.
  • I added images (that I’m not really satisfied with, but having any distinct image is an improvement at this point) for djinni (that image is of a lamp, but note that in the game-world any djinni represented in the map are not confined to lamps …), giants, griffins, phoenixes, simurghs (actually an image of an unrelated bird that I’ve used anyway), and sphinxes.

The other notable change is one that should improve performance slightly. Every time the user selects a new point, whether by using the “Go To Tile” dialog, scrolling using the scrollbars, or scrolling using the arrow keys, mouse, or numeric keypad, the map viewer tests whether the new tile is visible and if not scrolls the map to make it so. But I discovered this month that instead of testing whether the selected tile’s row was between the lowest visible row and the highest visible row, the viewer was testing whether the row was between the highest visible row and the highest visible row, and so resetting the scrollbar on the right every time.

Roadmap

The top items in the Pivotal Tracker backlog are currently some performance issues, a couple of fairly-urgent bugs that I mentioned last month and still haven’t fixed.

The performance issues are that I currrently use several APIs that best practice recommends not using for loading and drawing images and limiting the drawing area, and there are places where the GUI calls time-consuming operations that could be but aren’t yet done in parallel to the GUI-update thread.

My current top-features list is mostly the same as last month:

  • Find icons for the remaining kinds of fixtures that don’t have them: oases, “adventure hooks,” and (though I haven’t added support for them yet) portals to other worlds.
  • Convert the “Display …” menu to a panel containing checkboxes that the user can drag to set a custom display-sort order to control what appears on “top”.
  • Apps that allow the user to create units or other fixtures should allow him or her to either specify an ID number or pre-seed the cache of used ID numbers, to avoid (for example) giving a new unit an ID number that is used by a fixture that player doesn’t know about.
  • In the worker-management app, the user should be able to use the “report” tree to find an item in the map viewer.
  • As a user requested, when zooming in using the mouse scroll wheel, the zoom should center on the mouse cursor.
  • The worker stat generator should apply racial stat adjustments.
  • Make the apps behave (more) like native apps (following human-interface guidelines) on the major platforms, starting with Mac OS X. The Window menu is a good start, and finally works, but there’s more to do. I need to enumerate what more needs to be done …
  • Changesets need to become a priority, because maps are no longer immutable from the players’ perspective. First, I need a list of operations that need to be supported.
  • The new map API. There are a few tests, but first I need to write the XML I/O layer.
  • The turn-running helper apps should be able to tell me such facts as how much meat any given animal produces, how much grain should be produced in a harvest, etc.
  • Related to that, “resource management,” eventually including modeling resource production and accounting in the map and the helper apps.
  • Unit (and other) “portraits”—larger images for individual units, towns, and the like.
  • Something like the mine-model-generation program for stone deposits. However, I currently make do with the existing model, just with different proportions for each level.

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.

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