Megagame design: not just a big board game
Ed Silverstone helps to run Reading Megagames and is the admin for Megagame Makers. Here Ed has some thoughts on a common trap megagame designers fall into, and how to avoid it.
In this article, I’ll talk a bit about the differences between megagames and board games, and how they influence the decisions a megagame designer should be making.
Most megagamers are keen board gamers as well. So when we come to design a megagame, it’s natural to lean on that experience. After all, board games tend to be more polished - they usually go through hundreds of hours of playtesting, and often have entire teams of people working on them. They’re a treasure trove of interesting mechanics and engaging puzzles. And, as we all know, good game designers borrow, and great ones steal - right?
This is usually a trap.
The best outcome you can hope for when transplanting a board game mechanic wholesale into your megagame is that it provides an interesting diversion - something that absorbs a few players, silo’ing them off from the main game but still giving them a good day with interesting puzzles to solve. Far more likely, the players tasked with operating the mechanic will feel frustrated that they aren’t able to engage in the narrative elements of your game.
That’s not to say that board game mechanics can’t occasionally be a good fit for a megagame. But to successfully borrow one, you have to understand that megagames are quite different beasts.
A board game is generally designed to be played over and over. That means that it’s OK for players to come away from their first game having barely scratched the surface of the mechanical and tactical depth the game has to offer - in fact, it’s desirable. At a megagame, however, players will almost always be playing that game for the first time, and most are unlikely to play it again. It’s OK for the first turn of the game to be a “learning turn” - in fact, ideally, you should structure mechanics and narrative so mistakes on the first turn aren’t too costly - but after that, 90% of players should have fully grasped the mechanics and their implications.
Ironically, this sometimes means having more options available than in a board game. Board game design tends to be about having as few rules as possible, and finding perfect, elegant rules that lead to a deep and interesting possibility space - an extreme example of this being Go, a game with only six rules that takes years to master. By reducing the number of options down - in the case of Go, to only a single type of move - the tactical nuance of the game massively increases, but the accessibility to newer players decreases.
You can think of this as the difference between text and subtext. To an experienced player, it’s clear that this sequence of moves projects power here, and this other sequence shores up defences here - to a new player, it’s a random pattern of black and white stones. In board game design, this kind of subtext is good (up to a point, at least) - you want there to be hidden patterns that gradually emerge over multiple games; you want players to keep coming back to do better next time. In a megagame, subtext - especially mechanical subtext - is generally bad.
Why is that? If the mechanics are simple and easily “solved”, where does player engagement come from? Ideally, from interactions with other players, and the narrative that emerges from these interactions. In this sense, megagames are far more like tabletop roleplay games than board games. Mechanical mastery is definitely satisfying, but it’s not the heart of the game - and while players are definitely trying to “win”, in some sense, the criteria for victory are a lot more nebulous and tend to morph as the game progresses.
Thus, the job of megagame mechanics is very different from the job of board game mechanics. In a board game, the mechanics are the challenge, and victory comes from understanding and using those mechanics better than the other players. In a megagame, the mechanics exist to define the framework for the narrative, and victory comes from engaging with other players and building support, or talking down opposition, for your goals. The mechanics exist mostly to give context and weight to the negotiations and agreements you make.
For example - let’s say we’re designing a megagame about supervillains. Now, since it’s a megagame, negotiations and interactions between the players are the heart of the game. In this case, the key negotiations will probably be around who gets access to what resources, teaming up to take out those pesky superheroes, and who gets to rule what bits of the world once your evil schemes are inevitably successful.
So, obviously you need to have some game elements representing secret lairs, and what happens when one of your…ahem…colleagues sends their agents to try and loot yours. At one extreme, this could turn into a full-blown dungeon crawler, with carefully positioned traps and guards, and a research tree for unlocking new security measures and countermeasures; at the other extreme, it could be resolved “narratively” - have the defender describe how they’ve set their base up, the invader describe how they approach the incursion, and an umpire narrate the outcome.
Both of those sound great fun, but neither is particularly conducive to a megagame. The dungeon crawler would take far too long to resolve, balancing it across thirty-plus players would be near-impossible, and critically, the players who understood how it worked first and most thoroughly would have an unassailable advantage by turn three or four. Conversely, the purely description-based approach puts players at the whim of how well their ideas have been understood by the umpire, and makes it hard to make quantifiable progress.
So what would be a good way to implement this sort of action? Well, remember that we want players to be interacting and negotiating as much as possible - so having one player set up a static defence and another try to break into it is not much good. Instead, we could consider having “intel” tokens or cards - an enemy has to collect a certain amount of intel on you before they can attempt a break-in, and the more they have, the more likely they are to be successful.
This immediately opens up all sorts of intriguing opportunities - once I have intel on another player, do I just break into their base, try to sell it to the highest bidder, or try and shake them down for protection money? If several of us have a bit of intel each on one other player, can we reach a deal to combine our intel together and do one big raid? It also naturally links back into other areas of the game - maybe certain villainous actions force you to drop intel in certain places, maybe collaborating with another player automatically gives them intel on you, and so forth.
The resolution of a break-in can then be super simple - the invading player decides how much intel they’re spending, maybe adds a bonus for the gear their strike team is using, subtracts a penalty for the level of the base defences, and gets to steal items from your base or sabotage a number of projects equal to the resulting number - or one of any number of other actions, depending on what other concepts exist within the game for us to hook into. There’s no need for mechanical complexity here, because we’ve created the complexity in the area we really want it - the interactions between the players. If anything, by keeping to a single resource - the intel cards or tokens - and a simple resolution mechanic, we enable richer negotiations between players, because the value of that resource is relatively easy to grok.
Of course, that may not be the best mechanic for the particular game we’re designing. Maybe it doesn’t need a base invasion mechanic at all - maybe we want the players to focus on tracking their reputation with different law enforcement organisations, on hiring the best scientists and engineers, or on fighting the insidious influence of the mole-men. The areas we choose to give mechanical depth to will tell the players where to focus their attention.
At least, up to a point - we do have to give players ways to do the sorts of things the setting pushes them towards. If we try to build a pirate game without buried treasure, or a trading game without a way to buy shares in each other’s companies, we can be sure that we’ll just end up having to make a series of hurried rulings on the day as to how that works. This is where playtesting is our friend - getting a group of experienced megagamers to try out our game, and seeing what off-book actions they keep asking to take, is the best way to find out what mechanics we should have built - and conversely, if there’s an action none of them want to take, we should consider making it more relevant - or possibly just removing it.
So there we go. Designing good megagame mechanics isn’t a solved problem, by any means - but we have a very decent shot at it if we remember that:
Our primary design goal is to get players interacting with each other, so our mechanics should serve that wherever possible.
The mechanics that do exist should align with players’ goals - both short-term and long-term - and give substance to their attempts to pursue those goals.
Mechanical complexity generally detracts from the megagame experience. Our mechanics should give the players certainty about what a good outcome, and a good board state, are - the uncertainty they feel shouldn’t be about what’s mechanically optimal, but about the other players’ promises and motives.
With that framework in mind - go forth and steal, by all means! Mine the rich vein of pre-existing mechanics - provided you know how the mechanics you’re stealing serve the design of your game.
What do you think? Did Ed hit the mark or has he got it totally wrong? Let us know on our Facebook group.
Would you like to see your words about megagames appear here on our blog? Let us know and we could be publishing your post next!