I asked my design partner, Mark Aasted, if he wanted to write something for InsideGMT about our game, Skies Above the Reich. He came back with a pithy reply. Actually, he came back with an uncooperative, evasive, mildly combative, yet unexpected, reply. It’s worth printing here. His reply may not provide the details of the difficult and often contentious design process that must be negotiated between two intelligent and mature designers (I hear you snickering, Mark), nevertheless it elucidates a certain something about what it’s like co-designing a game. This is what he wrote back:

“Do I wanna write one?  Ha ha ha…it almost sounds as if you asked if I wanted to write an article for a war game magazine. I remember how well the last one went. Hold on, let me wipe the tear from my eye and catch my breath…

What would I say?  (Cue Dr. Seuss)

Big planes go up, little planes go up,

Up, up, way way up!

Big planes and little planes meet and clash!

Fast, fast, as each go by!

Some planes stay, some planes go,

Bye bye planes, now roll the die…

Crashes and smashes and parachutes abound,

Oh my, oh my, what a terrible sound!

Around and around the little planes go,

Curiouser and curiouser one’s mind will flow.

Tally the score, oh what a chore,

Playing games depicting this war.

Mark~

I know I know, ‘curiouser and curiouser’ is Lewis Carroll.”

Designing a historical simulation game requires patience, historical knowledge, arrogance, inspiration, and a stick-to-it attitude, but when you add a second designer to the mix…well, the formula gets complicated. You can be sure the design process will take longer. You can also be sure that neither designer will be completely happy at the conclusion of that process. It’s hard to know which rates higher on the unhappiness meter: being unhappy with the product or with the design partner.

Mark and I still speak to each other. That’s an understatement; we live in the same town and game together, and continue to do so even as Skies Above the Reich enters the last phase of its design process (the tweaking at the very end). We’re still good friends and have all sorts of plans for expansions or add-ons for the game, depending on how well it does on the P500 page (and how it is received after publication), so I’d say our partnership survived the design process. Maybe it’s even better for it, but there were moments when I was ready for a divorce. He may have felt the same, but once that process begins you really feel stuck together no matter how long it takes.

Imagine a carnival race where your leg is strapped to another fella’s and you’ve got to hop from the starting line to the tape at the end, only each fellow is tugging and pulling and hollering “not that way, let’s go this way!” After the crack of the starting pistol, design ideas get so mixed that you can’t just run your own race without taking a bit of the other guy’s leg with you. And there is no point stopping or giving up, because unlike in this silly metaphor, there really is no way to untie an idea. Once one partner puts it out there on the gaming table and the other partner works with it, it’s no longer the idea it once was.

The necessity to express ideas to the other fellow makes designing harder because you must constantly persuade. An idea must therefore be crystal clear if it is to be comprehended, and there is no reliable means of comprehension without testing. No idea is worth anything if it can’t be tangible and testable. Every articulated idea is a challenge and the design process is really a series of negotiations punctuated by the occasional aha moment (if only it were the other way around). What really makes collaborative design ‘fun’ is that as soon as you give shape to an idea by putting counters on a map, your design partner is standing by to serve as critic. He’s a naysayer, a negative personality, and a generally nasty individual looking over your shoulder shaking his head dismissively.

Here’s an example. I had concocted an absolutely brilliant scheme for handling damage inflicted on bombers while maintaining the elusive fog of war. The Damage chits would gradually accumulate on the bomber with each pass of the fighter, but in a later phase some of those chits would be removed, dependent on a die roll. Removal might result in the “reveal” of serious damage, or it may prove that same damage was harmless. It also had the charm of reducing the number of counters we would need, leaving room on the countersheet for other stuff. I loved it and we tested it and it worked. It sat as an integral mechanic in the design for months, as we developed other parts of the system around it. Until that grim day when Mark finally couldn’t take it any more, and said:

“Oh, by the way, your damage mechanic? Yeah, it doesn’t work. It doesn’t make sense. Damage is there and then it’s not? Players aren’t going to get it, it takes too much time, and really, I want the feel of damage increasing to the point where you think that bomber has just gotta fall apart and yet there it is lumbering on. Why do we need an entire phase where you fiddle with damage counters just to see how many Damage counters are real? Wasn’t this supposed to be a quick and easy game?”

Aaahhh…

Mark had a short but brutal list of things needing work, and it sent us back to the drawing board in a fundamental way. Talk about frustrating, but it forced us to find a simpler and better scheme for handling damage, one fostering the sense that the B-17 can withstand a ridiculous amount of hurt while preserving the possibility of scoring that incredibly lucky shot. Had I been doing this solo, players would have been stuck with my (nifty) damage scheme and maybe some folks would have liked it, but plenty of players would have felt the same way Mark did. That’s just one of many things that would have been different had Mark and I gone our separate ways. There’s plenty more to enumerate:

Had I designed Skies Above the Reich all by myself, I would have finished sooner. Just finding the time and opportunity to sit down together was excruciating, and even waiting for an email response could feel like an eternity. Also, had I flown solo my ego would have survived unscathed (well…until publication), and I would have been able to lay one hundred percent claim to the design. All mine! That can’t be underestimated as a motivational factor, especially in a market where the game designer gets very little moolah. Sole authorship is surprisingly enticing, but it doesn’t always produce better games. That’s the point here. There are perks to roping in a design partner, although finding a suitable victim is not easy (such a person must tolerate my scintillating genius). Co-authorship batters down the ego, and as unpleasant as that is, once you embrace it, it actually makes you less defensive about your precious ideas. And then you realize and appreciate how this difficult process allows you to encounter ideas your brain would be incapable of concocting on its lonesome.

The motive for collaboration is not just the pursuit of a really good design, as noble a goal that might be. There is more to it. I would say the best part of designing collaboratively is the social aspect inherent in the long and irksome set of negotiations that we fondly refer to as the “design process.”

I can’t speak for Mark here, but my willingness to collaborate probably began with my preference for board games over digital games. Besides the tactile quality inherent in feeling a pair of dice in my palm or sliding a counter along the line of a road printed on a map, I like the experience of sitting around a table engaging with people face to face. I enjoy shooting the breeze as we move bits and pieces across a board and roll dice and shuffle cards. Designing collaboratively is probably just an extension of that same social desire to be around my fellow human being.

Finally, there is one other reason to collaborate, and it’s an important one. When things go horribly wrong and your adoring fans morph into irate customers demanding an explanation for why your game is broken…it’s really quite handy to point to a co-designer.

Author: Jeremy (Jerry) White