(This is an adaptation of something I wrote for a different purpose than this blog. On reflection, I decided that there was material for a good blog entry here as well. While much of this is stuff I’ve said in previous blog entries, not all of it is, and pulling it all together in a single entry is, I hope, interesting and useful.)
For me, a game design is defined mostly by its limits. And that is the first thing I like to do when starting work on a game. All of my initial research and investigation is focused on this. Once I know what the limits are, I know what else I need to know, and what I can ignore. (If I know that the pieces are brigades, I know I can generally ignore the such-and-such battalion in my research. It doesn’t matter.)
Some of these limits are subject-limits, and apply to what boundaries I will draw around history to determine what parts of history the game will include, and what parts of history I will leave out. Other limits are game-limits and define what kind of game I will be making, and are related to the subject only indirectly. All of the various limits flow back and forth into each other; changing one will generally have consequences for the others. So, let’s begin.
To start, let’s go through what I see as the major subject limits:
Subject Area. This begins with a geographic rectangle around what will be included on the game map. I do need to be aware I will need space somewhere in that rectangle for play aids and tracks and such. But so long as I have extra space, I don’t need to worry about the exact layout until later.
Subject Time. This is a range of time, with a start and end, that defines what time period the game will cover.
Subject Scope. What sort of things are included in the game. For a wargame, I pretty much certainly intend to include the locations and movement of military forces in the subject area, but there are other things I can choose to include or omit as part of the subject scope. What about forces that weren’t there historically, but which might have been there? What about forces that arrived at one time, but might have arrived at a different time? What about limited intelligence? Weather? Ammunition? Morale? Command and control? Individual commander personalities/abilities? Fields of fire? And so on, and so on. (Note that setting scope of a system is not the same thing as designing the system: choosing a city I want to live in and a rent I can afford to pay is not the same thing as choosing the exact apartment I am going to live in.)
Subject Scale. How fine-grained is the subject resolution going to be? What are the smallest areas I can resolve? What is the smallest time unit? For the military forces I include, what is the unit scale? For each of the subject scope elements I plan to include, what is the mix of detail and abstraction do I intend to use?
Now let’s go through what I see as the major game limits:
Game Size. Physically, how big is the game going to be? This starts with board dimensions, but doesn’t end there. How many pieces are there going to be? How many markers, charts, play aids? Game size is not only about how much space players will need to play the game, it also correlates strongly with manufacturing costs and retail price point.
Game Time. How long is it going to take to play the game from start to finish? In general, the longer the game, the less often it can be played. People only have so much time, and the space the game occupies will have rivals for use of that space. A game that takes up a 44"x34" but can be played from start to finish in 3 hours is a very different proposition for players than one the same size that takes 20 hours to play. The 3 hour game can time-share a dining room table with family meals. The 20 hour game can’t. There is another, more subtle consideration with regard to game time: playtest time requirements scale with game time. All things being equal, a 4-hour game will need twice as many hours of playtest time as a 2-hour game to reach the same level of quality.
Game Complexity. How hard is it going to be to learn to play? A useful metric is rules length, but writing style makes a big difference there. Still, within any given style, complexity generally rises at least as fast as word count. And so, rules length of a given rules style is a good stake-in-the-ground complexity budget for the game. I can look at a game with rules written in a style like that I plan to adopt. Compared to that game’s rule book, how long is the rule book going to be? The same? Half as long? Twice as long?
Game Variability. How much game-to-game variation will there be in terms of how the game plays? At one end, there are games that I consider to be “closed”, where the players have very limited scope in the choices they can make. On the other end, there are games that I consider to be “open” where players can make a lot of different choices. (Choices that almost always end in defeat are not, by the way, things I consider choices in this context.) By way of example, NT was designed as an “open” version of Austerlitz where the Allies could try a lot of different plans. On the other hand, there have been “closed” versions of the same battle where the Allies were pretty much compelled to always repeat the historical plan of attacking the French right.
Wargame designers as a group, I think, tend to design around subject limits and let game limits fall out of that process as consequences of the subject and their treatment of it. (For example, I’m pretty sure that the design team of War in the East didn’t decide to do a 200 hour game on the WWII Eastern Front, and then chose a division scale as the best way to make that happen.) But that is not at all how I work. For me, game limits are very strong limits and have a very powerful effect on how I treat a subject. Generally, I start with game limits and a subject, and then see what subject limits fall out from there, to tell me to what I can and can’t do with the game.
Just a short blog entry for those left in doubt by the last one.
There is another game in the chute after the new edition of Bonparte at Marengo, and that's an Eylau game. It has the working title of Napoleon, 1807 with a subtitle of The Battle of Eylau. In giving a game a title I try to ensure that the most important word that establishes what the game is about is in the title of the game. In the case of Napoleonic games, that’s usually going to the name “Napoleon” (or “Bonaparte” as the case may be). The trouble with Eylau is that it isn’t that well-known a battle, and the name is rather odd looking. (And no, thank-you very much, I wasn’t about to go with “Preussisch-Eylau”.) If people who are not Napoleonic enthusiasts see the game, and get the message that the game has something to do with Napoleon, I will feel like my game title has accomplished it’s mission.
(And I would like to say that I have quite a few customers for my Napoleonic games who don’t know much about the Napoleonic period, and I am glad and happy to have them. I value all my customers, and want anyone who gives up time and money to learn and play one of my games to have a good experience with it. And if one of my Napoleonic games is a gateway drug to the period, so much the better. My own love for Napoleonics is true and deep and it always delights me if I can introduce someone new to it.)
Anyway, I can’t say I’m completely happy with the title, and will certainly change it if I get a better idea. One of the problems though, as with anybody trying to do a new game in this period, is that obvious titles tend to already be taken. You can re-use a title, which not generally illegal as copyright law doesn’t apply to titles, but doing so is confusing to customers and that is generally a bad thing to do if it can be at all avoided.
I may yet get a better idea for a title, and certainly would be pleased if I did, but for now, it is “Napoleon, 1807”.
A peek at what’s coming down the road.
(Click on the image to open it in its own window.)
So, originally for this blog entry I had this grand plan that having discussed two eastern front games (Stalingrad and War in the East) I was going to drill down into how those games handled production, and then use that as an introduction to my thoughts about production in Stavka, an eastern front game of my own that I’ve been working on. However, once I finished discussing Stalingrad and War in the East, I found that the blog entry was quite long enough already, and that it made better sense to just go ahead and post it, and talk above Stavka another day. And so, that’s what I’m going to do.
Anyway, I’m going to start with Stalingrad, the older and simpler of the two games I’ll cover today. (Incidentally, the Stalingrad rules refer to production as "replacements", but we’ll use a more generic term in this discussion.) Below is a process model, focused on representing inputs and outputs.
As you can see, it is super simple. Production cites make production points which are used to buy units. The production rates (points per turn per production city) are low for the Germans at start and stay low. For the Soviets, on the other hand, rates start low but go up over time. The result is that the production system is designed so that the Germans generally grow weaker over time, as their production can’t keep up with their losses. The Soviets, on the other hand, tend to grow weaker early in the game, but as their production rates rise, so does their strength. The only way the Germans can win is to capture production cities to cut off the Soviet ability to replace losses. The importance in the game of German capture of production cities is reinforced by the fact that production cites are the actual objectives in the game. If the Germans capture them all, they simply win. Game over. The system, which unifies military and game play goals, is neat, clean, and easily grasped. The production rules are covered in about 650 words, or about 15% of the Stalingrad rulebook.
Considered as a simulation, the system is more synecdochical (the part representing the whole) than directly representational. Essentially the three cities if captured represent such large territorial losses that the Soviet Union would genuinely have been in dire straits, even if not exactly in the way represented in the game. The biggest disconnect between history and the Soviet production system, I would say, is the inability of the Soviet army to ever exceed its pre-war strength levels, since the only units that the system allows be produced are those the Soviets had at the start of the game. But given the game’s general indifference to the latter half of the war, when the Soviets switched to the offensive, this is at least consistent with the way the game treats the history of the war generally.
Now, let’s move on to War in the East, and take a look at how it handles production. (Note that this discussion is focused on the system used by the Soviets for the campaign game. The Soviets don’t use it in the single-year scenarios, and the Germans have a completely different, more lightweight system of their own.)
Obviously the system looks (and is) significantly more complex, so let’s walk through it. The Soviets have personel and arms centers, which produce personel and arms points. Those points are used to buy units. The units are then placed on training centers, and after some period of time the units are trained and ready for use. An additional wrinkle is that units can be re-cycled through the production system to produce other units: units can be both a production input and output. And that’s it. If we compare the War in the East system to Stalingrad, the most important functional difference is time. In Stalingrad, unit production is instantaneous, and in War in the East it takes time. The basic arithmetic of the War in the East system (personel points plus arms points plus time buys units) is somewhat more complex than Stalingrad’s (production points buy units). Where things can be quite surprising though, is if we look at the cost in rules text for the two systems. The rules for production in Stalingrad take up 650 words, or about 15% of the rules length. The rules for production in War in the East take up about 8,000 words (!), almost 30% of the game’s total rules length, over ten times the length of production rules fo Stalingrad, and almost twice the length of the entire Stalingrad rules book. Even allowing for the fact the the rules writing style of War in the East is quite a bit more verbose than that of Stalingrad, that’s a lot.
So what happened? Why is the rules word count for the production system of War in the East so high? In general, the answer is that the production system in War in the East has a very process-heavy focus. Arms and training centers are movable pieces on the board, and each has its own special rules. There are three or four different ways (depending on how you count) of using units as production inputs. Unit training is literally localized on individual training centers, and building units involved placing them on the tracks shown below, each of which corresponded to a training center:
After being placed on a training center track, a unit being trained is literally pushed forward by the player, one space a turn (and yes, it did get old real fast to do that), until it is ready, when it can be moved to the front. Because units frequently required other units as inputs, units often have to be moved to training centers, as well as from training centers. Ironically enough, The entire localized training center system is frequently rendered irrelevant, as training centers can be moved to the abstract space of “Siberia”, where centers no longer have a specific location. This left the rules to regulate both non-localized arms and training centers (those in Siberia), as well localized arms and training centers (those on the map).
Now, the actual management of a war economy was a vastly complicated thing, but the things that made it complicated weren’t the things that War in the East simulates. In the actual war economy, factories didn’t produce generic “arms points”, they produced specific types of weapons, ammunition, parts and supplies, and they in turn depended on the production of various kinds of raw materials. Further, the factories themselves need machines for production, and those machines had to come from somewhere. People drafted into the army weren’t able to keeping doing what they had been doing: if you draft your agricultural labor force into the army, who’s going to be producing your country’s food? So finding people to serve in the army while keeping your economy going was a difficult problem. War in the East doesn’t simulate any of those things. It abstracts them. Now, to be clear, I think abstracting them was an excellent decision. Big, long game; lots of other things for it to do. No need to open that can of worms. But if you aren’t going to simulate them, what do you need a complex production system for?
I can’t know for sure why the War in the East design team went with a system that is abstracts so much, yet remains so complex. (Incidentally, the 2nd edition of War in the East, designed to integrate with War in the West to make War in Europe vastly simplified production from the first edition.) I can, however, make some reasonable guesses. First, I’m pretty certain that when the design team started down this path, they didn’t realize how complicated it would ultimately prove to be. I think they thought the whole production system would be a fun and interesting game-within-a-game, a mixture of representation and abstraction. The design just got away from them. (Complexity creep is a problem in all systems development. An unexpected problem arises, and the system is modified to fix it. Over and over again. It might be that none of the individual modifications is large, but they add up over time, and eventually the system becomes much more unwieldy than ever envisioned at start. And for the record, I’d really like to say that if that’s what happened to the SPI design team on this one, that I have a lot of sympathy for them. I’ve been there.)
And with that, I’m going to close off this blog entry. A Stavka discussion is coming. I promise.
I would like to begin today by telling you a story.
Years ago, when I was just out of high school, a store opened near my house that sold books and wargames. I applied for and got hired there as a clerk. (For me, at that age, it was the perfect job; sure beat the dry cleaners where I had worked before.) Anyway, the store hadn’t been open long before it became the home to a group of Napoleonic miniatures players. (Not all were miniatures players before joining the group, but all were wargamers of one sort or another.) At the endorsement of their host, my employer, friend, and owner of the store, they began to use an informal adaptation of the rules to Wellington’s Victory, Frank Davis’s game on the battle of Waterloo, for their games.
I wasn’t a part of the group at first. Miniatures weren’t really my thing: you either had to have tons of money or a love of painting tiny figures, and I had neither. Still, I watched some and began to get interested. I could see that they were having problems because their adaptation wasn’t really written down anywhere and they had to work out issues on the fly. Anyway, I offered to see what I could do to help. And so, with my copy of Davis’s rules to Wellington’s Victory in hand, I wrote an adaptation for Napoleonic Miniatures, dropping the things that were Waterloo-specific, and introducing generic rules where they were needed. And from that point on, I became both a member of the group, and (at first) the keeper of their rules, and later their in-house designer. (Because they later wanted a series of strategic rules for campaign games, being their in-house designer was actually a fair amount of work, but it was also great fun.)
Anyway, because of this group, the rules to Wellington’s Victory were the core of my wargaming life for about five years. I got to know them about as well as it is possible to know a set of rules, what they did well, and what they did less well. I loved them. I loved how creative they were. I loved how much they rewarded study and thought. I loved how clean they were. I loved their capacity for drama and excitement. I had previously greatly admired Davis’s Frederick the Great but my experience with his Wellington’s Victory system took my admiration of him to a whole new level. He was my hero and everything I aspired to be as a game designer.
It was during this period that I got to meet him. (It was at my request. We were both at the Origins gaming convention in Baltimore.) I was very nervous and very excited. I worried that he would take offense at some of the changes I had made in adapting his design for miniatures. I hoped that he would help me with advice on how to design wargames professionally.
The meeting did not go at all as I expected. He was kind, but seemed quite sad. I was sure that things were not going well for him in his career, though I had no idea in what way. (I still don’t. I could speculate, but don’t see the point.) Anyway, at one point when I was gushing in my enthusiasm, he just said, “Where were you several years ago?” It almost broke my heart. Of course I had been in high school then, but I knew he wasn’t asking the question literally. I took it to mean that at an earlier time in his career, he could have used my enthusiasm, but now that time had passed.
I never met Frank Davis again. I heard occasional snippets of news about him in the gaming world, and it seemed it was never good news. Eventually, I stopped hearing anything at all.
But Frank Davis is still my hero. I titled Napoleon’s Triumph as an homage to Wellington’s Victory. It seems pretty certain that he no longer has any connection to the gaming world, and perhaps that is how he wants it. But his influence there continues: I am part of that, and grateful for it.
A week or so ago, I found out that Decision Games had published what they call a second edition to Wellington’s Victory. (They actually published it over a year ago, but I knew nothing of it then.) This news really upset me and still does. An actual second edition of Wellington’s Victory no longer seems possible. Now, I am not upset at all that a new game on the same subject in the same scale by a different designer was published. In fact, as I think of design in our community as a long-running conversation, and so each new design is welcome and adds to it. What hurts me here is that calling this new game a second edition of Wellington’s Victory it doesn’t so much add to the conversation as attempt to erase and overwrite one of its most distinctive voices. Anyone who read the design notes for Wellington’s Victory knows what a personal project this was, how much of himself Davis put into it, and how long and hard he worked on it. He should not now be treated this way. It shouldn’t happen. It is morally wrong. I don’t think there is anything I can do at this point beyond voicing my protest, and remind you of the person I will always think of as the greatest designer whose work I was ever privileged to play, but I can do that, and I am doing that.
I thought I would follow up my previous post about the progress of playtesting with new edition of Bonaparte at Marengo with a more general discussion of playtesting in terms of process.
Generally, I move a design from development to playtest once it has a playable map, order of battle, and rules, and seems to function more or less as designed when I play it solitaire. At that point, I look for a playtest team. It is much my preference to get a fairly small group of people (5 or 6 is a good number) who have the time and interest to play basically the same game (with adjustments between games) over and over again. People who playtest for me will learn the game so well they could play in their sleep, and that is what I want. It is their expertise that I count on to ensure that the game that ultimately ships is balanced and the way it plays is well-understood. We live in the age of the Internet. If players find that a game is broken in some way, everyone in the community will know it. This is a good thing for players, but it is challenging for designers. Still, I firmly believe it to be a very good thing.
Anyway, if we look at playtesting from a process perspective, the core of the process is the playtest cycle, as illustrated in the diagram below:
One of the important things to understand about playtesting is that it isn’t necessarily the number of hours that matters: it’s usually more about the number of cycles. If you just play the early turns of of a game, you haven’t learned how it will behave in the later turns, as these cannot be necessarily predicted from the first. (For example, a version of Bonaparte at Marengo can work just fine in the opening and middle game, and fall apart completely in the endgame. And you wouldn’t know about the problems unless you play all the way through to the endgame.) Further, after you make a change, that resets the playtest clock to an extent and you really need to play it through again (at least once) to get even a basic understanding of the consequences of the change. In general, the faster you can get through a playtest game, the more cycles you can run, the more problems you can find and fix, and the more confident you can be in the fixes.
Because of the need to run full cycles, one of the most intractable problems in the design of long-playing games is how much time it takes to complete a cycle. Bonaparte at Marengo takes a couple hours face-to-face, and a few days over Cyberboard (roughly: Cyberboard playtime can be wildly variable due to wide differences in player availability from game to game.) Guns of Gettysburg was somewhat longer than Napoleon’s Triumph, for example, and so the playtest cycle time was longer as well, and for that reason alone it took longer to playtest. (Additionally, Guns of Gettysburg had a complex testing problem because of its variable reinforcements and moving objectives. Testing game balance took forever, a process I described at the time as the playtester death march.)
And this leads into a discussion about a game that I did not design, but which is relevant to a discussion about playtesting and time. (I said I was going to occasionally talk about games other than my own.) This game was SPI’s War in the East (1974). In a previous blog entry, I discussed Stalingrad, published in 1963, and the intense interest people had in making a better Stalingrad. This desire also was very much present in SPI, which took the form of the Stalingrad II project. (For SPI, better meant first and foremost bigger: they wanted an immense division-scale eastern front game.) Stalingrad II never happened, but with GDW’s publication of the conceptually similar Drang Noch Osten, SPI was challenged/provoked/inspired to go ahead with their version, dropping the title Stalingrad II in favor of War in the East.
If we were to compare War in the East to Stalingrad, an entirely appropriate comparison for a game whose origins lay in making a better Stalingrad, the first thing that would strike us is its size. It had four map sections, each as big as the Stalingrad map, and used about 5 times as many counters to represent the armies. (The total number of counters was enormously greater: 2000 vs. about 100, but only a fraction of the War in the East counters were units that would be on the map together at the same time.) But by far the most transformative aspect of the design was playing time.
In terms of playing time, Stalingrad was a longish game, but nothing more than that. Players whose expectations of board game length were set by Monopoly, for example, would have seen nothing extraordinary in the length of a game of Stalingrad. War in the East was so different in terms of playing time that it didn’t even really belong in the same genre as other boardgames. It wasn’t a game that you got out of its box, played for a few hours, then put back. War in the East was an ongoing, long term activity that demanded its own, large, dedicated space that it could share with nothing else: it was more like a model railroad set than a game. You could start a game of War in the East, and you could play it, but you could never really finish it: it had in the neighborhood of 200 turns.
And here we return to the subject of playtesting. I am certain that War in the East received more hours of playtesting than, say, the new edition of Bonaparte at Marengo, but it had many fewer cycles. (I infer from the design notes that in fact it never had even one full cycle.) So, if you can’t run playtest cycles, how do you test your game?
The short answer is that you can’t.
The long answer is you can try and test parts of the game independently from each other, and hope that if the parts seem to work ok in isolation, that when they are put together they will fit reasonably well. In practice, however, I think SPI had lots of evidence that their parts weren’t going to fit together, but knowing you have a problem and knowing how to fix and test it are very different things. Even their partial game tests (like yearly scenarios) had very long playing times in and of themselves. They wrote a computer program to try to test their production system, and as someone who spent many years writing computer programs, I can say that one of their worst features is that they are quite hard to dynamically change. If your program finds a problem in your production system, and you devise a new system in response (not merely minor changes to the existing system), you will likely have to write a new program to test that. As a way to test a subsystem for a boardgame? Not cheap. Not fast.
If we step back from theory and look at the actual game, we can see that design failures pervade War in the East. It is hard to think of a significant part of the game that doesn’t have serious problems, both in simulation terms and game terms. (Stalingrad may not have worked as a simulation, but it did work as a game.) I believe it isn’t so much that the design ideas in War in the East were bad starting points for a game, it was that without any real ability to run playtest cycles, there wasn’t any real way for SPI’s design team to find and fix the problems. It was a hugely ambitious project and badly needed playtest cycles to really get it working properly, but the game’s length made it impossible to run them. That it wouldn’t work very well was almost a certainty, and it cannot surprise that it didn’t. The SPI design team weren’t incompetent (far from it), just overwhelmed by how hard it was to do what they were trying to do. It wasn’t as if anybody then had a lot of experience then trying to create games this big, complex, and above all, long. There is no doubt that the game is a failure, but given the degree of difficulty, I think it was a respectable one.
Oh, and one more thing. Whatever its failings as a game, War in the East looked damned impressive on the table. And looks matter.
We’ve been continuing playtesting of the new edition of Bonaparte at Marengo. What makes the last week unusual is that I personally played a playtest game, which is very much not my usual practice. The “playtesting” I do tends to be fairly brief solitaire exercises of a few turns to make sure a change looks promising before sending it to the playtest team. Nothing like the full-length two-player games that makes up playtesting proper. This time, however, I played out a full Cyberboard game against one of the playtesters. So, why do I usually not playtest, and why did I decide to this time?
The reason I don’t usually playtest is that it takes time and mental energy that I think is best reserved for design work. There are design problems to be solved, rules to be written and edited, and map work to be done. Not just on the game currently in playtest, but in designing the next game to follow the one currently in playtest. I can’t do this work simultaneously with personally playing playtest games. Every hour I spend playtesting is an hour I don’t spend doing design and development work.
So, why did I do it this time? Well, it looked like the V20 version of the game (we generally refer to versions of the game by the rules version numbers, so this was version 20 of the rules) had a serious problem. V20’s first playtest looked really good to me (and it did solve a real problem with the game), but the second game went poorly and the playtesters were expressing reservations about the morale levels being too high (and a couple other things). I had some ideas on how to play the game that were different than what the players were then doing, and I wanted to test them out, to see if their concerns were valid for that play style as well as the ones they were using. And so, I played a game. The test taught me quite a bit about problems with the changes I had introduced in V20, but where it really got interesting was the endgame, which I hadn’t even intended to test; I expected to quit the game about midday.
What my playtest game taught me was that the game play was both super interesting and involving (very good) but the opening game balance was badly broken (much too tough for the Austrians) and the endgame balance and historical accuracy were also pretty broken (very bad). These were things I wasn’t even trying to test. I will say that doing the occasional playtest myself is something I should do periodically, in spite of the time cost. Looking at the game from the perspective of a player rather than an observer is a different enough experience that some problems (but not all) are just much more clearly seen from that perspective.
Since then, I’ve done a couple of new rules drops (V21 and V22), aimed at opening and endgame issues. V21 went through one playtest, reminded me forcefully of another endgame problem (a French late game retreat) that’s been there forever but which I had gotten so used to I had stopped really thinking of it as a problem. I decided that that was one tactic that really needed to go: it was ruining the endgame every time it happened. We’ll see how it works. These are both pretty substantial changes, and will need time to work through so that we understand the ramifications better. You just can’t rush playtesting. It takes as long as it takes, and if you hurry it, you run a real risk of shipping a bad or even broken game.
Well, the new edition of Bonaparte at Marengo continues to get a good playtest workout. We’ve had about 20 playtest games, mostly Cyberboard, but also some face-to-face. We’ve had 20 different versions of the rules (many of which contain only textual clarifications, and not actual content changes) and 11 different versions of the map (changes have tended to mainly concern of the morale schedule and objectives). In all of this, we have quite a few small changes, but nothing at all dramatic. We spent a lot of time working on the French activation/organization rules, and got to the point where we’re all pretty happy with the result. We’re currently working on getting some subtle but important combat changes tested, and also the latest version of the objectives/marginal victory conditions. It’s all very important work to making the final game one that customers will enjoy, but it does not make terribly exciting reading: you really need the kind of familiarity that comes from playing the game to “get” the changes. I am happy to say that the game has not gotten more complex; in fact, I think it is slightly simpler.
Regarding this blog, for the last month or so, frequent entries concerning actual game development have seemed quite unnecessary, given the kind of changes being made and the pace of those changes. And so, I’ve had fewer entries, and they’ve been more about theory and process than details about the actual game.
However, there is no need for a design blog to be solely focused on my own games, and so I thought I’d do some commentary and analysis on some other games: not from a player’s perspective, but from a designer’s. I have no particular schedule in mind, nor any set list of games. (Although I definitely have some candidates in mind.)
Right now, I would like to discuss Avalon Hill’s Stalingrad (1963). Although it is obviously not a modern game, and however often it may have been played in its day, it certainly is not a game that gets much table time from anybody today. Still, I think there is interest in discussing it, and I hope that by the end, readers will feel that it was worth their time.
Anyway, Stalingrad was of the first generation of commercial wargames, and had a great deal in common with other games of its generation. You can see the counters and map below (not to the same scale):
By modern standards, the art and print quality were exceedingly basic. The order of battle and map were considered marginal in terms of accuracy even by the standards of 1963. (Famously, Sevastapol was put on the wrong side of the Crimea.) Likewise, the core game system was not really up to the job of simulating its immense subject, and simply cannot play out in anything resembling history. Balance, in the first edition, was marginal: it was possible, but very far from easy, to win as the Germans.
Given all of the above, you might think the game was rather a failure. It was not. It was actually a great success. It was widely played and widely discussed. Game play (especially the Soviet set-up) was examined in almost microscopic detail, and there was an immense cottage industry in alternate counter sets and rules. (I don’t see such alternate rules and counters as necessarily indicating game design failure, any more than the existence of a thriving aftermarket for custom parts for a car necessarily means that the car design was a failure.)
In attempting to understand why Stalingrad succeeded, I would suggest that a good place to begin is if rather than think of it as a failed simulation, we think of it as a sort of an early, eastern front Eurogame, with more than usual attention to its theme, and go from there.
Part of the game’s success was of course simply that its subject was the largest military campaign ever fought, and there was real anticipation for it as a result. But to chalk it up to solely that, I think, misses its real virtues as a game. The first thing I would call your attention to is the short, muscular rule book. It was just about 4,300 words. If we were to graph its word count by subject, we would see the following:
About 45% of the text (about 1900 words) is devoted to the core game mechanics (sequence of play, movement, and combat). Another 30% of the text (about 1300 words) are devoted to the key strategic sub-systems (production, supply, and rail movement). Everything else divides up the remaining 25% of the text. I would say that the rules reflect an admirable focus on what the game is really about. It is a very direct, unfussy game. There aren’t many pieces to move to complete a turn. Combat resolution is quick and relatively painless (long division aside). Production (replacements and reinforcements) is likewise quick and painless: you get production points and choose units to spend them on. There is only one thing in the rules that really strikes me as a weakness: and that is the handling of rivers. Because the game put rivers in hexes rather than between hexes, the extremely simple idea that attacking across a river doubles the strength of a defender turns into a long, complex, confusing labyrinth of rules text. Somebody should have slapped the designers and forced them to put the rivers between the hexes: the world would have been a better place for it.
If we turn to the game play experience, the heart of Stalingrad game play is tactical, and the heart of tactical game play is mathematics. The game uses a probabilistic, odds-based system, so 14 points attacking 7 is quite a different thing in terms of statistical outcomes than 13 points attacking 7. With a wide range of unit strengths to choose from, optimally mixing and matching units and working out the various probabilities to get the best possible likely outcomes for attacks (including “soak-off” attacks which the rules force through mandatory attacks on adjacent units) is a genuinely interesting challenge. The spatial element of game play is important but plays a clearly supporting role to the mathematical engine. Spatial play is dominated by the terrain on the map that can double the strength of the defender, and the linear nature of rivers in particular substantially enriches the range of possibilities for attacker and defender both. Overall, tactical planning of where to put defending units and how to attack them is involving and rewarding for both players. The design effort put into the combat rules is well justified by the player interest that results.
Undoubtably the greatest weakness of the game play experience is strategic. At the strategic level, there is just not that much going on, as play is relentlessly tactical. Yes, there are some strategic considerations, particularly in the form of the three Soviet production cities (Leningrad, Moscow, and Stalingrad), which double as objectives, to focus the energy of attacker and defender alike, but game play overall is dominated by tactical considerations as the Germans grind east, trying to keep the loss ratios as favorable as possible. It is also true that in the game the roles "attacker" and "defender" almost invariably map onto "German" and "Soviet". Winter does nothing that would tend to re-create the historical Soviet winter offensives, and with the game ending in mid-1943, the year-round Soviet offensives of the last two years of the war aren’t going to happen either. (What to do about the last two years of the war in an eastern front game is just a tough design problem; if Stalingrad took a pass on them, I don’t think that later eastern front games did much to persuade anyone that taking a pass was not a reasonable idea.) Anyway, the sharply defined attacker vs. defender roles for the opposing sides don’t make the game bad (generally players alternated between the two sides in different games anyway) but there is definitely a sense that an opportunity for drama, at least regarding the Soviet winter offensives, was lost.
So what can a modern designer learn from Stalingrad? Quite a few things, I think. I mentioned that the game was unfussy and direct. The core of the game is the mathematics of its combat system, and it presents that in a very clean way. Constructing and attacking a defensive line is a thoroughly involving process. There is no cookie-cutter, one-size-fits-all way to play Stalingrad. You always need to think through the individual implications of every single hex as a unique problem. Stalingrad also has a nice gradation of results for bad-to-good play, which makes it fairly forgiving for players of different skill levels: the weaker player can (and sometimes does) beat the stronger player, making the experience enjoyable for both, without being so random as to make thought and skill seem futile and pointless. Overall, the game is true to itself and what it is about. Game sub-systems that are intended to support game play do just that: they support it with a minimum of complexity and player effort. If Stalingrad is not played much any more it is not because anybody ever discovered that it was a bad game, it is because other games have come along since have its strengths but not its weaknesses. When you consider how many years and how many failed attempts were made before it happened, that’s a pretty impressive legacy that should not be lightly dismissed.