Lessons learned from mistakes made (Part 1)
The second part of this article is available here.
Shaun D. McMillan created ALLIANCE the Ultimate World Leader Political Science Megagame together with this high school game design students in 2014. He and other facilitators have run the game multiple times in Texas, Wisconsin, New York, Canada, and in multiple languages in Taiwan, Singapore, Malaysia, and South Korea. He also Kickstarted Great Boy the Game and has self-published a card game called Conspiracy, but finds the poor player count of prototypical card games pathetic compared to megagames. You can find his games at MyMegaGame.com.
Players at Gen Con 50 playing the 2nd Edition of ALLIANCE Last Days (Photo supplied)
More is not always better
Before I was operating under the principle that a megagame was like a sandbox or a buffet. I thought that we should have as many minigames, crises, seeded ideas, rumours, and mechanics as possible in the game so that players don’t feel that the game is too simple, too boring, or too easy to figure out. This is problematic for many reasons. There are some serious issues to address with introducing players into a megagame and an excess of systems and mechanics only exacerbates those issues.
We had too many Scientists to all stand at the same table at the same time so I created an entirely different second tech tree with its own set of cards, only one of which gave access to certain Victory Points (oops!). The new tech tree was more thematic and played into the other mini-games, but it would have been easier to just let two sets of scientists play the first tech tree by doubling the number of tech cards. Players appreciated the effort, but they couldn’t trade with half the scientists, and half couldn’t get those precious VP.
I take joy in designing mechanics, content, and seeding the game with rumours. I also like allowing for multiple different end-games to emerge as the end of the game should ultimately be the most satisfying and epic aspect of the game. But as I put more and more into each game and simultaneously try to shorten the game both to reduce the time commitment and to keep up the pace of the game, I’m finding that players can hardly explore the depths of the themes they are engaging with. Players are smart and sophisticated, so if they are provided with enough intellectual ammunition they will discuss, argue, and explore all the emotional depths of role-play if given the time. Therefore, mechanics should be easily and quickly explained, easy and fast to adjudicate, but imply thematically rich and intellectually deep ideological conflicts.
If those fighting off the epidemics neglect certain cities, the resulting outbreak meant that the Secretary of Defense of that particular nation now has to defend his capital from the Zombie hordes.
This doesn’t mean megagame mechanics have to be shallow, but they don’t need to be nearly as deep or sophisticated as board games and card games designed for less than ten players. I challenged this idea with my last game and found that the players, though intrigued by the elaborate mini-games, would really rather be interacting politically with all of the other players, not with the complications and challenges presented by the mechanical systems of the game’s components. I’ll continue to innovate and experiment with these ideas even if I didn’t get a great response the first time I tried this approach, but first I want to revisit the core mechanics and make sure they welcome all of the players into their relationship with each other and the game’s themes.
In ALLIANCE Last Days I brought two turn-based games into the megagame for certain roles to play during the first half of each game day. Some had to play a modified version of Pandemic, and others had to play a card game I designed called, “Conspiracy.” Each had serious consequences for other teams/roles in the game making it very intriguing but also very complicated.
When it comes to systems and mechanics, we should operate by some of the principles identified by Nicholas Proctor in his book, “Reacting to the Past Game Designer’s Handbook.” Reacting to the Past or RTTP is a historical simulation system designed for students to roleplay and debate conflicting intellectual ideas in the classroom. The RTTP curriculum might not exactly be a megagame but it is similar enough for our interests and has been implemented by faculty at hundreds of colleges and universities in the U.S. and abroad since dissemination began in 2001.
Just to show you how crazy I am, this was yet another minigame called Ground Zero I developed as a standalone expansion for Last Days. Luckily, I didn’t finish it in time and left it out. Did I mention how much I love developing too many mechanical systems and components?
Ensure understanding of the primary mechanism in the beginning of the game
The rules and results of the primary mechanism must be absolutely transparent. Players must know how to interact with it. They must be given immediate feedback. Use something familiar like voting, trading, or purchasing upgrades, so they can engage it early and often.
Players come into the game with a lot of anxiety. They are anxious because at least a third of them didn’t read the rules at all, about a third of them understood the rules only vaguely after listening to the explanation at the beginning of the event, about a third of them read the rules and listened to the explanation but still don’t fully understand what will emerge from these systems and what it is they should make priority, and some of them won’t understand until they actually engage with the mechanics and see the results.
Players have other reasons to be anxious as well.
● Active participation
Players must be active participants even though they lack high levels of expertise.
● Accountability
If players do not familiarise themselves with the game materials they risk public shaming. Will they be able to uphold the responsibilities given to them by their role briefing?
● Peer Interaction
Will they be able to get other players on board with their agenda?
● Time Pressure
With so many people to talk to, a team to report back to, and actions available to them, what should they make priority. What is critical for me to do right now?
Players will naturally chat with each other at the beginning of the game which is good because they are now engaging with the strangers, they entered the game with. But until they understand how they relate with the primary system of mechanics they won’t really understand how they relate to other players within the game space. We must make it very clear what is at stake for each player, and we have to show them early on that their choices really matter by providing immediate feedback after they take their first initial actions. This creates a strong feeling of agency that will get them excited about their role in the game instead of making them feel lost or powerless to affect change within the game. If their roles are asymmetric then they could become resentful if they feel that another player has a far more important role to play than they do. They should feel that fulfilling the responsibilities of their role is critical to their team and to the game itself.
Secondary mechanical systems can be introduced more subtlety
The Primary mechanism by itself is not enough to build a dynamic simulation or interesting game. We need secondary mechanical systems to surprise the players and allow for complications to emerge. These are the mechanics that can be introduced later on in the game and only initially to a certain handful of roles, or even perhaps only late in the game. But once these secondary mechanics exert a major influence on the primary system, their functioning must become clear to everyone.
While players may possess incomplete understanding of the secondary systems, make sure the GM (Game Master) can easily understand them all by describing their function, timing, and reason for existing in the Instructor Manual. It is a good idea to map out all of the systems visually using some type of flow chart to show how each system interacts with the others in one big illustration. This will help the GM not to be overwhelmed by all of the rules if they are not the designer. This is also helpful for Control Player Referees because they can often be more helpful if they know which other systems their choices will directly or indirectly affect, and which Control Players they should check in with about changing rules, increasing or reducing rewards, identifying missing components, or who to ask questions.
Feedback loops
It is important that any information, available action, or effect introduced by a card pays off. Like Chekhov’s gun, if you introduce a gun at the beginning of a film, someone should get shot by the end. The problem is that actions often involve both the engagement of multiple players and adjudication by a control player.
The results of player actions should not be concealed or so subtle that they cannot be easily detected. If players cannot see this relationship, the game begins to seem arbitrary and/or remote and players lose interest.
Players need to understand what is happening, why it is happening, and what it has to do with them. If they can then they will continue to engage with the mechanism and the other players.
I put in a lot of effort to give players lots of information, mechanics, and relationships with other players. But by using similar components to do all three it was not clear to players whether what I was giving them was a thematic elements with no real mechanic which we often refer to as fluff, or whether I was providing them with a mechanic that affected other players, and it was unclear when or how they should expect engagement with these mechanics to pay off. Would they even see the results of their decisions?
This problem was made worse by the fact that some players did not show up to fulfill their roles. Was a mechanic not paying off because the other players it affects were not in the game?
I worked really hard to make every role in the game critical so that every player would feel that their role mattered. But when players did not show up, and other players on the waiting list did show up, I did not have enough time or manpower to figure out quickly enough which roles were missing and which could be replaced.
While facilitators can hardly be blamed for players not showing up, designers know this is a common problem for megagames so we must design for it. I don’t have a clear solution for solving this problem, but we can at least abstractly identify a principle by which to find a solution which I will call, “redundancy.”
Check out Part 2 of Shaun’s blog where he discusses what players want to know vs what they need to know, amongst other points here.
If you’d like to discuss the items raised by Shaun, head over to our Facebook group now and catch up with the discussion there, or if you’re the first one, tell us what you think!