Fate of the SS Fortuna
A Sci-Fi Mystery-Solving Escape Room
The Fate of the SS Fortuna was a narrative-based sci-fi mystery escape room, where players can feel like detectives investigating a crashed ship to discover the reason behind the crew's mysterious disappearance. The escape room involved both digital and physical interfaces, as well as live communication with the ship's navigation "AI" character. The experience was hosted for one week at Seattle-based Virtual Reality tech start up, PlutoVR.
"You have been hired by the company Starpoint Cosmonautics to investigate a mysterious catastrophe. A small research spaceship called the SS Fortuna has crash landed on Earth, mysteriously empty of its crew. The only remaining crew member is the ship's AI. Its core is badly broken, missing several parts and most of its memory, but it's still on and it very much wants to know what happened to its crew – so much so, that it's not going to let you leave until it finds out! The only things at your disposal are the items left on the ship's bridge and the AI's scrambled memory banks. Can you work together to figure out what happened on this disastrous voyage?"
– Pitch Statement
01
Project Summary
Project Duration: Jan - June 2023 (22 weeks)
The Idea
The Fate of the SS Fortuna was initially conceptualized as a narrative escape room with mixed-reality (VR/AR) elements, and served as me and my team's college capstone project.
We were interested in exploring the possibilities of infusing classic escape room design with digital elements, and experiment as well as a narrative that informs the game's puzzles and world. After extensive research and brainstorming, we settled on a mystery-solving game with physical puzzles, digital puzzles, and an "evidence-presenting" mechanic that utilizes AR.
The Final Product
The final product included the following components:
-
A constructed physical set for the players to play the game in, including sci-fi furniture, pieces of "evidence", fake photos of the characters, and other decoration,
-
An interactive Unity app simulating the spaceship's computer.
-
A network built in TouchDesigner to manage sound, stage cues, remotely triggered electronic locks, and the AR scanning device.
-
9 traditional puzzles (a mix of physical and digital), and 10 mystery questions to answer, all of which could be solved within 1.5-2 hours.
-
A mystery featuring 4 characters, told through dialogue transcripts, journals, and environmental storytelling.
-
An evidence-presenting mechanic that requires the players to present proof of their mystery findings using an AR scanning device.
-
An "AI" character who talks to the players and gives live hints, portrayed by an actor speaking through a vocoder behind the scenes.
-
A backstage studio setup with cameras and mics that allowed the team to listen in and observe the players during playtesting.
Reception
The escape room was hosted for one week at Seattle-based tech startup PlutoVR, during which the team ran a total of 12 games for 25 people. Playtesting helped reveal and fix many minor bugs, but the core intent of the game's mechanics held up and the majority of the feedback we received was very positive! The room was especially noted for being unique and memorable, especially for those who enjoy more narrative in their games.
My Roles
Given our small team size of just 5 people, I wore several hats during this project.
Narrative Designer & Writer
This involved charting the overall game flow and player experience, designing engaging puzzles, and closely intertwining the puzzles with the narrative. I wrote all the dialogue, gamemaster scripts, and environmental storytelling. I nailed down the premise, the events of the mystery, and the characters' roles and personalities, as well as their early visual designs.
UX/UI Designer
I planned the layout of the Unity app, and later produced most of the digital assets used in it. I also contributed to planning the game's internal logic to help out our team's programmer. I produced 100+ assets for use across 6 UI screens.
Gamemaster
When the event opened, I ran the game from behind the scenes during all of our playtesting sessions. This involved controlling manual stage cues, speaking in-character as the Fortuna's ship
autopilot, and giving the appropriate amount of hints to get players through the experience.
02
Research & Concept
Early Brainstorming
Before building anything, the first step was to research and brainstorm. After a period of researching AR/VR technology, escape rooms, immersive theater, and puzzle video games, the team ended up with a lot of different ideas about how to approach the story and gameplay.
In order to avoid any one of us dominating the conversation too much, we did 2 rounds of pitches. In the first, each team member pitched a simple premise, and we collectively chose the one we found most intriguing. In the second, I created a storycrafting guide, and each team member presented a more detailed outline of a story. We then picked out the most memorable elements of each and synthesized them into one broad outline of a story – the mystery of 3 missing crew members and their ship's AI. The sci-fi theme was picked due to how easily it would accomodate any technology we wanted to include. We made moodboards and concept art to get each other on the same page, and then got to work.
Early concept art of the room's intended aesthetic.
We knew we'd be working with a limited number of moveable fake walls and only a few major pieces of furniture, but we wanted each of the 3 characters that made up the SS Fortuna's crew to have their own little space on the "bridge". Based on those constraints, we laid out the room in a sort of U shape. Another advantage of this is that the players can't see the entire room when they enter, which contributes to a feeling of exploration as they start to look around.
A map of major features in the room.
A diagram of the room's central feature: the captain's console.
Storycrafting
After nailing down the overarching concept pitch, the team split off into their respective niches. For me and the team's character artist, the next step was the define more details of the story and characters. We spent about 2 weeks trying out different outlines, each of which had its merits but ran into the same problem – they were too complex for an experience that would only last 1.5 hours. So, we took all 3 of our previous drafts and simplified them to their core theme - overwork and the burden of expectations. In retrospect, if I did this project again I may have chosen a more dramatic theme to increase memorability, but this theme worked just fine and grounded the story in reality in a way that's generally uncommon for escape rooms.
Brainstorming how to interconnect components of the mystery.
Early versions of the Crew Roster, which players receive in the game's Case File.
03
the game Flow
Puzzle Planning
In order to plan out what we wanted to build, we had to create a game flow chart. From our research on other escape rooms, we knew we wanted to have around 3 major puzzles, interspersed with minor puzzles and story, as well as a memorable opening and ending to the experience that would help immerse the players into the world.
The first few flows were created collaboratively by the whole team. Based on the scope of our project, we decided it would be best for the game to be almost entirely linear to save us time on considering alternate paths through the experience. We also decided that due to the heavy focus on narrative, the game would work best with 2 players. This way, there would be that classic element of collaboration that makes escape rooms so fun, but we would avoid the problem of a large group of players spending time catching each other up on the story instead of progressing.
One of three early game flow brainstorming diagrams.
Defining and Refining the Flow
The game flow continued to evolve over the course of the project, right up until the final week. Due to the short timeline, we needed to get right to work on the physical aspects of the room, so we would define just enough to allow our set design and electronics leads to start prototyping, and continue refining the details around the aspects that had already been set in stone.
After the first few passes, the responsibility of updating the game flow fell to me, as I was one weaving the narrative into our gameplay plans. I split the game into sections – one for each character in the mystery, plus the opening and ending – then outlined the function and dependencies of each puzzle, all the mystery questions the players would need to answer, important story beats that would require dialogue, and all the necessary stage cues. Throughout the latter half of the project, I would update it with any major changes, so that the team could check if their decisions were in line with the puzzle flow and narrative intent without needing to remember every detail or ask me directly. This proved to be a huge time-saver worth the six total versions of the flow we created.
The sixth and final version of the game flow, with all details finalized.
Can be viewed in more detail here, along with the GM script.
04
Puzzles & Prototypes
Designing Puzzles
We aimed to fill out the escape room with a mix of different types of puzzles that would make up the core gameplay between piecemeal narrative segments. We decided on a couple physical puzzles that would require electronics very early on, and later filled out the rest of the space with a mix of much easier to produce physical and digital puzzles. I was not involved in the electronics very much at all, but later on came up with the majority of the other puzzles. Since we didn't want players to get stuck on a difficult puzzle and miss seeing the whole story, I erred on the side of making the puzzles easier, but still engaging enough to take the players a few minutes to solve.
Some of my brainstorming for puzzles hidden around the room.
The blacklight puzzle in the topmost image above, as seen in the escape room.
Creating Mystery-Solving Mechanics
The mystery aspect of the escape room presented a unique problem: how to keep non-narrative focused players engaged enough with the story to be able to solve the mystery. Some players very much enjoy searching for details and paying attention to characters, while others prefer not to get invested and focus on the puzzles instead, but for our escape room's core gameplay to work, the story needed to be mandatory. One problem we knew existed with mystery games and escape rooms was that the players would need to present the entire solution at the end, when they had no doubt already forgotten half the evidence. To combat this, I took inspiration from popular detective games such as Return of the Obra Dinn and Ace Attorney, and came up with a mechanic that would help players stay on the same page with the story.
It worked like this: the room's live character (the ship AI, LENS) would ask a question such as "Whose handprint is on the floor?" This question is a small part of finding the overarching mystery, and the players must answer it before moving on to the next question. In order to answer it, they can choose from a predetermined list of answers on the ship's "computer" (our Unity app). However, to prevent players from simply trying every option, they also have to present proof – the item that helped them make the connection. Around the room, we placed items with evidence tags, which have a QR code on them and can be scanned at an AR scanner by the ship's computer. When the players both choose the right answer and presented the correct piece of evidence to prove it, they would receive the next question. There were 10 of these in total, about 3 per section, with each group coming together to reveal the fate of one of the missing crew members.
L: An example of a mystery question series. R: Pieces of evidence the players would use to solve it.
Theater-of-the-Mind Prototype
Since we were attempting a combination of mechanics that was somewhat unusual, we wanted to have a little more certainty that players would be able to understand and enjoy the core gameplay. To test this, I put together a theater-of-the-mind prototype where I would run a few playtesters through the first section of the game using text descriptions of the props and puzzles we would eventually have on set. I would read out what the players see, then ask them what they do, tell them what happens, etc. – much like a tabletop RPG or a text adventure.
This prototype performed very well and provided me with some valuable feedback. The majority of the playtesters had no issues with solving the small sample of puzzles I'd included, and none of them reported not knowing where to go next at any point. They also grasped the evidence system better than I expected, though I suspect the simple spoken format made it easier, since the players didn't need to learn an unfamiliar input format. Provided we had more time to spare, I would have liked to test the entirety of the game this way, but even this truncated version provided the team with more confidence in the viability of our plans.
The theater-of-the-mind prototype. Can be viewed in more detail here.
05
Building The Unity App
Photo Credit: Jimmy Humphryes
The Ship "Computer"
As previously mentioned, the Unity app was meant to simulate the experience of investigating the ship's main computer in search of clues. In order to reduce the amount of information players needed to take in at once, we decided to make the computer inaccessible until the second section of the game, when the players have already gotten acquainted with the rest of the room and are ready to discover something new. The "screen" was actually an image rear-projected onto a curtain, but the players could interact with it just like they would with a real computer. Within, we hid things like crew voice transcriptions, the captain's log, and a hidden error report for LENS.
The challenge here was reducing the amount of information and functions within the app as much as possible. We needed the players not to get distracted by miscellaneous information, and we also had very limited time to program in new features. Me and our team's programmer worked together all throughout the process to cut down our plans to their minimum viable version, and to determine which parts of the UI would be handled by Unity and which ones would be handled by TouchDesigner.
Early wireframes of each of the Ship OS tabs.
Crafting the UI
Beyond designing the functionality, I was responsible for creating many of the UI assets used in the Unity app. As our priority was to make things functional first and pretty later, instead of making all the assets at once, I would generally create additional assets when our programmer requested them or when I noticed especially glaring inconsistencies. Due to the tight time constraints, we constructed both at the same time and bounced ideas and requests back and forth often, much like one might in a game jam. We had initially planned on using a pre-made asset pack to save time, but the ones we found on the Unity store did not end up working well for the features we wanted to implement. I made many custom assets from scratch, especially for the puzzles, which required unorthodox input methods. The fast pace of our work allowed us to get everything functional by the time playtesting rolled around.
One of the tabs as seen late in development, as well as some character dialogue.
06
Bringing the room to life
The Set
Photo Credit: Jimmy Humphryes
Of course, no escape room is possible without a set to immerse the players into the experience. The room our team built included furniture for each of the characters' areas, a rear-projected screen, and quite a lot of decoration, but the we knew we had to have a centerpiece to make the set truly memorable. One of my teammates created an incredible 3D print of the ship AI, LENS, which also doubles as a puzzle. The light at the front changes color based on LENS's emotional state, which helps communicate story beats to the players. Another standout feature of the room was the breaker box. It was intended as an easy first puzzle to get players looking around the room, but doubled as a dramatic moment where the players could turn on all the lights in the room at once and hear the ship computer start up. We took extra care to fill the set with small objects that would give a sense of the characters who used to inhabit it, such as tools, lab equipment, a mess of sticky notes, and books. The attention to detail did a lot to make the space intrigue the players and encourage them to examine items that could be used as evidence in the game.
Writing & Environmental Storytelling
Mystery writing is a tricky thing. You have to communicate the clues clearly to avoid confusion, but you also want to obfuscate the solution so the players must work a little bit to find it. I spent a great deal of time making sure the mystery's questions followed logically from each other, and that players would be able to pick the important details out from the unimportant ones.
My second concern was making the characters distinct enough that the players could easily remember them and keep track of the mystery. However, narrative takes a long time to read, and we needed the players to finish the game on time. My solution for this was to give the players the basic information about the mystery up front, and to make each character as distinct as possible. First, I wrote up a "case file" the players could reference at any time if they forgot someone's name or role. Then, when time came to write dialogue, I took care to give every character a distinct voice, as well as distinct handwriting for their journals and quickly scrawled notes. Each of them has a specific set of values that create conflicts between them, and these minor traits helped communicate this to the players.
The case file's crew roster, featuring the mystery's 4 central characters.
A few of the story-related props scattered throughout the room.
07
Playtesting & User Research
Running the Game as LENS
Being the one most familiar with the game in its entirety, I acted as the gamemaster when it came time to playtest the escape room. The team would hide out in our makeshift backstage studio, watching feeds from several cameras and mics we set up in the room to keep an eye on what the players were doing. My role was to manage certain manual stage cues and locks, and more importantly, to speak into a vocoded mic as the character of LENS.
LENS is at the center of the experience, and acts as a sort of guide through the story for the players, moving the mystery along and giving hints when the players get stuck. We had realized early on that giving hints unprompted is often better than waiting for players to ask for hints, as they have no way to know when they've gone off track. LENS's ability to give any amount of live hints was a huge boon, since it allowed us to tailor the difficulty of the game to each group of players. Players who were unfamiliar with puzzle games could receive hints right away, while experienced puzzle solvers could try their hand at the game without LENS's help. The diegetic nature of the hints also avoided breaking the players' immersion, which is a common problem in escape rooms. Overall, this system helped cover for aspects of the game that hadn't been telegraphed clearly enough and let the players have an enjoyable experience regardless.
LENS (lower left) and the console screen during late game. LENS's dialogue would appear in the dialogue box onscreen using speech-to-text, allowing players to read along with the voice.
Expanded version of the Game Flow, with LENS's script included. Can be viewed in more detail here.
Implementing Changes on the Fly
During our week of playtesting, the team worked together to implement fixes for bugs, broken props, and puzzle clues that players weren't noticing. I maintained a bug list and change log throughout the week to record all changes we made, so we could include them in our user research analysis. We thankfully did not have to make any changes to the overall structure of the game, which worked very well.
The biggest sources of design changes were:
-
Players often did not read things, or read very selectively. I will note that players who did read everything finished faster than players who didn't bother.
-
Some players would not check everything in the room or assume they shouldn't do anything with items they did not yet understand the purpose of.
-
Players would occasionally misunderstand wording that seemed obvious to us.
-
Players who were unfamiliar with video games would often misunderstand how the evidence system worked, or were confused that they were actually meant do some detective work.
We corrected for these issues by doing the following:
-
Adding more obvious visual cues to highlight the most important areas and writing, as well as scattering more hints pointing to those things to make them harder to miss.
-
More clearly advertising the escape room as a narrative-first experience, and telling players in the rule briefing that reading everything will never be a waste of time.
-
Changing obscure or specific wording to terminology more easily understood by the general public (ex. referring to the ship OS as the ship's computer instead).
-
Having LENS walk the players through answering their first mystery question to help them get a sense of how the evidence mechanic works.
User Research Findings
The qualitative data we recorded during playtesting gave us many insights into what we succeeded at and what could have been better. I will break down observations on individual aspects of the game below.
-
Overall Satisfaction: Very positive. The vast majority of groups (11 out of 12) finished the game on time, were actively interested in the gameplay, and reported enjoying the experience afterwards.
-
Previous Game Experience: Half of our players were already familiar with either escape rooms, puzzle games, or other video games, while the other half not so much. Both were able to finish the experience, though the latter group leaned much more on LENS's hints.
-
Interest in Puzzles: Interest in the puzzles was mid to high among 11 out of 12 of the groups, with the most popular puzzles being those that required more collaboration and teamwork between the two players. However, some players reported a feeling of information overwhelm when they gained access to the ship's computer.
-
Hint Usage: Most players reported feeling the puzzles were a reasonable difficulty, with the exception being a couple players who did not speak aloud enough to receive targeted hints from LENS. Our live hint system allowed for a highly customizable level of difficulty, which was a huge success.
-
Interest in Narrative: Half of the groups were very interested in the story and felt that it added quite a bit to their enjoyment, while the other half preferred not to read and only paid attention to the story insofar as it got them to the next puzzle. We decided this was a success, as we were appealing to our target audience without completely alienating everyone outside of it.
-
Evidence Mechanic Ease of Learning: There was a vast range of reactions to the evidence mechanic. Players who had played narrative-based games before picked it up right away. Other players understood its logic, but expected proof scanning to work more like an inventory system. The AR device could also have been replaced by a scanner that worked more reliably.
There were a couple groups who seemed frustrated by the need to "show their work", as they would come to a conclusion and then completely forget what brought them there. We concluded that this was simply caused by differences in individuals, and wasn't something we could fix.
-
Accessibility: Some players had a hard time parsing LENS's speech, but the availability of subtitles prevented this from becoming an issue. We also had one puzzle where one player would need to crouch down on the floor to see through a peephole, and some players found the rear-projected screen difficult to read. However, no game-breaking issues arose from these concerns.
08
Conclusions
Overall, we succeeded at everything we set out to do! Our players were successfully entertained, our experimentation with the bounds of the escape room medium was a success, and the experience was a valuable chance for the entire team to collaborate and explore new skills.
Given more time on the project, we could still improve a few things. First, the evidence system could use a more reliable input method and an even clearer tutorial. Second, several elements in the Unity app could be rearranged to lessen information overload and prevent players from overlooking important details. Third, the escape room could more clearly be advertised as a narrative-heavy experience, so players know exactly what they're getting into, and so we can more reliably attract the type of player who find narrative very engaging. Additionally, we were designing this experience knowing that it would be temporary, so improvements could certainly be made to the durability of the set and its electronics.
In this case study I only touched on the aspects of the project I worked on, but there is so, so much more. I certainly can't speak highly enough about my team and the colossal amount of effort they put in to making the escape room the best it could be, despite the comparatively very short timeframe.
Still curious about this project? See the links below!
