From the very beginning of Strategic Primer, I rejected pretty much every traditional conception of a “unit.” In many such games a player’s pieces are all interchangeable. Chess is a step up, with several distinct types of pieces, and wargames (of the “miniatures on a table, with a thick rulebook”) are more complicated still. (Of these, my original design was closest to the last. But I’ll explain in more detail below.) Turning to computer and video games, most “strategy” games I’ve seen have either interchangeable units or a variety of types, each of which has certain defined statistics, and a unit of one type cannot be converted into another type. Most “tactics” games I’ve seen have a variety of “jobs” or “classes,” and a character can often be converted from one to another, but there is a limited number of characters in the player’s party, while most “role-playing” games I’ve seen (not many) have classes but concentrate on advancing within them.
Strategic Primer began with the notion of a “unit” as a unit of (usually fifty) soldiers with particular training and particular equipment, emphasizing the equipment more than the training. The battle rules were primarily designed for the cases where one battle line met another battle line, and things were mostly a contest of will. After a battle, the winning unit probably gained “health”–soldiers–that had fled or surrendered rather than holding their ground in the battle, and if the losing unit had better equipment, it could loot the field for better weapons. Which is, of course, what happens when amateur armies are involved, but (with the possible exception of tabletop wargames with thick rulebooks, which might have a rule somewhere about it) strategy games don’t do this.
As my design for Strategic Primer grew, the size of most units shrank as their equipment became more important–the catapult, rather than the legion, became the typical Starting Package unit–and I started to look at things at a lower level. (I also played a tabletop role-playing game for the first time soon thereafter, which became a profound influence, but that’s not really relevant to this point.) I began to separate a unit’s base statistics from any equipment, “improvements” was the term I borrowed from Civilization: Call to Power, added to it. (Improvements to a fortress may or may not have been in the absolute original design, but were introduced before the end of the first campaign.)
I have since revised the model to make it somewhat more consistent and orthogonal, completing the separation of human ability and experience from equipment, and will talk about the current model in my explanation of the technical problem below, but the same concerns apply even more so to the more complicated previous revisions of the design. I have also eliminated a rule, which exacerbated my difficulties overwhelmingly, that a player got a free unit or fortress improvement of every kind he or she discovered instantly upon that discovery; without that rule, I suspect my problem here would not have grown in scale enough to trouble me, though I would have had to improvise rules about production.
The technical problem all of that is intended to lead to is this: at the beginning of the present campaign, which is vastly simpler so far in the relevant respects than any previous campaign (largely due to my elimination of the “free prototype” rule and a similar rule that started every player with two of every unit in the Starting Package), there were a total of sixty units. In the new model, a “unit” is (for our purposes, i.e. at this level of abstraction) merely a soldier or worker. Most of these sixty units did not have any notable equipment (ignoring equipment that isn’t “notable” is one of the many simplifications I am making to make running the campaign possible), but each had a level in one Job to complicate its starting statistics, and some were working in a different Job than their levels were in. As the game progresses, the number of units is growing dramatically (only the rule that the population of a fortress cannot grow by more than half its current size per turn has kept the total population we’re concerned with from doubling), and many will be given, or ordered to man, several pieces of equipment. When one player attacks another for the first time, I expect there to be at least a thousand units in the world, and I will need to be able to find all the units in a given tile, and then to know what equipment each is using and each one’s effective statistics after applying any modifiers from that equipment.
This is actually a nearly perfect problem to apply a relational database to. But I am not very good at database design, and in fact have only ever successfully programmed an application using a relational database in my Software Engineering class. When I started trying to keep track of units’ statistics, position, and improvements in the first campaign a decade ago, the only tool I had to hand (that I knew of) was the non-relational database (one table per “database”) that is part of Microsoft Works, which came with my parents’ computer. In fact, I had never to my knowledge encountered a relational database at that point, but I improvised something approximating relations to make a collection of Works databases into something I could use.
But even with a relational database, designed by an expert, the dramatic growth of units and notable equipment, and the advancement of most units in several Jobs per unit, will tax my ability to manage them even if not the database itself.