I turn now away from the map problems, which can for the campaign be worked around using paper maps instead, and toward the part of the game that became unwieldy in previous campaigns even before I started trying to make the computer do my work for me instead of treating it as an improved typewriter. First, there’s the matter of scientific/technical advancement. The rule is that a human player can invent practically anything by simply explaining or demonstrating it to his or her scientists. In the first campaign, the proviso that those scientists have to be able to understand it was basically only enforced by the players not submitting proposed advances they didn’t think their scientists could handle, and was mostly ignored anyway. (I hadn’t thought of doing “turns” yet–everything was marked with the current date when I ran the strategy–but there were probably on the order of three turns a week, and some players got from crossbows-and-catapults into space in less than a month real time.) Because at least three players took advantage of this rule, plus another rule I’ll mention in my next essay in this series, my table of advances filled up rather fast.
This was further exacerbated in the subsequent partial campaign, where the active players picked up where they left off and I tried to keep up with them in my own additions to the database. At the same time, I was trying to convert the existing advances into a new system. (In the original rules, which I’ve mentioned before, most units’ “hit points” were the number of soldiers in that unit, usually fifty; a system that wouldn’t even work all that well with a purely ancient/medieval/Renaissance military model would be even worse when confronted with aircraft.)
As part of this conversion, I began to add dependency information: you can’t invent the gunpowder cannon until you invent gunpowder, for instance. But by this time I had hundreds if not thousands of advances, and so while most of them got converted to this new system (which I’ll talk about in a later post), only some of them got proper dependencies added. Later, as I prepared for and went off to college, I converted the database to another system, dropping everything but the descriptions because I couldn’t think of how to represent the statistics, but I got a fairly complete dependency graph. The current model is the result of yet another overhaul (still in progress), and adding some dependency information ought to be nearly trivial because I am keeping notes of which advances in the previous system are converted to which in the newest system.
But all of that is not yet the real problem. In the previous version of the database, which I am using as the base for the conversion I’m currently working on, there are on the order of 1700 advances. Once I have some sort of dependency graph, I need to first determine that the graph is acyclic, which will probably be as close to trivial as any operation on a data set of moderate size ever is. But then I need to check that all the dependencies make sense, and that there aren’t any missing dependencies (or, for that matter, missing advances). And finally I need some sort of tool to suggest advances (in the database) that a given player has all the prerequisites for and thus could discover soon.
In the next part of this series, I’ll talk about the difficulties in keeping track of the details of the forces under the players’ commands.