P2 – Quest for Compound X

Project 2: Quest for Compound X

Team: Sebastian James, Joseph Ngo, Kaitlin Peng, Dylan Ly 

 

Artist’s Statement

During our first meeting as a team it felt as if we all immediately clicked on the vision we had for our P2 game. Ultimately, we all wanted to create a game that could invoke real feeling from our player. Our initial brainstorms eventually converged to the path that we chose – to create a suspenseful, narrative rich game that would have our players wanting to play the game to its completion. And so, we crafted a detailed, emotionally evoking story about an average civilian simply trying to save his family but also the world in the process. We wanted the challenges in our game to not explicitly feel like puzzles but rather experiences that could “realistically” be part of this adventure to find a cure for an infectious disease that has riddled the world. 

We saw Minecraft as a great medium by which to express the story and challenges we wanted. There was enough infrastructure in Minecraft to execute what we wanted but also enough customization and flexibility that allowed us to make the game feel like its own entity. While the visuals are minecraft based, we customized our world enough where it felt as if it were its own game. Whether someone knew or didn’t know what Minecraft was, we made sure that when they loaded into our game, it was an experience that was unique and cohesive. With this in mind, we paid a lot of attention to crafting our narrative in the game and having it seamlessly integrate with the challenges.

 

Our Narrative

The narrative aspect of our game was something we took priority in as a team and so we thought it would be important to briefly describe our overarching narrative for context. 

As the main character you are as average as an average civilian can be until your life gets turned around the moment you see zombies attack your villager parents and turn them into zombies. As you are escaping the horrific scene, you escape to the nearby dock where you see a man offering you sanctuary on his boat. While you are boarding this boat, the man is fending off zombies on the doc and gets killed in the process. In a matter of hours your entire life has changed. 

While on this boat you get a chance to explore and discover that the owner of the boat and the man that saved you was named Magnus, the lead scientist at Zora Pharmaceuticals. This company released a rabies vaccine that was not ready and instead of curing the disease, it made it highly infectious and worse. As you are continuing to read Magnus’ journals, you find a book that details a trip he was going to take to find the cure to the infectious disease that has overrun the world. Hearing that you can save your family, you decide to take Magnus’ quest on. 

The first trip in this journey is to an island that possesses a much needed ingredient for the cure. However, upon arriving at the island you find that the chest in which the ingredient occurs requires a puzzle to be opened. This is where you solve clues in order to find the first ingredient. 

The second stop in the journey is in an abandoned city but in order to access the building you need to go to and avoid zombies, you have to complete a parkour style puzzle along the outside of the building. 

With these two items in your possession, you are able to return home with cure and save your zombie parents.

 

Concept Map

Initial Decisions

We initially wanted to take the framework of an escape room and adapt it to this digital version and make it form our narrative. At its core, this is a game about solving a series of puzzles in order to find a key that allows you to escape the room. In our narrative, these puzzles grant the player a potion that allows them to cure their family and the population, thus ending the game. With this basic escape room premise in mind, we came up with the following initial decisions:

  • Players: 1 – this is a solo op because we felt that it would lead the player to fully immerse themselves in the gameplay and narrative. Eventually there can be a co-op style play with the brother as one character and the sister as the other. 
  • Objectives: Solve puzzles left behind by the scientist to make the cure to save your family and the world.
  • Outcomes: Non-zero sum – the player wins at no cost of anyone else
  • Resources: Must find resources for cure via puzzles.
  • Boundaries: Boundaries are hard set into the game. The narrative box has hard blocks the player can not destroy and cannot move. The yacht has a boundary around it so that the player can not go off the boat. 
  • Types of fun: challenge, fantasy 
    • Mechanic of needing to complete certain levels before others → dynamic of making multiple attempts and puzzles and challenges → aesthetic of a challenge as the user needs to come over a series of obstacle/challenges/puzzles in order to win 
    • Mechanic of forcing a user to experience a back scene → dynamic of them becoming invested in why they are completing the challenges that they are → aesthetic of fantasy as we try to make this made up world feel as “real” as possible to the player so that they are invested in completing the game.

 

Testing and Iteration History

Playtesters: 5 total

Playtester general descriptions: We tried getting a variety of players. We had someone who never played Minecraft before and also someone that is an avid player. We the others fell into a range in between these two extremes.

Iteration/ Playtest 1

Our first iteration of the game involved building out the foundation of the world for our player. Central to this was our yacht that would act as a central base for our player. From this boat, we wanted the player to be able to transport themselves to the other challenges. We also meant for it to act as a place for our player to get a grasp of the game mechanics (what is interactable, how to move and explore, what elements are core elements and which are not). And so our overarching question for this first round of playtesting involved the difficulty curve of learning how to navigate our Minecraft world. 

We conducted 2 playtests during this iteration – one person who has never played Minecraft (but understands digital gaming mechanics like moving forward, backward etc) and an experienced Minecraft player. We felt that testing with both types of users would give us good insight on extreme user cases. 

For the person who has never played Minecraft, we came across some interesting findings. The first was that the boat we had felt “overwhelming” to be dropped right into. It was a substantially large boat with the only real boundaries being the edges of the boat. This meant that this player was free to explore every corridor and room on this boat. This felt overwhelming to this player especially since there was little in game instruction on what to interact with or do in order to access the first challenge. A positive from this playtest however, was the ability to explore the boat gave this user a safe space to explore game mechanics. Through opening doors, walking up and down stairs, and switching levers, the player began to understand how to navigate our world. 

For the player that was experienced in Minecraft we found other interesting findings. This player spent less time exploring the boat since they had an understanding of what might not be important (for example they knew not to interact with beds or plants that were decorative). We had this player experience one aspect of our first puzzles – the mobs of zombies. This player spent some time fighting the hoards of zombies that we set to spawn but they made the comment that even for them, who has played the game before, the mob spawns were slightly difficult. This was good insight on finding some way to make the difficulty curve less steep initially. 

Overall, our findings from this first iteration were that the boat exploration was useful for the narrative and learning curve but needed more explicit purpose, our mob spawning idea was well received but needed to be easier and more relevant to the story, and some explicit visual experience that explained the narrative before the user even gets to interact with anything would better frame the game.

Iteration/ Playtest 2

We took feedback from the first playtest and created this second iteration of our game. This version involved adding more experiences to the boat to make it more relevant – such as the journals in the library that give clues that help with the first puzzle. We also completed the entire first puzzle to its completion and added an intro narrative experience that would better frame the world the player is in. With this round of playtesting, we had a series of questions including if boat exploration now had a sense of purpose, if the intro narrative was an immersive enough experience to get the player invested in the story, and the difficulty of the first puzzle (does one need too much Minecraft knowledge to complete this task?). At a high level, we wanted to test if the individual elements of our game (boat, island, journals, puzzle, backstory, etc)  started to have the feeling of a single through line. 

One thing we discovered during this playtest was that the clues added onto the boat satisfied many of the issues we came across in the first playtest. Now, the player was unknowingly getting a sense of game mechanics by finding and discovering clues on the boat. We took inspiration from the Plants vs Zombies onboarding with the hopes of making the “tutorial” not feel like a tutorial. Our player was able to understand how journals and directions worked from exploring the boat and this skill would become useful in the first puzzle. 

The narrative experience we developed in this iteration happened before the user gets to play the game. This involves the backstory of what is happening in the world and its goal is to get players emotionally invested in completing this game before it even begins. We initially showed this player a screen recording of scenes we set up and enacted. While the player was paying attention to the backstory video, they commented that it was not that immersive or engaging of an experience for a couple reasons. For one the video was played and then the player was tasked with loading into the game so the experience felt disconnected. The player also described that while the scenes were interesting, having it be a video was simply not as engaging – they wondered if there was a skip the story option as it exists in other games with cutscenes. This led us to think about how to make the narrative experience in game more engaging. 

One of the more important findings from this round of testing was the insight into the first puzzle. We created a chest that could be unlocked only via number password. This password can be found by exploring the ship in the beginning of the game. While this player had an idea of what the password could be, they got stuck on the mechanics of how to input it. In order to get this password encrypted effect in Minecraft, the player needed a certain level of in-game XP and an understanding of how writing in journals/ on paper worked. Without this knowledge the player could not unlock the chest despite knowing the password. The challenge in our puzzle involved exploration and unfortunately we found that the challenge came from not understanding Minecraft’s mechanics. We solved this by making the puzzle a number lock still related to clues on the ship. The number lock unlocks by pressing certain buttons on screen and this seems to be an easier, more intuitive way to still achieve the same affect. The user no longer needs to know how to write something in a book in order to unlock the chest. 

This iteration gave us great insight on how we should continue to add in game elements that progressively teach game mechanics so that the player is readily equipped to tackle the puzzles. The boat changes were a success and so we decided to lean into creating more elements that allowed a user to not only play the game but learn whilst doing so. 

Iteration / Playtest 3

For this iteration, we decided change the narrative intro scene to the story. The player is now suspended in a glass box and now can experience the story in game. The only thing the user can do while in this box is interact with a switch that would teleport them to the next scene. Adding this element will not only make the narrative more immersive since it is in game, but allows the player to go through a “tutorial” of game mechanics. The switch to teleport queues users into the idea that signs that look like the one in the box are navigable and so when they come across them in the game, they have a sense of what to do. With this, we had the question if the scene was immersive enough and if the in game mechanic helped in the rest of the game. We also added more direction to puzzle one about how to physically enter the password to unlock the chest. This would hopefully takeaway challenges that arose from understanding Minecraft so that the player could focus on completing the challenge we designed. We had the question whether the direction we included was enough to guide users into how to enter the password. We also built out the initial version of the second parkour puzzle. The question for this element was testing the difficulty of the designed puzzle. 

We found that the changed narrative aspect was a success. This solved the problem of narrative engagement along with teaching game mechanics. We also added an element that connected the backstory to the yacht. As the narrative ends, the user must for the first time, run and jump in order to get onto the safety of the yacht. By the time the player is on the yacht, they are well equipped with the moving mechanics they need to explore. At this stage, we started thinking about elements like sound to further immerse the player into the narrative happening. 

For the changes made to the first puzzle, they were well received. Since it was difficult for people with no Minecraft knowledge to figure out the first puzzle, we changed the puzzle to be a button combo puzzle that opens the door to an unlocked chest containing the ingredient instead.  This helped solve many of the problems found from playtest 2. We actually found that we could add more clues on where to find the answer to the combo puzzle  since this player in particular had trouble looking through barrels to find it. 

We then tested the difficulty of the second parkour puzzle. Feedback on the visuals was great – the player enjoyed how immersive and vast the abandoned city was. They mentioned how it played well with the narrative. When trying out the parkour however, there were moments when a sprint was necessary to make a certain jump and we had assumed that the user knew how to do that. However, we found that the sprint mechanic was not something that this playtester knew about. This was great to know and we plan on implementing this similar to our other features. We will add some hint to users that teaches them to sprint earlier on in the game when it is a safe environment. For example, at the beginning of the game when the user must run onto the boat, we can have them sprint on to show that this is an available mechanic.

 

Video of Final Playtest

Final Prototype / Demonstration of Experience

Play Through 

Game Shape

 

Link to Play the Game!

https://github.com/sebaxj/cs247g

 

About the author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.