top of page

THE ESCAPE

SUMMARY

After having narrowly escaped being destroyed due to obsoletion, a service bot suddenly boots back up and is instructed via radio by an outsider to escape the mysterious facility and collect something of importance along the way. 

My goal with this personal project was to focus on
technical design and puzzle design, with the intent of allowing the player to use the player character as a tool to solve different environmental challenges. The inspiration for using the robot as a tool came from the game Pacific Drive

BREAKDOWN

Time

6 Weeks Half-Time

Team Size

Focus Areas

Solo
 

Technical Design
Puzzle Design
Game Design
Level Design

 

Software

Unreal Engine 
Blender
Miro

Assets Used

Audio sourced from Soundsnap

Hover

MECHANICS

Hovering

My goal with the movement was to give the player a more tactile and weighted experience when traversing the environment as a supposed service robot. I used a template for a hovering vehicle. It worked quite well and provided the groundwork I needed for a hovering robot and would alleviate the scope [1]. However, there were still aspects that I wanted to adjust and expand upon for the robot's movement to be where I wanted it: 

• Having it feel more weighted and higher up above the ground.

• Not be too fast when hovering.

• Not be as floaty when mid-air.

• Not being able to fly when the line trace breaks from a surface.

• Add mouse controls for the camera. 

 

In terms of having the robot feel more weighted and higher up above the ground, I decided to first model parts of the robot in Blender, specifically the base and the lid. Both the line trace and mass of the base mesh were increased, as well as experimentation with the linear and angular dampening [2].

 

Over the course of the project, I continued to iterate and experiment to prevent the player from being able to fly and continuously jump while mid-air. I also adjusted different variables such as speed and hover force, along with adding a center of gravity for the base mesh to make it more stable when traversing, which also helped later when working on the diving mechanic, but more on that later. 

 

Overall, I am satisfied with the results since the robot now plays closer to what I had as a goal when I started this project [3]. The biggest additions to the original work are that the player can now turn hovering on or off with a key press, as well as look around with mouse controls. 

[1] Hovering using the template.  

 

[2] My later iteration of hovering with higher elevation and more mass.  

 

[3] The final iteration I made of hovering with the desired results. 

 

Collecting and Dumping Loot

The movement then led to the addition of looting, since I wanted the player to be affected by the weight of any collected loot and see it be visually represented on the robot. The inspiration clearly derives from robot vacuum cleaners, and I thought that it would be fun to implement that into the context of gameplay
 

During the earlier stages of the project, I was able to implement the ability for the robot to collect the loot and have it move around inside with the help of simulate physics [4].  As previously mentioned, I wanted the player to be affected by the weight of the collected loot, and this was simply done by adjusting the mass of the cube mesh so that it was right when playing [5]

The overall logic is quite simple, as the initial loot cube that collides with the robot's collision box gets destroyed, spawning a new loot cube inside the robot's container. The spawned cube also simulates physics and enables collision so that the cube moves around in the container. 

The last iteration that I made for loot collecting was how it would be used when the robot is submerged underwater. The regular loot-collecting logic wasn't sufficient since the robot would be ascending away from any loot that was present, so I implemented a different logic where the robot would collect the loot like a magnet

The last thing I needed was the player to be able to dispose of the collected loot before proceeding to another area [6]The principle remains the same, where the previous loot gets destroyed and is replaced with a spawned one, similarly to the regular looting logic. The difference here is that the dumped loot has an add force that shoots the loot up in the air

[4] Early iteration of loot collecting.

 

[5] Later iteration of loot collecting that affects the balance. 

 

[6] Final iteration of collecting and dumping loot. 

 

Opening Lid and Deploying Wings

I implemented the mechanic of opening the lid in order to experiment with different ways of collecting loot for the player. The early stages of development had loot cubes tumbling down from a distance [7]
 

However, after further iteration, this particular mechanic was used mainly when the player had to dump the loot, except for the finale of the experience when the robot had to collect the reactor core. The reason for this is that it wouldn't be too reliable of method to collect loot, as the player has to be placed just right to get the loot that is falling. I thought about implementing a magnetic force, which eventually became used for when the player is underwater.  

When it comes to the deployment of the wings, my goal was to give the player the ability to boost, and have the thruster extend and the wings spread out [8]. This was implemented to give the player feedback that it was possible to boost, and I just think it turned out to be a cool way of introducing the player to the mechanic

[7] Early iteration of opening the lid for collecting loot. 

 

[8] Final iteration of opening the lid and deploying wings.

 

Jumping, Boosting, and Diving

The jumping and boosting mechanics were implemented as platforming is a central part of the majority of the puzzles. The key challenges of implementing both jumping and boosting were associated with the movement logic.

Specifically, I made sure that the player could not jump multiple times while mid-air, which, after further iteration, I implemented the logic to see if the
line trace has made contact with a surface.
If not, the player can not jump again, which fixes the initial issue. With boosting, the addition of delays between allowed boosts also mitigated the issue of continually using the mechanic [9]

Lastly, there is diving. This mechanic probably took the longest to implement properly, as I experimented with Unreal's Water Plugin and how it interacted with the Buoyancy component of both the robot and the loot. At first, it was possible to loot the cubes and descend underwater, however, there was no way for me to control said descent. The robot would rotate in all directions, and the process of tweaking buoyancy values, mass for the cubes, and center of gravity for the robot didn't meet my requirements of having it be streamlined and controlled [10]

My script checks to see how many loot cubes are present within the robot container box, and then adds force to the robot so that it descends in a controlled manner. Then there was the issue of the robot rotating underwater. After multiple attempts at fixes, I finally landed on using a PhysicsConstraint to limit the angular swing, or tilting of the robot, when underwater [11]. This worked better than I thought, as the player has much more control when descending [12]

[9] Final iteration of jumping and boosting. 

 

[10] Early iteration of diving. 

 

[11] Later iteration of diving. 

 

[12] Final iteration of diving. 

Buying Upgrades

As part of my core gameplay loop, I implemented an upgrade logic in the form of stations placed in the levels. The logic determines if the player can buy an upgrade depending on how many cubes are detected in the robot's container box [13]. When the upgrade occurs, it calls a specific function from a function library that manages all upgrades for the robot. The upgrades that can be acquired are the engines, jumping, and boosting. The engine upgrade was made as a free upgrade due to the onboarding portion of the starting area, where the player has to overcome an obstacle. Overall, the simplicity of the logic fits well with the linear nature of the level design


 

[13] Final iteration of upgrading. 

Loot
Lid / Wings
Jump, Boost, Dive
Upgrades

LEVEL DESIGN

My intention with the level design of the experience was to create levels that were suited to teach the mechanics through onboarding and to sell the theme of the world through environmental storytelling
 

Overview

Level Flowchart

1.png

1. Conveyor belt. 

4.png

4. Broken elevator. 

7.png

7. Loot transport.

2.png

2. Radio call.  

5.png

5. Exploring the factory. 

8.png

8. Smashing success.

3.png

3. Overcoming obstacles.

6.png

6. Navigating the tunnel.

9.png

9. The dive. 

10.png

10. Stealing the core.

Level Design Techniques

I used environmental storytelling most notably at the start of the experience, where obsolete robots are disposed of. Further use of this technique is in the factory by showing new robots being built on the conveyor belts, as well as the robot that has fallen down after taking too much loot during the first bridge puzzle. Bait and switch is used in the factory area, where the player will turn around and see the rest of the loot cubes behind the conveyor belts. 

 

Breadcrumbing was also used throughout the experience with the loot cubes, but most notably after the first bridge puzzle, when the player jumps onto a large bridge and sees the path towards the maintenance area with the help of said loot cubes. There is a pronounced leading line that guides the player underwater on the path towards the reactor core. I also used funnel before reveal in the underwater portion of the experience, where the player will dive through narrow corridors and then resurface to reveal the reactor core.



 

Showcase of the level design techniques. 
 

PUZZLE DESIGN

Jumping Puzzle

After acquiring the ability to jump from the service station, the player is able to jump up on the crates and exit through the small hatch at the top. With this puzzle, I wanted the player to have a clear goal when entering this space for the purpose of onboarding the jumping mechanic, with the stacks of crates leading to the hatch on top. 

 

Bridge Puzzle 1

Start of the jumping puzzle. 
 

The solution to the jumping puzzle. 
 

This particular section will introduce the player to pressing a button to extend a bridge, which is fairly simple. The goal here was to allow the player to make a connection between the color-coded button and bridge  to familiarize with it before entering the next puzzle.

 

Start of the first bridge puzzle. 
 

The solution to the first bridge puzzle.
 

Bridge Puzzle 2

This is a more elaborate variant of the previous bridge puzzle, in which the player must solve the puzzle in a special sequence. The first step is to dump the loot nearby to be able to jump across to the other side and extend the bridge. The player can then collect the loot and acquire the upgrade. 

 

Window Puzzle

Start of the second bridge puzzle. 
 

The solution to the second bridge puzzle.
 

After acquiring the wings and booster, the player will see a cracked window nearby the service station. This was intentional, as I wanted the player to be guided towards immediately upon receiving those abilities. The solution here is to boost through the cracked window glass and continue onwards. 

 

Descend Puzzle

Start of the window puzzle. 
 

The solution to the window puzzle.
 

Here is a twist of a previous mechanic, whereby the weight of collected loot has an effect on the player's balance. In this puzzle, the player must collect the loot to become heavier and able to dive

 

Ascend Puzzle

Start of the descend puzzle. 
 

The solution to the descend puzzle.
 

Here I wanted the player to not quite reach the hole that leads to the other side. This is where the dumping of loot will make the robot light enough to ascend

 

Spinning Fans Puzzle

Start of the ascend puzzle. 
 

The solution to the ascend puzzle.
 

This is a combination of both ascend and descend, as my intention was to make the player use what has been learned previously in a combination of looting, dumping, and boosting. 

 

Start of the spinning fans puzzle. 
 

The solution to the spinning fans puzzle.
 

Catching Puzzle

The last variation of a puzzle with a button, with the twist being that the loot must be caught by having the lid open first. This is in contrast to the previous times, where the player had to dump the loot instead, which was a purposeful design choice in this case. As mentioned previously, I initially wanted the ability to loot while the lid was open to be more frequent, but in this case, I saved it for the finale as it felt more impact when it comes to stealing the reactor core

 

Start of the catching puzzle. 
 

The solution to the catching puzzle.
 

PROBLEMS AND SOLUTIONS

Loot Physics

There was a rather worrying problem that I encountered when it came to how the loot physics interacted with the player's actions. Specifically, any time when the player decided to either jump or boost then the loot inside would clip through the robot's mesh, no matter how many adjustments were made for the collision settings and variables for the force

To work around this, I came up with a 
diegetic solution and redesign of the robot. Naturally, this also meant adding feedback so that the player would know when something is not allowed. This resulted in several sounds that the robot makes to signify the player. 

The
sounds are inspired by the various noises that the UFO's make in the movie Close Encounters of the Third Kind. Basically, a lot of tuba and trombone cues. Besides being a somewhat endearing feedback sound, it also resulted in further iteration of my puzzle designs. 




 

Loot physics problem. 
 

Loot physics solution. 
 

Diving Softlock

One of the largest issues that I encountered while designing the underwater section was the situations in which the player can get softlocked when ascending up to the ceiling. This was solved by having two anti-softlock areas that lead straight up to small chambers that contain more loot for the player to collect if it was missed

 

Diving softlock problem. 
 

Diving softlock solution. 
 

DEVELOPMENT SCREENSHOTS

These images showcase my production pipeline that covers pre-production, earlier iterations of the blockouts, and the models I made in Blender

 

REFLECTIONS

Overall, I am very satisfied with how this piece turned out, at least when it comes to how the mechanics were used within the environments. That being said, I would have wanted to iterate the level design even further, since the subsequent levels are focused on onboarding

I also wish that the dumping of the loot had been
refined, as it is still buggy when the player decides to open the lid, where the loot cubes move sporadically inside the robot's container. And the collision overall isn't quite there since the cubes have a tendency to pop out sometimes when the robot is underwater

In conclusion, this is a project that I definitely want to continue to
develop further by not only iterating on the mechanics, but also creating a less linear level design and with more puzzle complexity than what was offered in this smaller experience. 


 

FULL PLAYTHROUGH

SAMI OUZAA

+46 70-796 46 59
contact@samiouzaa.com

  • linkedin
  • cv

I am part of The Game Assembly’s internship program. As per the agreement between the Games Industry and The Game Assembly, neither student nor company may be in contact with one another regarding internships before April 23rd. Any internship offers can be made on May 5th, at the earliest.

bottom of page