P1 Meltdown

Artist’s Statement

Our initial inspiration was Keep Talking and Nobody Explodes, a game I enjoyed due to the mayhem of confusing descriptions and instructions. My least favorite part of it, however, was how asymmetrical the experience is: the two players have completely different roles, and only one gets to interact with an electronic system, while the other flips through an intentionally complicated book. I wanted to take the confusing aspect of the game and use the commonality of mobile phones to make a game with similar elements of difficulty, but with every player sharing both the controls and the instructions. This eliminates the need to determine distinct roles for each player before starting the game and creates a more symmetrically engaging experience.

Our initial plan was a digital, social, 2-4 player asymmetric game, in which one player has the instructions and needs to communicate them to another player(s), who have the controls, to keep a nuclear reactor from melting down, very much inspired by games like Keep Talking And Nobody Explodes or Jackbox’s Bomb Corp. Our goal was to create frantic, fast paced, high pressure situations through this asymmetric flow of information and a time crunch.

This game has a social aspect, as players have to rely on each other to make progress. Players have shared lives and shared consequences for mistakes. Communication, misunderstanding, and strategizing together creates bonds in anyone. There is also an important element of challenge, with puzzles and time pressure, which creates a feeling of accomplishment when players succeed. Lastly, there is an aspect of sense-pleasure, in the ability to control switches and the instant feedback from a digital platform. Ideally, the player would receive very tactile and audible feedback from pushing buttons, and the music would increase in intensity as they run out of time or as the player makes mistakes. 

This style of game would be well suited for a group of people who aren’t hardcore gamers to find a challenge to tackle together. It would work really well in environments where players are trying to get closer together, like a student group retreat. The collective challenge that players can only conquer through collaboration is sure to make players feel accomplished as a group.

Concept Map / System Diagram

https://www.figma.com/design/EJFZPzkPAer4MiSqBGU8Om/meltdown?node-id=0-1&p=f&t=EcFxgqvTzhlIO0ws-0

 

Initial Decisions:

Our initial design was to have one player with a set of instructions, and another player(s) with a set of levers and buttons that had to be pressed in a particular order. Our mechanics involved toggle levers and buttons, a time limit, shared score across players, increasingly complicated instructions, and an asymmetrical information and control scheme. We built around the values of creating urgency, demanding collaboration, and testing trust under pressure. It was important to us that success should require communication under time pressure. As stated, this creates social fun, challenge fun, and sensory fun. 

 

👥 Players

• 2 players
• Each on a separate phone, connected via Bluetooth
• Each player has 4 controls: randomized mix of buttons and levers, each with a unique color

 

📲 Device Layout

Each device displays:

• 4 controls (e.g., Red Lever, Turquoise Button)

Current reactor status (temperature, stability, etc.)

🎯 Objective

Prevent a nuclear reactor meltdown by coordinating input actions across two player devices, each with a randomized control panel of buttons and levers.

 

🕹️ Controls

• Buttons: Can be pressed (momentary); have a “recently pressed” state for ~10 seconds
• Levers: Can be up or down (binary toggle)
• Wires
• Dials

🎮 Instructions

• • The informer can see the current reactor status (temperature, oxygen levels, humidity, etc.)

• The operator(s) can see several levers, buttons, and wires

• When the game begins, the informer will see a prompt alerting them of a system emergency. They have to communicate to the operators and coordinate to respond to the emergency
• As the game progresses, the informer will receive more alerts of different emergencies, and they will have to balance their priorities and communicate effectively to lead their operators to safety
• The players gain more points the longer they hold off the meltdown

 Testing and Iteration History

 

Pre-playtesting:

We quickly realized during in-group testing that having only one player with the instructions and one player with the controls was too simple, causing players to feel disengaged because they weren’t being pushed to strategize or communicate more effectively. Therefore, in our next design, we drafted a handful of more difficult minigames which challenged the players’ communication and coordination more. We arrived at two minigames with a similar idea: each player only had partial control and partial information. In one minigame, players have access to half the control panel and half the rules, and must reach a particular state without violating the rules. In the second minigame, players have to work together to get through a maze, but each player can only view half the walls.

Therefore, for our next two playtests, we tried these two minigames in a low-resolution paper prototype and player-enforced rules.

 

Playtest 1 (in class): 

 

During the first playtest of our game, we got 2 players to play Meltdown. They ended up completing three tasks with the 3rd task needing to be restarted since one of the players got locked out due to an accidental rule violation. In the beginning, the players seemed a bit confused with the rules of the game. At the end of the three tasks, we asked the players some follow up questions.

The first question we asked was when the players were most confused. One of them responded saying that in the beginning, they weren’t aware of all the controls that could be done until playing the game. The other player said that he experience a “fun confusion” since he liked figuring out what needs to get done to move forward to the next task.

The next question that was asked was “what parts did you find most challenging?”. Both commented on the last challenge being the most difficult, especially considering the fact that they had to restart due to accidentally breaking the rules. Because of this, we decided to implement an error message popup for when the user tries to break a rule to prevent this from happening during gameplay.

We also asked the players about when the game started to “click” or make sense. Both players commented that once they started the first task, they begun to understand how the game works.

Next, we asked the players if they feel like they built a strategy as they continued to play the game. One of the players commented that they didn’t think of a strategy and was just thinking of the end goal while the other commented that he had a strategy of trying to figure out what the other players’ rules were.

Lastly, we asked what they would do differently if they were the gamemakers. One of the players suggested that one minute for each task might be too short. Overall, both players agreed to have enjoyed the game and found it fun!

 

Takeaways:

• Player enforce rules don’t work well. Having a digital version allows us to have more complicated rules and interactions while leaving the player’s working memory for strategy and coordination

 

Playtest 2 (in class):

 

In this playtest, guest UI was included; however, it was currently broken. During this playtest, one of the main things that came up was issues with communication. Due to the fact there was a language barrier, it made it hard for the players to describe the walls to each other in terms of navigating the maze tasks. Because of this, the players had to figure out a strategy of communication such as asking questions like “Which two squares is the wall between?” which helped to communicate which wall in the maze was most difficult to get around. Doing this made it easier for the players to plan their next moves. Some feedback that was received was that the game would’ve worked better if the guest screen was functioning and that the instructions needed more conditions because it felt too easy. They also provided us with suggestion of adding XOR level ownership, more ulterior motives, and minigame punishment for mistakes that were made.

 

Takeaways:

• Provide a framework for the players to communicate with by labeling the mazes with coordinates

 

Playtest 3:

 

With this playtest, there were some mixed feelings that came from the players of this game. The players were not the biggest fans of the level/slider challenges and didn’t seem super invested in these challenges. They also found the rules to be a bit confusing to understand just like the players from our first playtest. However, the players commented that they liked the mazes and especially the toughest maze due to the fact that there was more strategy and backtracking involved. After playing the maze rounds, the players wished for a longer challenge of a maze due to how enjoyable they found it to do the maze tasks.

 

Changes Made Post-Playtests:

 

As a result of these playests, we decided to make multiple changes to our game Meltdown. Based on the critique given from the second playtest, we fixed the Guest UI bug making it now a functional part of the game. We also created instructions that update on completion and added a global score and lives system to keep the game interesting. In the future, some ideas that would be good to implement is the ability to sabotage roles and the option to engage in private mini-challenges.

 

Final Playtest:

https://drive.google.com/file/d/1dFTbtA6sAdWSxz1J21gz6cwW41FkohbC/view?usp=drive_link 

In our final playtest, we had 4 players join the digital version. We attempted to have more players, but they couldn’t see any of the controls due to technical issues. For the players who were in the game, they expressed some confusion over 1. Who the rules applied to and 2. When they had successfully completed tasks.

There was definitely an aspect of social fun, as players raised their voices, tried to ask each other what they saw, and offered suggestions for how to solve the task. 

 

Takeaways:

• We need to more clearly introduce the game, perhaps with a how to play menu, since seeing only a fraction of the control panel isn’t self-explanatory.
• We need more clear feedback for when players have succeeded a task or flipped a lever, perhaps through audio or a screen flash

 

Future Versions:

In future versions, we’d like to implement more minigames with different mechanics and have the instructions increase in difficulty over time. We’d also like to add a countdown to put the players under pressure to complete as many tasks as possible in the allotted time.

Of course, we would also want to iron out any bugs so that joining the game is consistent and it supports up to 8 or even 16 players.

 

 Link to Final Prototype

This QR code links to the game, using expo go

 

* Download game repo from here: https://github.com/AlexJYRed/meltdown-rn

 

How to Start/Join

 

*Make sure that you have downloaded Expo Go on your phone before following any of the below steps

 

1. Start the server!
   1. Open terminal
   2. Run “cd backend”
   3. Run “node server.js”
2. Start frontend!
   1. Open new terminal window
   2. Run “cd frontend”
   3. Run “ ./mac_setup.sh or ./windows_setup.sh” based on your operating system
   4. Run “npm install”
   5. Run “npx expo start”
3. All phones that want to interact with this game should scan the QR Code that comes up
4. That is all! Enjoy Meltdown!

 

Rules

You have a limited amount of time before a nuclear meltdown, and you’ll only be able to solve the emergency by fixing the control panels. A game master (GM) will present tasks to you and facilitate your game. Your goal is to complete all tasks before time is up. Here are the rules of our prototype:

1. Each player will be presented with their own board that has interactive controls on it.
2. You may not look at the other player’s board.
3. Wrong solutions might break your control panel even more.

(in the future, in our final version) Each player’s control panel consists of:

• Switches: flips the card to switch sides.
• Buttons: press a button to play its corresponding sound.
• Dial: one board shows dangerous ‘red zones’ along a slider, and the other board contains a dial and blank slider.
• Maze: one board shows an incomplete maze with only the horizontal lines, and the other board shows the vertical lines.