|HOME GAMES LISTING GAME PLAY & DESIGN WOMEN IN (WARGAMING) HISTORY||
A Minimalist Approach to Computer-Assisted Design: The "Wargames Calculator"
When we look at the development of a computer-assisted miniatures wargame system, we are faced with a task of daunting proportions. Not only must we identify the behavior and capabilites of units, and the probabilities and effects of their interactions on the tabletop (as for any miniatures wargame), we also need to come up with a technical design. We can base our game on an existing rules set - thereby circumventing much of the work - but we are still faced with the design and functionality of a plethora of different screens to allow players to do many different things. The obvious ones are movement and formation changes, fire, charges and melee, and morale, but we may also need to consider other functions like command control and orders, battlefield engineering activities, supply, and many others. It depends, of course, on what we want to have in our game.
And there are other challenges in computer-assisted wargames design, too. What information do we need to store about each unit/ship/tank (etc.)? How do we collect and store that information? Many rules systems use an approach where much of the needed information is either provided with the game (statistics on ships, tanks, etc.) or can be entered at set-up by whoever is designing the tabletop scenarios. An interface for setting up and editing the units/ships/tanks (etc.) is needed, possibly as a separate application. This creates a database which can be reused (if that's in the overall game design). Of course, we will need to be able to administer the database and print reports - more work! And then we have to address issues of usability (we don't want bored players waiting for the GM to type for five minutes every time a player does something), and issues of synchronicity (can the tabletop get 'out-of-synch' with the in-program information? Do we need to allow features for players to edit the game while playing? Save/recover the game in case of a crash?) The list goes on for a while. Dealing with this kind of stuff is what software developers do.
These are only some of the issues: they are legion. However, if we step back and examine the entire problem, we see that these challenges and requirements are based on some assumptions about the role the computer will play in the conduct of a wargame:
There are plenty of other things the computer could do, but from what I've seen, these are the most common ones. And they are all very worthy - these are the reasons a lot of us are attracted to such systems in the first place. We should realize, of course, that wargamers using paper-and-dice systems today are OK with all the clutter, look-ups, and wasted time, even though these things are annoying and can be done away with by using a computer. There are many paper-and-dice "fast-play" systems which abandon many of the more detailed aspects of simulation, and thus begin to solve some of these problems. They have proved to be incredibly popular, because they produce faster games which, although they may not be so realistic, are more enjoyable. They place the emphasis on the "game" part of the word "wargame."
For a long time, I have wondered how the interface for a computer-assisted miniatures wargame could be radically simplified. From what I have read elsewhere, I am not alone in this thinking - others have had this idea, too. The phrase which I use (and which others have come up with, quite independent of anything I've said or written) is "wargames calculator." I want to have a single, reasonably simple screen on my phone or tablet which lets me run a wargame.
The implications of such an idea, of course, are that some of the typical functions of computer-assisted miniatures design will need to be abandoned. If we use the fast-play wargame idea of what a player is able to tolerate, then we can look at the functionality of our computer-assisted design, and decide not to do everything, but only some of it.
The first task is to reduce the sheer number of screens. As with a fast-play wargame, this means getting rid of a lot of the non-core features of our game. We want to move units and kill things. Everything else is window-dressing. This helps a lot: no fancy command-control features or battlefield engineering tasks: these are nice, but not core.
And as for record-keeping: forget it. This is a lot of the heavy lifting. A fast-play paper-and-dice system simply abdicates this function. (Think about DBA. How many record sheets are there? Exactly none. You only know that the strength of your army has been reduced because you remove bases from the table.) If we decide to do the same thing with our wargames calculator, we can simplify things considerably. No more set-up screens, and no more database administration. We know the unit is there because the figures are on the table. Fine. All we need to know is what type of unit it is, and we can determine that by looking at it.
Fog of war? Well, insofar as we can still hide the details of every game mechanic from players, we can preserve this functionality to some extent, but as for hidden movement and unit statuses, etc., we will just default to what players do now: accept that everyone instantly knows everything at all times. If they want to use paper-based fog-of-war mechanisms, that's fine.
This leaves us with a smaller set of computer-assisted functionality which we will not abandon: automated chart look-ups and detailed algorithms for resolving combat, etc. If we are to implement a "wargames calculator," we will need to fit this much into a single, simple screen. Can it be done? I decided to try.
Before we go any further, I should point out that what follows is sort of an extreme example of an approach that could well involve a bit more complexity and a bit more functionality. What follows is an experiment, just to see what could practically be done. (Other developers would no doubt make other decisions if they were to attempt the same thing.)
I am happy to report success. I created a grand-tactical game for the Franco-Prussian War (I play Age of Valor and other Fire & Fury derivations quite happily, so I wanted to do something different using the same figures). The game is called La Guerre Ó Outrance, and it models the war at a level where entire battles can be played on a small table: players are army commanders, controlling divisions as the basic maneuver unit. My single screen is shown below:
What you see is the entire game - there is no set-up, no editing of unit characteristics, and no in-memory storage of anything which could get out-of-synch with the tabletop. If the game crashes, you re-start it: nothing is lost. Multiple players can run it at the same time in a single game, without any networking, because all it does is calculate results. If the game master steps out for a smoke, no problem: you just use somebody else's smart-phone for a couple of minutes. All the information is "stored" on the tabletop. I do use markers for disorder and demoralization (casualty figures, in my game). The tabletop still looks clean. I'm pretty happy with the result.
The sequence of play is simple: you click the initiative button and a box pops up randomly giving it to the Prussians or the French. That side can now move one unit. Repeat until all units have gone, and then its a new turn.
The game itself has only a limited number of troop types: infantry divisions, cavalry divisions, generals, and corps artillery reserves. There are three quality levels: Guard, Line, and Landwehr/MobilisÚ. Cover is limited to None, Soft, Hard, and Fortifications. Actions requiring the computer are: Deploy, Maneuver, Deployed Fire, Advancing Fire, Assault, March, and Regroup (there are a few other actions which don't require the computer, including resting, moving generals, and route marches). Units are in maneuver formation (columns screened with skirmishers), deployed (firing line screened with skirmishers), or march column.
I tried to minimize the number of clicks needed to take an action. For movement, all you have to do is select the unit type and the movement action (maneuver or march). When you click the Result button you get a box telling you the base movement rate. Ditto for regroup actions: three clicks. In both cases, a pop-up will ask you if there is a general within command radius, as this can affect whether orders are lost/delayed, and whether a regroup succeeds. Fire requires more - you have to select also the type of target unit and its formation, range and cover, and you may need to deal with disordered status or relative numbers. The absolute worst-case scenario is ten clicks. Normally, it requires five or six.
Making a close assault is the worst: this can take as many as twelve clicks (normally seven or eight). The point is, this is as fast as using dice and charts, and probably faster. (Skeptics will say "That's not true - when I play DBA we just roll the dice." Bullshit. I've played a lot of DBA, and not only do you have to look up modifiers [and try to understand the Barkerese!], but also what happens when some element type is beaten-but-not-doubled in certain terrain by some other element type, etc. etc. It does not just involve rolling the dice. Other fast-play games are, in my experience, similar. Not that I'm complaining - I loved DBA and I like several other fast-play games, The Pikeman's Lament being a current favorite.)
Combat results include disorder, demoralization, push back, the loss of a base, being shot to a standstill in a charge, being forced back in a charge, being swept from the field, and others. It's the same as what you see in games like Fire & Fury (although it is not an implementation of that system). When you take significant casualties, your unit loses bases.
So where's the complexity? A lot of it is in the details which the players don't see: divisional structures, weaponry, doctrine/training of different forces, and historical combat behavior. The composition of a Prussian infantry division is not the same as a French infantry division, and they had very different weapons. This is true across the board. And when you factor in tactical doctrine, you end up with a different picture yet again: how many troops would be deployed as skirmishers? How far in advance of their supports? How did they behave on the battlefield? What was the divisional artillery doing? How many guns? What kinds of guns at what range? Did the divisional cavalry matter at all in this type of terrain?
Every combat action takes this kind of detail into account, assigns point values, and performs various calculations to determine the combat outcomes (and yes, it rolls some dice while its at it, but randomization is far less important than in most fast-play games.) As a piece of software, it is actually incredibly simple. But from the perspective of a wargame, it has significantly more detail. Think about what Phil Barker and company had to do in writing DBA: they reduced a large range of historical types with a variety of arms and armor to a single troop type (Psiloi, Cav, Blades, etc.). Formations and doctrine and behavior and everything get lumped into a relatively large category which perforce must make blanket assumptions about a lot of the detail. It relies heavily on randomization. Here, I'm really doing much the same thing, but the computer lets me do it without losing a lot of the important detail, which means I can rely less on randomization to fill in the blanks.
In truth, I spent considerably more time doing research than I did writing code (and I own a stack of cool new books on the FPW, too!). As with any wargame, the rules have to incorporate a lot of research if they are to depict a period with any accuracy. The actual coding was a matter of a couple of days, once I knew what I needed to program. But that's beside the point. The question was whether a minimalist approach to computer-assisted design could produce a reasonable fast-play wargame - I'm convinced that it can.
Copyright (c) 2018 by Arofan Gregory. All rights reserved.