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.

      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.

itch.io Symbol Download from Itch

PDF Symbol View Documentation

Game Design


The Three Axis Problem - Final Thesis Project - Gameplay - Toni Winkler

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.

View: Early Gameplay Idea

View: Mechanics Playground in GYM-Level

Level Design


Restrictions

Through Testing and experience from previous projects, I decided on several Rules for my Levels:

  • Maximum of 30x30x30 meter large levels to ensure the feasibility and design puzzles in a more confined space.
  • Not more than 6 different orientations for the player character ( X, Y, Z, -X, -Y, -Z ) Keep platforming simple and to a minimum.
  • Player Respawns does not reset the objects within the level.

  • 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.

    The Three Axis Problem - Final Thesis Project - GYM -  Jump Distances - Toni Winkler      The Three Axis Problem - Final Thesis Project - GYM - Trigger to Door Distances - Toni Winkler


    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.

    Level concept in Miro

    The Three Axis Problem - Final Thesis Project - Blockout Level 1 - Toni Winkler


    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.

    The Three Axis Problem - Final Thesis Project - Gameplay - Toni Winkler

    The Three Axis Problem - Final Thesis Project - Gameplay - Toni Winkler

    Scripting


    Some of the Mechanics I scripted via Blueprints are:

  • The Camera Smoothing Behaviour while taking the player characters orientation in account
  • The pick-up and carry mechanic for the gravity cubes
  • Respawn system for respawn points in arbitrary orientations
  • Separate Respawn Behaviour for Blocks
  • Modular Interaction system to trigger doors, blocks and scalable stairs via pressure plates
  • Level Transitions
  • UI and Settings behaviour
  • 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.

    Gameplay