The Three Axis Problem - Insight
Solve Puzzles in this MC Escher-inspired Game and reach the end.
Overview
This Game was my final thesis project. I worked alone on it but had good Insight from Playtesters and my lecturers. I wanted to revisit this concept from a previous pitch. This was possible because with a plug-in I found a way to work around the technical constraints it would have posed.
The following page merely highlights some aspects of what I did for this project.
Content:
-
Genre: 3D Puzzle Platformer
-
Engine: Unreal 5.3
-
Team Size: solo
-
Duration: 5 Weeks (128 Hours Effectively)
-
Release: June 2024
-
Platform: PC
-
Tools: Blender, Adobe Photoshop, Adobe Premiere, Miro, Trello, Google Docs, Google Notes
Role(s) and Responsibilities:
- Game Design: Concept of Mechanics and System Design, Implementation and Iteration
- Level Design: Iterative Process of Puzzle Design with Player Guidance in mind.
- Visual Scripting: Movement Constraints, Camera Behaviour, Gravity Cube and Interaction System, Level loading. Camera Smoothing, Sound Settings via Blueprints.
- UI: Implementation of Prompts, Main and Pause Menu.
Game Design
I added iterated and cut multiple mechanics until I settled for a feasible and interesting amount. I found some puzzle concepts via playtesting and trying out different combinations of mechanics.
For the first level, I used references.
I build puzzles from the back to the front. I try to build so that when the player is playing the level they have to use that interaction. The puzzles are defined by what the player can't do.
Level Design
Restrictions
Through Testing and experience from previous projects, I decided on several Rules for my Levels:
GYM
I tested mechanics in a GYM-level to ensure that Movement and Jumps felt acceptable enough, as they were not the main focus of my thesis. I made sure that scales and colours were consistently used within my levels. I used the GYM as well to see how winding stairs are perceived by players. With this, I answered questions like, how wide or narrow can they be, how many steps are needed for a 45° angle and is the rolling speed of the Player Character is acceptable.
Concept And Blockout
Before the creation of a concept, I asked myself, what mechanics and features need to be taught the player at which point. The concepts for the puzzles were either based on references or found through playtesting the mechanics in the GYM. The two-dimensional level concepts I made were mostly used as Player Flow Maps because for the type of levels I created they were otherwise insufficient.
Iterative Process
After I decided the the scale of assets and movement distances in the gym I began the block-out process. I used blender to create the correct assets and I made dithering materials for the effect of the camera going smoothly through objects. The scale of stairs and the colour coding of assets changed significantly over time.
To ensure modularity I created LevelInstances of Puzzle sections and could therefore move them around and rearrange them easily
I conducted multiple playtests with different testers to ensure that mechanics were understood by different player types. With every week, I made level guidance more obvious.
Scripting
Manual Camera Adjustment Feature
View Blueprint: Smooth Camera Collision
View Blueprint: Pressure Plate
Some of the Mechanics I scripted via Blueprints are:
Learnings
Design and Coding
Game design and coding alongside level design can't lead to modular code when you have that kind of time pressure. The ability to create child blueprints saved me, but I would make the interaction system more modular if I had the time again.
More structured Testing and Iterations
Initially, I thought the iteration process was more about changing elements in the level. However, individual mechanics were often broken or even the engine crashed. Bug-related test results like these and their fixing delayed the testing of the level design. When I made major changes to the levels, I made copies of them so that there was a playable level at all times.
Limitations through Scaling
While many of the limitations were intentional, a few I would have preferred to avoid with better reference analysis. For example, the width of the door frames did not allow a cube to fit through without the player character carrying it. This meant that certain dynamics were no longer possible. I could achieve something similar with the help of the moving platforms, but it's not ideal.
It was important to me to keep to the level size limit, which also made the visual guidance of the player difficult. Turning the player towards a point of interest is easier when the level is not confined to such a small size. If technically possible I would not limit level sizes again in order to enhance the gameplay and make the design process faster.
Difficulty Curve
I had problems to bridge the difficulty from the first level to the advanced levels. Through testing and subsequent iterations, I was able to simplify the more difficult sections, but I later learned of other approaches such as Civilization's Decision Tree, an undeniably complicated game that asks the player to make one decision, and then two, and then three, and so on. This way the player is not overwhelmed and is slowly introduced to the complexity.
Distances between Actions and Puzzle solutions
The longer the path, the more the player disassociates puzzle elements that belong together. I have mitigated this break somewhat with the level Moving Platforms, where the player has to reuse elements of a puzzle later and with a jump section. In the future I will concider this distance either to make puzzles easier or harder.