Back

Minotauruss

A retro-inspired first person dungeon crawler with a defined centralized goal, that every mechanic and addition works towards achieving.

Solo Project
Made to practice working with the MDA framework and Design by Subtraction. I made everything myself, except for the main brick/wall texture.
2026
1 week of development.
Never released publicly.
Godot
Notion, Aseprite & Krita.
Summary & Overview
Minotauruss was a quick personal project I finished in a week, by deliberately spending plenty of time upfront on planning and pre-production I managed to very quickly and efficiently create a game that achieves what it set out to do; disorientate and overwhelm the player at first, and then gradually transform that feeling into a rewarding sense of mastery as they play.
I put this game together as part of a freeform 10 week school term. After creating a variety of other prototypes and tech-demos that had potential, but no focus, I wanted to try the exact opposite approach, bringing structure to my scattered process. Learning to work with and understand this design philosophy ended up being the one thing I'd dedicate the entirety of the term to, and I feel like I've massively grown as a designer because of it.
A screenshot of the game.
Pre-Production
Something I wanted to prioritize with this project in particular was a concrete scope and vision, especially coming off of the back of a few smaller prototypes that got nowhere. This time, I'd plan out exactly how the game would work and feel from the start, where possible. I think this worked well for a project of this size, and I've since working on this been quite successful in getting my design goals straight.
I fully put the focus on getting the "Aesthetics" (User Experience) right, after which I wrote out the gameplay and mechanical systems in a separate document.
The MDA Framework
I didn't want to adhere fully to the (rather archaic) MDA framework, instead using it more as a structural suggestion.
What I wanted to get out of it was starting with the game's intended user experience, after which everything else would be made to reinforce this goal. I took inspiration from Fumito Ueda's Design by Subtraction approach in this, and spoke about it with HKU design-teachers throughout the term, who helped me grow further in this.
Scope & Research
To ensure I'd be able to actually achieve my intended goals within a reasonable time-frame, I heavily limited my scope and researched other games and media that incite similar feelings of oppression and confusion, such as Sokpop's Grunn or UFO 50's Barbuta.
This left me with just four possible outcomes/endings for the game, with a simple structure and order to them. which ended up being quite feasible, while still providing enough content and puzzle solving gameplay. This is also padded out by the challenge of avoiding the Minotaur itself.
The endings written out in Notion.
Here's the very first sketch I did of the complete puzzle, simplified heavily.
Here's another part of the Notion document I wrote out.
Sketching out a Dungeon
I sketched out the entire dungeon layout on paper after just a tiny bit of in-engine prototyping and planning out the puzzle, after which I could get started on building out the full maze right away, which made the rest of the design and development process a lot simpler.
This is the first area you explore. In the final game I played with color coding to visualize the separation of different sections.
Here's the final version of room C! At an angle the player would never see in-game.
Reinforcing the Intended UX
By defining so clearly what the game was aiming to achieve it made deliberating design decisions a lot more straightforward.
An few examples in the final game are the intentionally archaic movement scheme that takes away player agency by limiting rotations to 90 degree increments, or the lack of any direct guidance/tutorialization.
A contextual, "hidden" button prompt.
"MAKE AN OFFERING".
Here's the movement system, note that you have to stop moving to look down.
Developing a Minotaur
The Minotaur serves as a constant looming threat, one that roams the halls of the dungeon seemingly randomly, here's a look behind the curtain.
Walking into a room with the Minotaur.
Connecting Halls
I separated each room with doors, this reinforced the idea of never knowing whats waiting for you after the next loading screen, and this created constant tension.
I also used the separation of rooms to disorient the player, by showing empty black space where other rooms were, leading to a non-euclidean feel.
Doors
I built the whole scene switching system with the minotaur in mind, so that the player and the minotaur could use the same data as for which maps connect to each other. My top-down map was invaluable throughout this.
Room "CX-KNIFE" with just one exit.
Room "CX", which the door in the other image connects to.
A close-up of these two rooms on paper.
Mystery in Minotaur Movement
The Minotaur's movement system is pretty simple, he randomly switches rooms when the player does, this led to a few weird edge-cases when the Minotaur was trying to leave a room you were trying to enter, but I managed to work out most of the kinks through extensive debugging.
The room the minotaur always starts in, note the broken shackles.
Prediction and Consistency
Through experimentation it was possible to predict the first few of the Minotaur's moves, as you could figure out where he starts by paying attention to decorative elements and his movement pattern.
I enjoyed the thematic implications of brains over brawn, and it fit the intended UX of slowly gaining a feeling of mastery of well, which let the player outsmart the Minotaur with time and knowledge.
Playtesting
While small in scope and ambition, I still wanted to get the game in the hands of a few players. Only through testing can you confirm whether or not your design goal and intentions have been achieved.
What went well?
Players enjoyed slowly figuring out the layout of the labyrinth, and the main puzzle ended up being intuitively solvable through well-placed landmarks and memorable set pieces, such as the Altar of the Crow.
The game also felt pretty complete for what it was, by virtue of having time to add a few simple menus.
The Altar of the Crow.
The character select screen.
Getting away from the Minotaur.
The death-screen I drew.
What could have gone better?
The Minotaur was still too complex to figure out for most players, with slight 50/50 randomness not feeling consistent or predictable. I made the Minotaur quite fast and punishing to ensure the feeling of tension was never lost, but this led to encountering the Minotaur feeling like a random and somewhat unfair loss, instead of a worthwhile challenge you could feasibly learn to overcome.
Did I achieve my design goals?
Not everything I tried ended up working right away. The general sense of uncovering the labyrinth and slowly learning about it's layout and items worked, but the Minotaur was overtuned in difficulty, which felt incomprehensible and frustrating.
What did I learn?
I really valued having well-defined design goals and a solid intended user experience. This led to my playtests leaving me with obvious points of improvement for a possible second iteration, that would then get me closer to the experience I was aiming to create.
I'm also very happy with being able to test the game after just a week of work. Going forwards I'm going to continue this efficient way of failing fast, in a similar vein to how Valve playtests every week.
Post Mortem
A close-up of the character status image, his pinky is bleeding.
This game is still in a pretty rough state. Due to the rather strict deadline I put on myself of just one week the game is lacking any audio and the visuals are pretty rough, the wall brick texture was ripped directly from Barbuta, the Minotaur itself is lacking a model and his code is still somewhat jank. Despite my best efforts, I couldn't iron out all of the bugs in his movement logic, and I'd probably end up refactoring the whole thing if I ever find the time.
I currently don't really plan to ever fully finish and release this project in particular. I think it holds value artistically, and for fans of similarly obtuse puzzle games, and I might end up making something like it again sometime, but for now I'll let the Minotaur rest, taking only the design philosophy I learned along the way.