About the Project
Since 2010, I’ve primarily worked with Unity, but I wanted to challenge myself and explore Unreal Engine. As a personal learning project, I put together My First Test Chamber, a small experiment in UE5. My main goal was to build a project using only Unreal Engine's Blueprints.
This isn’t a full game but rather a study piece where I explored the basics of Unreal Engine through a first-person puzzle game. The project includes basic interactions, a graybox level, no combat or failure states, and a simple structure with a start, a few puzzles, and an end.
Inspired by The Talos Principle and Portal, I built this over about two months in my spare time. It’s a short, 10-minute experience focused on experimenting with UE5’s tools and blueprints. There’s no polish or final art, just a rough prototype to test ideas.
First Weeks - Learning the Basics
In the first few weeks, I focused on learning the basics of Unreal Engine 5, including navigation and core concepts. This stage was fairly easy and exploratory since there are many similarities between Unity and Unreal. I imported a few assets and started experimenting with movement and asset placement.
At this point, I wasn’t sure what the project would look like. My main goal was to build a small game using only blueprints. I decided on a first-person game to focus on learning the engine’s logic without worrying too much about animations, camera clipping, and other third-person challenges. I also chose not to include enemies since AI felt too ambitious for a first project. After a few days, I settled on a first-person puzzle game inspired by The Talos Principle, Portal, and The Witness.
With that in mind, I picked a door and button system as the main mechanic. It's a common element in many games, making it a great starting point for a learning project. I then started researching and developing my own door and button system.
After several days of tutorials and trial and error, I built a simple but versatile system. It allows doors to open when a player steps on a button. A door can require one or multiple buttons to open, and I can easily assign a button to a door using the eyedropper icon in the button’s hierarchy.
Weeks 3 & 4 - Adding More Stuff
Once the door system was complete, I started experimenting with potential puzzles using this mechanic. I planned the following:
-
A door that requires two buttons: teaches the player that doors may need multiple buttons to open.
-
A button with no visible door: introduces the idea that buttons might not always be next to the doors they control.
-
A button that opens an unexpected door: teaches players that button-door connections aren't always obvious.
-
A button that activates a platform: shows that buttons can control more than just doors.
-
A button that needs constant weight to stay active: expands the game’s possibility space.
I successfully implemented the first three puzzles but I didn’t have a moving platform yet or a pressure plate mechanic. So, I started designing them. I followed tutorials, made adjustments, and faced challenges, especially with passing information between different actors. However, as I worked through these issues, I started to see the full potential of Blueprints, and using them became genuinely fun.
Like the door and button system, my platform system was designed to be easily adjustable in the editor, which proved valuable during level design. I could tweak its speed and destination on the fly. In the end, I scrapped the puzzle where a button activated the platform because it wasn’t interesting enough, but I plan to bring it back later. For now, the platform existed just to introduce players to moving platforms.
At this point, once a button was activated, it stayed active. To add more depth, I introduced a new type of button: a pressure plate that requires the player or an object to stay on top for it to remain active. This kicked off the biggest challenge of the project: designing and developing an item pickup and drop system.
This turned out to be trickier than I expected. For example:
-
What happens if two items are next to each other?
-
What if the player is already holding an item?
-
How do I prevent items from being dropped inside walls or floating in the air?
I'm not a programmer, so I usually work with them to find technical solutions that fit the game's design needs. But this time, I had to figure it out myself. I solved these issues using Line Traces (Unreal’s equivalent of Unity’s Linecast) and ran into ongoing challenges with hit detection for the pressure plate, which I kept refining until the very end of the project.
After a few weeks, this was the result:
Final Weeks - Content & Polish
With the main mechanics in place, I shifted my focus to adding content and polishing the game. Over the next few weeks, I:
-
Implemented all puzzles
-
Worked on the ending sequence
-
Added lighting
-
Built the menus
-
Fixed a lot of bugs
-
Optimized the project for stable fps
-
Polished, polished, and polished some more
Along the way, I also made adjustments to improve pacing. Some rooms were resized because they felt too empty or disrupted the level flow. Others were optimized by reducing overlapping light sources and minimizing overdraw from transparent materials.
And in the end, here’s the final result:
Learnings and next steps
This project was incredibly fun to work on! I learned a lot about Unreal and feel proud of what I accomplished. I managed to create a game entirely on my own using only Blueprints, without writing a single line of code!
Here are my top takeaways from the experience:
-
Blueprints are powerful and easy to grasp for non-programmers.
-
Unreal has more built-in game-ready tools, whereas Unity sometimes feels too generic in its approach.
-
Level design in Unreal was more challenging but also more flexible than in Unity.
-
The widget system for UI is much easier to use than Unity’s Canvas, especially for non-programmers.
-
Unreal’s lighting system is complex but delivers great visual results with less effort than Unity.
-
Debugging felt harder than in Unity, though this might just be my lack of experience.
-
Optimization was by far the biggest challenge. UE5 is heavy, and even a simple game like mine could drop below 30 FPS.
I plan to keep working with Unreal, and for my next project, I want to focus on animation/character movement or AI.
In the meantime, don't forget to download "My First Test Chamber" on itch.io.