Quantum
Maze
A multiplayer digital card game inspired by the film Coherence (2013), designed and coded in a team of four
Overview
Concept Explored & Objectives
The task was to design a multi-player interactive story-based board game that allows players to experience the story by becoming characters from the film Coherence (2013), which explored non-linear storytelling.
Objectives of the Task
The purpose of the task was to explore coding while building a game involving non-linear storytelling, and be able to narrate parts of the film to the players in the course of the game.
The game needed to explore the storyline of the film and enable players to immerse themselves in the plot.
Timeline
The total 5 week duration of the course was split into 3 intensive parts.
-
Week 1 & 2: Conceptualize the entire gameplay of the board game, test it out with players and a physical prototype, and shoot a video explaining the gameplay
-
Week 3 & 4: Draw out an exhaustive flowchart mapping every possible outcome of the game, and code using Python select parts of the game
-
Week 5: Finish coding the entire game, add visuals if required, and shoot a final gameplay video of the digital game
Index
-
Developing the Gameplay
-
Exhaustive Flowchart of Gameplay
-
Coding the Game: Phase 1
-
Coding the Game: Phase 2
-
Conclusion & Reflections
Index
Click on any of the topics to go directly to the relevant section
Developing the Gameplay
Understanding Non-Linear Storytelling
A brief summary of the film: Coherence is a strange story of eight friends who meet for dinner on the night the Miller's Comet is passing over Earth, and its passing results in a tear in their reality. They are unaware of any such occurrence, and unknowingly walk through the tear, ending up in a different version of reality than they were in before. These versions of reality possess the same characters, but the events surrounding them are relatively different, leaving each one suspicious and unsure of the other's true reality, and having to use personal belongings and other objects to subtly identify realities. The film ends with the tear closing up when the Miller's Comet has completely passed, but two different versions of the same person are stuck in one reality.
Challenges
Conceptualizing the gameplay was a challenging task, as the film itself was quite confusing for us to understand. We needed to incorporate the same form of non-linear narrative into the game, but without potentially confusing and frustrating the players.
We explored several possible outcomes of how the game could progress, the rules, in what circumstances it could be won, and how best to incorporate the tricky back and forth of the story's twisted timeline.
Brainstorming on Gameplay
Navigate using arrows to view all the images
Key Aspects of the Game
Game Concept
Quantum Maze is a strategy survival game inspired by the film Coherence. A tear in the fabric of reality leaves you and three of your friends stuck in a maze of alternate timelines where each of you must try to find your way out. Trade items and use your actions wisely as you and the other players race to collect all the necessary items needed to escape. Only one of you can make it back to your reality of choice by navigating multiple timelines, both good and bad.
We developed the progression of the game with the use of Trade Cards and Action Cards. Trade Cards are segmented into five distinct categories of:
-
Event: This is an event that has occurred only in one of the realities, which means each character will recognize only one event from all the five.
-
Behavior: This is an action that one or more of the other characters have done in the course of the night
-
Identifier: This is an ordinary object, that the group of one reality have termed their 'marker' for that particular reality. This means that the reality can be determined by linking the right identifier to it.
-
Sound: A certain sound was heard by the group of one reality in the course of the events.
-
Decoherence: This is the final event that occurred, which made the group realize that something was wrong and their realities had been warped. It is again, different for each reality's group.
Quantum Maze: Explained
Quantum Maze looks into various instances from the film Coherence and combines them into a strategy card game. At the end of the game, only one player can go back to their original reality, away from all the turmoil of the night.
To do so, each player must collect a series of five Trade Cards that contain the events connecting to their original reality. Players can trade cards and use adverse actions against each other to gain the cards that they require. The game uses strategy and encourages conversations and negotiation between players to increase interactivity. On each turn, a player, playing as one of the film characters can pick up two cards and can play a maximum of twice. In this way, they have the opportunity to trade as well as utilize Action Cards in a single turn. As a player collects all their required cards, they can head out in search of their original reality. But will the Quantum Maze allow it? Upon collecting the five required cards, there is still one more hurdle to cross in order to win, which is the Gamebreaker Stage. Here, they must roll a high enough number on the dice to securely reach their reality and win the game.
(Navigate using arrows to view all the images)
Designing the Cards
Setting the Context with Story Cards
Building the Narrative with Trade Cards
Progressing Through the Game with Action Cards
Testing the Gameplay
We tested the game with other groups of people and took note of their involvement in the game, whether they understood the rules, and took their feedback into consideration to finetune the gameplay. The group who played our game had not seen the film Coherence, so it was an advantage for us to see whether the complicated and convoluted storyline made sense to an outsider. We could see some shortfalls in the game when it came to narrating the film’s story to a newcomer, and making sure they completely understand it.
Testing the other teams’ games as well helped us identify different important aspects involved in gameplay, such as strategy, competitiveness, and interaction. We realized how important it was to check and maintain these aspects in our game.
Physical Prototype Gameplay Video
Exhaustive Flowchart of Gameplay
Mapping Every Possible Outcome of the Game
Before beginning to code the game, we had to create a flowchart for every outcome and boundary case for the game from start to finish.
Only when we start making the flowchart, did we realize the possible gaps in the game and then were able to fix it.
This activity was an important step to the whole process of developing a game, as it would have been much more difficult to fix if we suddenly realized while coding that there was some scenario we had not accounted for. This way, it was a simple and systematic approach to coding.
Click on the image to zoom into details
Coding the Game: Phase 1
Coding the Entire Game, Playable on One Device
We began the process by referring to our flowchart, and coding parts accordingly. In this first version, the instructions, as well as each player's cards were displayed on the command line, visible to everyone, and the players would play turn by turn. We decided to figure out the logic of the game completely, and once that was complete, focus on how it can be played simultaneously by multiple players, like a real game.
All player's cards as well as the game instructions displayed in this manner, and the game is played on the command line
Simplicity of Use
Since the first version of the game was completely command line based, we had to account for alternate options of what the player would type. For example, when the player had to type the name of another player they want to trade with, we had to ensure that all variations of the name would be accepted without throwing an error, such as allowing for 'm', 'M', 'mike' and 'Mike'.
In the process of coding, we tried to leave as little as possible work for the player to do (as little as just looking at their card's serial number and typing it in) by making the program more exhaustive.
The code needed to repeat the question to the player in case of a typing mistake, rather than throwing an error and stopping the program
Coding the Effect of Action Cards on Players
When we started programming, we could see how complicated certain Action Cards were to code, and certain boundary scenarios were to predict. It was exhausting how many different conditions and situations we needed to check at each turn, but we were able to see simpler ways of doing it along the way, once bigger chunks of the game were completely coded.
It was also complicated to maintain the effect of a particular Action Card on a player for several rounds. For example, the Unconscious card would render a player unable to trade with anyone for a full round. This would mean that the program should inform the player of an error if they try to type their name in for a trade, or another action. These cases were tricky to code, and each player's status needed to be checked before any trade or action could be performed with them.
For the duration of the effect of Snooze Action Card, the player cannot be allowed to take a turn
Many, Many Functions
The amount of conditions we needed to check for, and situations we needed to account for while building the game was quite overwhelming. Each time we figured out how to code a function, there were several aspects to keep in check for that particular function to work correctly. Once that task was complete, there were even more cases to check for when it was added along with the rest of the functions, and they all needed to interact with each other without throwing any errors.
Coding as a Group
We were a team of four, and this course was an introduction to Python geared towards beginners. However, another team member and I were familiar and comfortable with coding, but the other two team members were not. This created some difficulties in the process, especially since only one person could code at a time. It was a slow and difficult task to navigate at first, but then we were able to divide up the coding tasks among us based on our specific skill sets, while regularly updating and explaining each coded section to each other. Explaining the logic and syntax used in the code to each other helped make our own understanding stronger as well. We also ensured that complicated sections in the code were thoroughly explained in the form of comments, so that each team member could take their time to understand it.
All functions and important sections of the code thoroughly explained in comments
Coding the Game: Phase 2
Converting to a Multi-Player Game
After coding the entire logic of the game in Phase 1, we researched on how we could host a local server with multiple clients, in order to have our final game be simultaneously playable on four different devices where each player has access to their cards on their screen, and can play the game in that manner with the cards being updated by the code on the individual webpages.
Making Each Players Cards Accessible Only To Them
We decided to use QR codes that lead to distinct HTML pages for each separate player, and display their cards and instructions on the webpage itself. We coded the QR codes to come up as soon as the program was run for each player to scan, and the designed images of the cards were shuffled (using the shuffle function on Python) and distributed to the players for them to see on their website.
Trade and Action cards are displayed separately for simplicity, and marked with serial numbers for the player to enter on the computer when they want to play the corresponding card
Code for generating QR codes linking to distinct HTML pages for each player
Updating the HTML Webpage After Every Change
Once the individual webpages were set up, the next task was to ensure that after every change, the respective player's webpage should be updated. This includes Trades, where cards need to be updated for both players, Actions, where the affected player's webpage should not allow them to play a turn until the round is complete, and the Gamebreaker stage too. After every change in the game, the involved players are asked to refresh their screens to see the updated cards.
Images from Gameplay
Final Gameplay Video
Conclusion
Reflections
The process of building this game was quite exhaustive, and required several hours of committed work almost each day. Our team members were a good fit for each other. We worked hard and dedicatedly met throughout the week and all day even on weekends to complete the code. I was familiar with coding even before this course, and so throughout the class, I was able to teach as well as learn with my teammates, which helped deepen my understanding of programming.
In the course of this task, I was able to learn about classes and objects, which was something fairly new to me. I also had the opportunity to understand the concept of servers and clients when we incorporated it in order to make our game playable by multiple devices, and the basics of HTML with Python to build a webpage. We simplified the code wherever we saw possible, and created functions wherever we saw repetitive actions. I gained a deeper understanding of the various elements involved in creating a game, and was also exposed to different approaches to programming as taken by different members of my team.