Puzzle Game

Specifications
• Developed at The Game Assembly
• Custom game made in Unreal Engine 4
• Style: Puzzle/exploration
• Other team members: Shwan Hawez – Technical Artist, Oscar Johansson – 3D Artist, Simon Lindskog – Sound Designer
• Development duration: 4 weeks half-time

Tools
• Unreal Engine 4

Summary
A puzzle game made in Unreal Engine 4. The main objective that I wanted to achieve by making the game was to learn more about the visual scripting language that Unreal Engine uses and learn more about the engine in itself.

Design process
I thought about what kind of puzzles would be both fun to design and play, and interesting to script. I took inspiration from ‘The Witness’, an indie game where the player navigates through labyrinths on monitors in order to progress through the game.

Initially I created modular blocks that I could build the level with. The artist could then replace the pieces with his own in a later stage without changing my design. After I had the level blocked out I started working on the doors; I made them open and close when the player came close or walked away. I also created an object which communicated with the door and unlocked it when the player interacted with it.

Example of a puzzle

After that I started working on the puzzles. They basically work like snake in a maze, but the main difference being that the player can backtrack. I had many ideas on how I could solve it, the first thing I tried was to move the player to another area and have the player walk around in the maze, the player would look at a monitor which filmed the maze from above. When the player moved, triggers would activate different colliders to hinder the player from intersecting with the tail. However I couldn’t get it to work the way I wanted, the colliders wouldn’t activate how I wanted them to. So instead I tried to do it with ray traces from the colliders to the player, in order to see which direction the player moved in, in relation to every collider. This didn’t work either and I felt like it was too complex for what I really wanted, so I tried to rework it from scratch and finally I made it work.

I built the system to be very modular and dynamic in order to easily build and iterate on the puzzles.

Every panel that has a puzzle can be interacted with by the player; the panel communicates with a door which opens when the puzzle is complete, a camera that renders the maze, and a spawn point where the player starts the maze. This approach allowed the player to stay at the monitor instead of teleporting to the maze. The player can then navigate in a network of nodes where each node holds references to the adjacent nodes to which the player can move. When the player reaches a designated node the puzzle is completed and calls on a function in the door which unlocks and opens it.

nodes

Whilst building the puzzles I discovered new ways of using the tools I had. One idea that a classmate had was to fade out the paths and let the player navigate in the dark. Another feature was the portals that the player could enter in order to traverse greater distances. It was really fun to play around with these features and see what I could build with them.

puzzleDark

A puzzle where the path is partly hidden.

puzzleTeleport

A puzzle where the player must use teleports to progress.

When I had built the six puzzles that I needed for the level I scripted the mission, which is to collect two batteries and take them to the large monitor in the hub room of the level.

All in all the game was really fun to make and I really learned a lot of how to use a visual scripting language.

Screenshots