Megagame Design Debate – a new way of designing megagames
Onside Report on the Megagame Design session at CLWG on Sunday 6 August 2017 – By Tom Parry
First, we would like to thank CLWG for inviting us to discuss megagame design. We had a very enlightening discussion, and we now have a much firmer grasp on the philosophy behind most megagame design. There is plenty that we disagree with, which we will go into greater detail about in a moment, but we want to be clear that we are not claiming that our approach is objectively better. All we are claiming is that we would prefer to build and play a different style of megagame, and we are not the only ones. We’re not saying that other megagame designers need to build or play this style of megagame, merely that we would like to.
In our experience, the most common kind of megagame is a political simulation (of varying accuracy). For the sake of clarity, we will refer to this kind of megagame (including Not Over By Christmas, A New Age Dawns, and Watch the Skies) as a “classic megagame”.
We see all megagames as able to be broken down into a “top” and “bottom” layer. The bottom layer is the underlying mechanics; i.e. the rules spelled out to the players that define what they can and cannot do. The top layer is the communications between the players, and the inability for any one player to know all open information. That is, the top layer is what differentiates a megagame from any other kind of entertainment.
Classic megagames seem to be designed from a “top-down” perspective. By this we mean that the game is designed in order to produce the “best” scenario – whether that be a historical simulation or a “what if?” exploration. For example, the priority when designing Crisis in Britannia appears to have been to evoke the most authentic feel of being a Celt in this time period. This is not how we would have designed the game, and if we were, our version would play very differently. The desire to evoke the feel of being a Celt would still be present, but it would not be our main priority. To understand how we would have designed Crisis in Britannia, we first need to discuss what we mean by “meaningful decisions”.
When we design any game, our first priority is to always ensure that players are making meaningful decisions. To us, for a player choice to count as a meaningful decision it must contain the following four elements:
The player must be aware they are making a decision, know what the options are, and have some understanding of the consequences
2) Mechanical Consequences
Their decision must be resolved through game mechanics
The player can recognise the impact and consequences of their decision
The player cannot undo their decision after exploring the consequences
If any one of these components is missing, then the player has not made a meaningful decision.
To refer back to our example of Crisis in Britannia, if we were designing that megagame, we would always choose to sacrifice historical accuracy if it would increase the available meaningful decisions. For example, we would give the Celts a bigger opportunity to defeat the Romans in battle. This would be historically inaccurate, but it would increase the availability of meaningful decisions.
The clear difference between our design philosophy and the classic design philosophy was displayed when we asked Jim at which turn he expected a city to be overrun by zombies in UNSOC. His response was “that is a non-question”. He explained that it didn’t matter if a city become overrun because the police units were invincible, therefore the city players would still be able to play. From our perspective, “players can play in an overrun city” is a non-statement. This is because they no longer have the ability to make meaning decisions (by our definition). To clarify, the player’s choice at this stage would be to either attack the zombies (which can only result in death of the police unit at this stage) or to not do so. Both options end in essentially the same result; the police unit does nothing. Thus, this is not a meaningful decision by our definition.
Our version of megagame design has not been explored before (to our knowledge). We intend to explore this “bottom-up” approach in our megagame designs. Even if we build a historical megagame, we will always choose to sacrifice historical accuracy if it will create additional meaningful choices for the players.
We are aware that we are among the less experienced megagame designers, and so we would like to be able to draw upon the experience available at CLWG. However, for anyone to be able to support us in megagame design, they must be able to understand our design philosophy and priorities.
Our focus on mechanics-first design led us to pose this question: What is the difference between a 60-person board game and a megagame? To us, there is no difference at all.
Ignore the 404, I’ve fixed the problem.
Interesting that wordpress seems to put a load of random and mostly irrelevent links to wikipedia in the article that were not there in the version I pasted in. Is this some sort of widget?
Also it seems to have added a picture at the top that was of a completely different session?
I do share a lot of your perspectives, my Mexico game was written bottom up and I am very much at the game end of the CLWG spectrum. I do however take issue with your definition of meaningful. I agree with the awareness and reminders parts. I think the permanence is a bit of a red herring – surely that would depend on the circumstances?
I take issue with the mechanical resolution part. It is trivial to provide counter examples where a major decision has no mechanical impact. Should we declare war on Germany? Should we form a marriage alliance with Spain or France?
While you could have purely mechanical consequences for those they could also be fully resolved through player responses. In fact you could have a game entirely mediated through player responses though that would probably be a roleplaying game.
Note I say player – I suspect we both agree that control mediation is never an ideal solution.
Sometimes for me though it’s least bad, usually for covering edge cases, definitely not for core processes. Proposing a mechanical solution for everything will lead to a lot of mechanics which becomes very hard to implement correctly. It’s hard enough to get simple core systems carried out right let alone obscure peripheral rules.
There is a bit of an intangible in that more than just meaningful the decisions have to be “interesting”. What that means will depend on context, taste and the scope of other things you have to do – not every decision has to be hugely exciting if you are doing a lot of stuff but making very similar low impact decisions over and over is also not a lot of fun.
I do not think a megagame is identical to a huge boardgame any more than it is a simply a huge game of D&D and those things are definitely not the same.