
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
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.
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. Conveyor belt.

4. Broken elevator.

7. Loot transport.

2. Radio call.

5. Exploring the factory.

8. Smashing success.

3. Overcoming obstacles.

6. Navigating the tunnel.

9. The dive.
