On Wednesdays I write about my strategy game, Strategic Primer.
Last week I wrote about my intention to start over the computer version of Strategic Primer. This week I’d like to talk at somewhat greater length about where I intend to take this new revision, including its impacts on the campaign version. (Which still needs more players: if you’re interested in joining the current campaign, please contact me; this would involve a time commitment of probably no more than a few hours a month, and we work around the players’ schedules.) I’ve laid my plans out more specifically on the project’s feature list, but the following is somewhat more general.
One major problem of the previous version was that everything was very tightly bound together, which made it very difficult to start working on anything I hadn’t touched in a while. To avoid causing the same problem in the new version, I’m making two user interface “drivers” from the very start, and I’m trying to ensure that everything except the actual UI code is thoroughly tested.
In the previous version, each “tile” represented a square a half-mile across. The problem that was the final straw prompting me to start over was how to allow multiple “modules” (units, fortresses, buildings, or landscape features) on a tile and still have meaningful and useful interaction and pathfinding. In the new version, each “tile” will represent an area about ten feet by ten feet, and until I start adding support for submarines, aircraft, and the like no two modules can share a tile. I intend to convert the campaign map to the same tile size, but have not yet thought of a suitable algorithm to do the conversion for me. (I wrote at length about this problem several weeks ago.)
To help with that adjustment, I am making some significant changes to the terrain model. Previously, a tile was defined by its location and its “terrain type,” which was either ocean, plains, mountain, swamp, jungle, temperate forest, boreal forest, tundra, or desert. In the new version, each (much smaller) tile will be defined by its position and its terrain type, now from the somewhat smaller list of water, desert, swamp, plains, and ice (though that list is still open to revision), but also by its elevation and, eventually, the height of its water table. Forests will be plains tiles with trees, which will be landscape features.
In the previous version, including the campaign at present, a tile can have any number of “landscape features”–the one example I created in the code was a crater–but exactly one “event.” Events were what I came up with when a player sent a worker out exploring with specific things to look for; I made a list of 24 possible events (with enough of them, especially “nothing of interest here,” duplicated multiple times in the file to make it 256 possibilities) and assigned one to each tile. But that has proved not nearly detailed or flexible enough. Therefore, in the new version (and eventually in the campaign) each (smaller) tile can (but doesn’t have to) have any number of possible “encounters,” which are things that someone going through or nearby might see, run into, or otherwise “encounter.” And I hope to make this list much better informed by what the players want their explorers to be looking for.
So that’s some of the new things that I intend to implement. Comments?