top of page

Playdead's INSIDE-inspired
environmental puzzle design

This project is my deep dive into puzzle design, inspired by Playdead's game INSIDE. I aimed to refine my skills in deconstructing and creating environmental puzzles within an existing IP.

The process simulated the development phase when the core verbs and mechanics are set, and the challenge shifts to creatively combine them into new, engaging experiences. I picked INSIDE for its engaging but minimalistic puzzles and simulated the task of crafting a new puzzle within its boundaries.

This portfolio piece is my journey through the design process and a description of the practical steps I took for implementation. It's like sitting down for a chat about game design – the what, why, and how behind the scenes.

Final puzzle prototype


Setting the goal

To reach my personal goal of this project, I decided to set up specific minimum requirements for what I want to create:

  • Notion page with game progression and puzzle deconstruction

  • a medium-sized 1-screen puzz, that would fit into the game's difficulty curve and the player's knowledge state

    • requires at least 3 steps to solve

    • no extra mechanics in addition to those existing in the game



To know the context of the game and how the puzzles are structured, I played the game and deconstructed its information flow, keeping the deconstruction notes on a dedicated Notion page

During the deconstruction, I paid extra attention to:

  • the order of mechanics presented

  • ways in which the mechanics are presented

  • progression of mechanics - their updates with new rules

  • deliberate breaking of previously set rules

  • what are the uncertainties and challenges of each puzzle

  • how the mechanics are mixed with challenges

  • specific design patterns

Link to Notion with deconstruction

At this point, I was also writing down puzzle ideas that naturally came to mind to free my head for brainstorming later.


I was taking notes digitally during playthrough so it was faster to transfer them to the deconstruction page



Defining the point of the puzzle

To know, which mechanics I will be able to use for the puzzle, I needed to decide on the point of the game where it would happen.


The decision was based on:

  • The density of complex puzzle in a row, as that would influence the player's brain fatigue

  • Whether the target complexity of the puzzle (1 screen; at least 3 steps) would fit into the dynamic of the game

  • Combination of known and taught mechanics and their implementation complexity, as I had limited time to prototype

Ultimately, I decided to set my puzzle in Forest Hangar, after the player is taught a new mechanic of pneumoboxes.


Credit: "INSIDE", Playdead, 2016


Credit: "INSIDE", Playdead, 2016


Brainstorming and picking the idea for a prototype

When brainstorming on my own or coming up with ideas for a team brainstorm, I rely on several methods.

This time, I used these techniques:

  • creative free flow while rereading deconstruction to get the most obvious and surface-level ideas out of mind

  • synthetic with mechanics: taking 2-4 mechanics and seeing how they could interact (i.e. pneumoboxes, light as danger, pushing/pulling, and others)

  • synthetic with challenges: doing the same with 2-4 challenges (i.e. timing of movement, timing of interaction, spacial precision, and others)

  • thematic: taking themes and topics of the game and game areas to see what challenges and mechanics could complement them

With all ideas, I tried to come up with at least 3 steps for the solution.


Level sketch

In the end, I have settled on 2 ideas: one - of a goal medium-sized puzzle, that involves fire and extinguishing mechanics; and a second one - of a small timing challenge, that would require just 1 step. For this post, I decided to focus on the first idea, as it fits the goal better. Level layout and solution documentation were done in Miro.

The main pillars were:

  • solution requires exploration

  • meaningful backtracking

  • timing challenge

  • using interactable and environmental objects in a multitude of ways

This way the changing layout of the level makes backtracking meaningful and challenging for the player. In addition to movement challenges, players also need to account for both usages of the manipulated object, which creates more mental load.

Encounter Design - Inside - Frame 1.jpg
Encounter Design - Inside - Frame 2 (1).jpg



When the level was planned out, I started to prototype, using Unreal Engine 5.

The first thing I needed to recreate was INSIDE's 3C system: character, camera, and controls.

I needed to recreate those with metrics as close to the original as possible to support the puzzle's positional and navigational challenges based on the original game.

In addition to basic movement, I implemented climbing ladders with switching sides on the top and swinging on a rope. Creating the base character and extra navigational modes took ~16 hours. 

Climbing a ladder with switching sides and extra impulse on jumping off

Physics-based rope swinging

Next, I quickly created scalable systems for:

  • dietetic UI: modular buttons, moving the ladder up and down; a lever for activating the conveyor belt; a valve for moving the cart around

  • fire propagation system with an extinguishing mechanic

  • conveyor belt that moves objects back and forth with adjustable speed


Trying to keep the prototyping fast, I spent roughly 3.5 hours on this task. However, I still was trying to keep the code architecture simple and adjustable.

After all the main elements were done, I set up the puzzle level and ran some internal iteration rounds, noting down and fixing bugs, unnecessary frustrations, and possible soft locks and exploits. 

In this project, I focused on puzzle design so I didn't allocate time for visual aspects, that would not influence the design and feedback of the puzzle

Controlling the cart with a valve

Controlling the conveyor belt with a lever to move items that cannot be pushed/pulled around


External playtesting + iteration

One of the soft locks encountered by a playtester - level layout allowed for rolling the burning box all the way to the left

Now came the most exciting part of this project, which would show me how well I managed to reach my goal of making a puzzle that would be true to and fitting for the target project - external playtesting.

The difficulty of this part was that I needed this puzzle to be playtested by people who are familiar and proficient with INSIDE. Luckily, a few people answered my request, played the puzzle, and provided written feedback and recordings of playthroughs.

All feedback, related decisions, and following tasks can be found on this Notion page
When processing the feedback, I:

  1. Wrote down intentional and unintentional player behaviors, paying additional attention to audial non-verbal cues, UI/UX improvements, bugs, and then verbal and written feedback

  2. Made tasks for bugs, sorting them by severity based on how much they prevent the prototype from being a good assessment of puzzle design

  3. Came up with solutions for unintentional behavior, made tasks for them

  4. Noted my thoughts about what issues the verbal and written feedback tells me as a designer

  5. Came up with solutions for the issues

  6. Made tasks and prioritized them based on the frequency of encountering and influence on a good assessment of puzzle design

To my delight, apart from some technical problems they had, both playtesters have pointed out that :

  • they"loved the experience"

  • the puzzle is "fun and understandable"

  • "puzzle design very much [felt like and reminded them] of INSIDE". 


Code refinement

After the main design was set I spent some time cleaning up the code:

  • removing debug functionality

  • commenting the newly and recently implemented features

  • aligning the blueprints to improve readability

  • sorting variables into related categories

I deem it to be an important part of the work, as in the company environment it would improve the readability of my code for other departments and decrease the workload for the programmers, who would need to edit or review my code.


Second iteration and final result

Most of the improvements in the second iteration were aimed at removing frustrating backtracking and improving controls (for example, making switching sides on top of the ladder controllable instead of automatic).

The second iteration took just 3 hours altogether.

Here, you can see the playthrough of the final iteration.


Header picture - "INSIDE", Playdead, 2016

bottom of page