GAME DEVELOPMENT · PUZZLE DESIGN · UNITY · C#
A myth-inspired 3D adventure game developed by Gaucho Game Lab. As Puzzle Lead, I designed and implemented systemic puzzle mechanics and mechanic-driven levels in Unity.
01
My work on Odysseia focused on designing reusable puzzle systems that could grow in complexity while remaining readable to the player.
I developed the mechanics, implemented them in Unity, designed levels around their interactions, and collaborated with the art team to improve visual communication and puzzle readability.
MY CONTRIBUTIONS
02
The tidal system turns the environment itself into part of the puzzle.
Water levels rise and fall with the game's day–night cycle, dynamically changing which routes are available to the player.
During ebb tide, previously submerged spaces, objects, or routes can become accessible. During flood tide, rocks and reefs can become submerged, opening paths that would otherwise be blocked.
The design shifts the player's reasoning from simply asking“Where should I go?”to also asking“When should I act?”
03
A time-driven environment creates an obvious design problem: waiting is not an interesting puzzle interaction.
To solve this, I implemented aTime Acceleration System that allows players to deliberately advance the day–night cycle.
This gives players agency over environmental state. Tides become something they can actively plan around and manipulate rather than something they simply wait for.
04
I designed the light system around progressive complexity: introduce one understandable rule, then repeatedly expand what that rule can do.
At its foundation, light travels from an emitter to a receiver. From this simple interaction, the mechanic expands into a larger system.
A light source activates a receiver.
Relay nodes turn activation into path-building.
White light splits into RGB channels.
Channels recombine into new color states.
Color constraints create selective routing.
Relay nodes allow beams to be redirected across the environment. This transforms a simple activation mechanic into a routing problem, where players construct a path between multiple objects.
Prisms then split white light into red, green, and blue channels, introducing branching paths and dependencies between simultaneous signals.
At higher complexity levels, beams can be filtered or recombined. New puzzle challenges therefore emerge from combinations of rules the player has already learned.
05
The Minotaur's Labyrinth explores how a single puzzle system can shape the structure of an entire level rather than just an individual room.
Maze design creates a tension between exploration and guidance. A short solution path may cause players to skip much of the space, while a long forced route can make the maze feel overly linear.
I used light dispersion as the structural backbone of the labyrinth.
White light is divided into red, green, and blue routes, naturally separating the maze into three major regions. Each region contains a focused set of puzzles with enough depth to reward exploration without forcing the player into one excessively long path.
Cross-region interactions reconnect the spaces. A beam originating in one region can become necessary for solving a puzzle in another, encouraging players to understand the labyrinth as one connected system rather than several isolated rooms.
Persistent beams also become a form of environmental communication. Solved routes remain visible in the space, allowing the level itself to record progress and suggest unexplored possibilities.
06
The light puzzle system was implemented in Unity using C# with a modular, event-driven architecture.
One of my main implementation goals was to separatelight propagation frompuzzle reactions.
ARCHITECTURE
Light receivers emit activation and deactivation events instead of directly controlling gameplay objects.
Independent components can respond by opening doors, activating secondary beams, rotating objects, or triggering other gameplay behavior.
This keeps the core light system independent from the specific objects that react to it.
EXTENSIBILITY
A shared LightReceiver implementation handles common behavior such as light dependencies, color aggregation, activation state, and downstream propagation.
Specialized receiver types extend that behavior only where a mechanic requires different interpretation of incoming light.
LightReceiverShared receiver logic for incoming light, activation, and propagation.
FilterLightReceiverSelectively passes color channels to support filtering-based puzzle constraints.
SpecificLightReceiverActivates only when incoming light matches a required target color.
07
The project taught me to design game systems across multiple scales — from reusable C# components to puzzle rooms and whole-level structure.
The light system demonstrated how a mechanic can gain depth through combinations and extensions, while the tidal system explored how changing environmental state can create another dimension of reasoning.
Working as part of a larger team also required clear communication across disciplines so that gameplay logic, level design, and visual presentation supported the same player experience.