Locked Away
"You have been kidnapped and have only five minutes to solve the puzzles and escape. Can you find the way out before time runs out?"
Role: Game Producer & Programmer
Development time: 2 months
Team Size: 5
Engine: Unity
Methodology: Agile
Programming language: C#
Project management: Trello
Tools: Git & GitHub
Genre: 3D Escape Room, Puzzle Game
Platform: PC
Year: 2024
About Locked Away
Locked Away is a short 3D escape-room game created by a multinational team of five during a workshop course at Kajaani University of Applied Sciences. We developed it in Unity within two months.
The player wakes up in a dark basement after being kidnapped. They have only five minutes to explore the room, solve a connected set of puzzles and find a way out before time runs out.
We wanted the game to feel like a real escape room, where every clue leads to something else and the pressure slowly builds as the timer gets closer to zero.
My Role
I worked as both the Game Producer and one of the programmers. As the producer, my main responsibility was making sure the team had a clear plan, everyone had meaningful work and the project stayed realistic within the two-month development period.
My responsibilities included:
-
Helping the team define the game concept and scope
-
Planning the project using an Agile approach
-
Creating milestones and managing tasks through Trello
-
Coordinating a multinational team with different levels of game development experience
-
Assigning tasks based on each team member’s skills
-
Supporting teammates who were new to game development
-
Coordinating programming, 3D art, level design, audio and puzzle design
-
Tracking progress, adjusting priorities and resolving blockers
-
Managing puzzle dependencies and ensuring each puzzle led naturally to the next
-
Managing version control through Git and GitHub and resolving merge conflicts
-
Programming gameplay and interaction systems in Unity with C#
-
Organising testing and helping prepare the final build and presentation
​
​Several people in the team had never worked on a game before, so I could not expect everyone to immediately understand how game development worked. I had to explain tasks clearly, help people when they got stuck and make sure they still had real work that would be used in the final game.
Project Goals
Our main goal was to create a complete escape-room game within approximately two months. It needed to have several connected puzzles, a clear beginning and ending, and enough atmosphere to make the player feel trapped and under pressure.
We wanted every puzzle to lead naturally to the next one. Solving something should give the player a new clue, object or piece of information instead of making the puzzles feel like separate tasks placed around the room.
Another important goal was choosing a concept that everyone would enjoy working on. The team had very different gaming backgrounds. Some people mostly played VR games, while others preferred shooters or completely different genres. During brainstorming, I tried to make sure everyone had a chance to share ideas and that the final concept had something interesting for each person to work on.
Production Process
We used an Agile approach throughout the project, developing the game in smaller stages and adjusting our plans as the project progressed. We used Trello to divide the work into clear tasks, assign responsibilities, track progress and keep the team focused on the next priorities.
Because several teammates were new to game development, I often had to break larger tasks into smaller and more manageable steps. I tried to give everyone work that matched their current skills while still allowing them to learn something new and contribute directly to the finished game.
We regularly reviewed the current build, checked what was working and adjusted our priorities when something took longer than expected or a team member became stuck.
The development was divided into four main stages:
Late October – Concept and planning, first playable prototype
We brainstormed different ideas, chose the escape-room concept and planned the main puzzle sequence. We worked on the basic player movement and interaction systems so we could quickly test whether exploring the room and interacting with objects felt good.
Early November – Environment and puzzle development
The team worked on the basement environment, 3D assets, audio and individual puzzles. I followed the progress, helped divide tasks and made sure the different parts of the game still matched the same overall plan.
​
Late November – Connecting the puzzles
Once the individual puzzles started working, we connected them into one full sequence. We checked that every puzzle gave the player the clue or item needed to continue.
Early December – Internal testing, final build and public playtesting
​We tested the full game, fixed problems between connected systems, improved the atmosphere and prepared the final playable build and presentation. We also had a public playtest to see how players understood the puzzles, whether the time limit felt fair and whether the complete game worked without anyone explaining what to do.
Challenges and Solutions
My biggest challenge as the producer was working with people who had never made a game before. Some teammates were still learning the tools and did not always know how their work connected to the rest of the project.
I handled this by explaining tasks clearly, checking in regularly and helping people break larger problems into smaller steps. When someone was stuck, we looked at the problem together or changed the task instead of letting it stay blocked for too long.
Another challenge was that everyone had very different ideas about what kind of game we should make. During brainstorming, I tried to make sure that nobody’s ideas were ignored. We eventually chose an escape-room game because it gave everyone something interesting to work on, including puzzles, programming, 3D art, audio and atmosphere.
Version control also became a challenge during development. Some team members had trouble using GitHub, and we occasionally ran into merge conflicts when several people changed the same parts of the Unity project. I had to learn how to resolve the conflicts, work out which changes needed to be kept and help the team avoid similar problems in the future. This gave me useful experience managing a shared project where several people were working on different parts of the game at the same time.
The original VR idea also became a production challenge. VR interested some members of the team, but supporting it would have required more testing, more technical work and different controls. Since we only had two months, we decided that finishing one good PC version was more important than trying to make two versions at the same time.
Making the puzzles connect properly was another important challenge. We did not want the player to solve random puzzles without understanding what to do next. Every completed puzzle needed to provide a clue, item or change in the environment that pointed towards the next one.
To make this work, we tested the entire puzzle sequence instead of only checking each puzzle separately. I kept track of what every puzzle required and what the player received after completing it.
Gameplay
The player explores a dark basement and searches for objects, clues and information that can help them escape before the five-minute timer reaches zero.
The main gameplay features include:
-
First-person exploration
-
Interactable and movable objects
-
Picking up and dropping items
-
Mouse-based object manipulation
-
Environmental clues
-
Logic and object-based puzzles
-
Connected puzzle progression
-
A five-minute countdown timer
-
Separate win and lose conditions
-
Music that becomes more urgent as time runs out
​
The puzzles are connected, so solving one gives the player something that helps them continue. The player needs to understand how the different objects and clues in the basement relate to each other before the timer runs out.
Playtesting Feedback
We held a playtest shortly after the final presentations. The game worked from beginning to end, and players did not run into any major technical problems.
However, some of the puzzles were more difficult than we expected. A few players became stuck because they were not sure which object or clue they should focus on next. Several testers said they would have liked more hints if they had not made progress for a while.
This showed us that puzzles can feel very obvious to the people who created them but still be confusing to someone seeing them for the first time. With more development time, one of our next priorities would have been adding optional hints and making important clues easier to notice without directly revealing the solution.
Players especially liked the atmosphere, the variety of puzzles and the way the puzzles connected with each other. The music also received very positive feedback. It became faster and more urgent as the timer got closer to zero, which made the final moments feel much more stressful.
Outcome
We completed Locked Away within the planned development period and presented a finished playable PC build.
The final game included a complete basement environment, several connected puzzles, interactable objects, environmental clues, a countdown timer, changing music and separate win and lose conditions.
The team managed to finish its first longer game project even though several members had little or no previous game development experience. Choosing to focus on PC instead of dividing our time between PC and VR also gave us more time to finish and test the main experience.
For me, the project was a valuable opportunity to combine programming with production, team support and responsibility for the overall puzzle progression.
What I Learned
Locked Away taught me that producing a team with different experience levels is not just about assigning tasks. I needed to understand what each person was comfortable doing, explain how their work connected to the rest of the game and make sure they still had space to learn.
I also learned how important it is to involve the whole team when choosing a concept. People are more motivated when they feel heard and can see part of their own ideas in the final project.
The project gave me more experience managing dependencies. A single puzzle could require programming, a 3D model, audio, environmental clues and testing before it was actually complete.
The playtest also taught me that puzzle difficulty is very hard to judge from inside the development team. Since we already knew the solutions, some clues felt much clearer to us than they did to new players. In future puzzle projects, I would arrange external playtests earlier and leave more time to improve the clues and player guidance.
Most importantly, the project taught me when to reduce scope. Choosing PC over VR allowed us to finish one complete game instead of trying to support two versions that we might not have had enough time to polish.