TOC
- What is this project?
- What is a megagame
- Why is a bot needed
- Use cases that the bot solves
- Future work
What is this project?
This is part of the "student's as partners" program at Carleton University. I'm working on this with Dr. Alan Tsang for one of the courses he teaches, multiagent systems. During the course, a "megagame" is played with all of the students over the span of a week. Our project here focuses on building better tooling that can be used during this event.
What is a megagame?
A megagame is an event where several dozen players take part in a large-scale simulation of role-playing, politics, and strategy. It normally takes several hours to play, and can sometimes span over multiple days. Think of it as a board game, but everything scaled up. It has a lot of similarities to a game like Risk, where all players are focused on moving their pawns around a large map, and making strategic alliances with other places. However, in a megagame, players each have a unique role on a team, and communication between teams is restricted.
For example, a hypothetical megagame version of Monopoly might work as such:
- Each player in a normal Monopoly game might instead be a team made up of several players, each with a different role. These teams might represent real estate companies.
- On each team, there would be a company president, a finance executive, a media role, and several other roles. The other roles might not be used, depending on how many players there are in total.
- These teams are each trying to buy different properties, however only the president on a team can make the deal to buy. The finance role would deal with the cash flow, maybe from property rent, or tenents of the properties. The media might spend time improving the look of the company in the "public's" eye. All of these roles are abstractions, so players might be using action cards to accomplish what they want, or trading resources with other teams.
- A large element of megagames is role-playing. This means that when one of the companies is making a press release about a new property they bought, they might earn extra resources for doing well. This would be decided by the control team, who are the "referees", or "dungeon masters" of the megagame.
An in-person megagame with around 300 players
You can read a much more detailed description of megagames here. Ars Technica also wrote a piece about megagames.
Why is a bot needed
This year's run of "Watch the Skies", the megagame played in Dr. Tsang's class, was done on Discord. Since everything that semester was remote, the game had to be run on a platform that would allow for communication between teams. It also had to restrict who could speak to whom. Discord offers all of these features, with the added bonus of voice channels needed.
The game ran pretty well, however, there was a lot of management work that was put on Dr. Tsang, as he was the only one who managed the game state at all. This included transactions between teams, creating channels when teams needed to talk privately, and battle simulations.
There are a lot of areas that a bot can help with. Not only for ease of running the game but also for locked-in choices. For example, if a team sends money to another team, the bot can make sure that it was properly recorded. Or if the control team (Dr. Tsang) needs to ask teams a question, they can have a time limit, and responses are locked in on sending.
With these items in mind, we looked at several areas where bot functionality could shine:
- Trading and transactions
- Querying players and teams with time-dependent questions
- Player role and permission management
- Text channel manipulation
- Announcements, updates, and state display
For the base of the project, we decided to focus on items related to currency trades and asking players questions.
Why not a website?
An important question to consider is why we aren't making a website for players to use, instead of restricting them to Discord. In essence, everything that the bot does is being exposed to a web view, but only for the control team. This means that the control team can see statistics, like how money is distributed between teams with a pie graph. The control team can also use this dashboard to make changes to the game, like move players to different teams, or send out announcements.
For the player, a website would allow them to potentially have more ways to express what they want to accomplish in a turn. For example, creating a transaction in Discord is currently made up of several steps, all of which have to be done with Discord's new UI elements. This includes emoji interactions, text commands, dropdowns, and buttons. A website would allow for more than just these UI elements.
Discord's new dropdown UI element
There are a few reasons that Discord is a better option to be the primary tool for online megagames:
- It keeps the discussion and the interactions in the same place.
- It can be harder to build a megagame tool that can work for multiple games with a website when you're not restricted to what Discord provides.
- Less information is sometimes better in megagames. A full UI that answers a lot of the questions players might have can reduce the need to interact with others, and this is a key pillar of megagames.
Although this rationale holds up for now, in the future it would be interesting to explore ways that a website could enhance a player's experience. For example, if a map with military pieces is needed, it would be much harder to implement it on a website.
Use cases that the bot solves
Currency trades
A primary mechanic in megagames is the exchange of different currencies. This might be money or credits, but can be a lot more specific, like action cards that are played, or military troops. There are a lot of ways that this might be done as well; these transactions might be done between a player or entire teams, and they can either look like a one-way send or a two-way trade.
These trades also need to be managed in a way that makes sure that they are verified by both parties. They also need to be recorded in a way that can be viewed later if needed. Another important requirement is transaction atomicity. This is important to make sure that if someone tries to make two transactions at the same time with only enough money for one, they don't both go through.
Locked-in choices
Another required task in megagames is collecting player's turn input. It needs to be easily accessible for the control team so that they can do any turn-simulation work that they need to.
There are three ways that this might be done.
- The first is just a standard submission. A team knows what they are capable of doing on their turn, and just needs to lock that in for the control team to see. At the end of a turn, the control team should be able to have access to a list of choices made by all teams.
- The second is a specific question with a specific response. For example, the control team might ask "how many interceptors does each team want to send to intercept?". Each team should be able to respond in a structured way so that calculations can be done automatically. This is particularly helpful during battle simulations
- The third is a unique question posed to a team or player from the control team. These are more likely secret questions that come up because an event occurred, or a player might have a secret role. In this case, the control team still needs an easy way to get a response from one party, not many.
Future work
There are areas that this work can expand into in the future.
Use for larger megagames
Around the world, megagames are often run at much larger scales than what we're hosting at Carleton. Although many of these are in person, many have been transitioning online as of recent. This bot is designed to alleviate some of the difficulties that control teams will have while running online games.
The first version of this bot was designed with Watch the Skies in mind, but the goal is to make it have extensible capabilities, which would allow it to work for other megagames.
Use at Carleton
Over the past few years, many courses in the Computer Science faculty at Carleton have started using Discord for student communication. It's a great tool for keeping students up to date, allowing students to chat, and creating voice discussion rooms.
This bot might have some features that could be useful to professors at Carleton. In terms of server management, giving users permissions is a key requirement. Having a dashboard that allows professors to see all of the students in a table grid, and being able to move them around could save a lot of time.
Future posts
This blog post gave an overview of the purpose this bot will serve. There will be a test run of this bot on August 28th, 2021. After that, the bot will be considered "stable" and have a 1.0 release. The bot will be open-sourced, and development will continue. Another blog post will be written to describe the technical side of this project and show off the bot in action.
Top comments (0)