I Made Something
An autobiographical narrative puzzle game about turning the creative process of this project into mechanics, space, and audiovisual change.
Access Code: gamepoems
Context
2026 | MSc Thesis | Solo Project
Techologies
Unity · C#
Roles
Brand Identity
Print Design
Art Direction
01 | Project Overview
Overview
A systems-driven worldbuilding experiment where ecological balance becomes the player’s primary language.
Design Challenge
Our old identity had grown generic over the years, stitched together from whatever felt fastest at the time. Business cards, decks, and the site all looked like they belonged to three different studios.
Design Direction
We built a tight grid system, a single confident wordmark, and a small set of embossed printed pieces, then applied that same system across every touchpoint so the studio finally looks as considered as its work.
02 | How it plays
MOVE
A systems-driven worldbuilding experiment where ecological balance becomes the player’s primary language.
ATTACH
ANCHOR
Use dock points to commit parts of the body and alter access through the level.
03| Mechanics as Meaning
The game's core mechanics also function as a symbolic language for the creative process, allowing meaning to emerge through interaction rather than exposition alone.
AVATAR
The initial idea from which the process begins.
SEGMENTS
Thoughts and material accumulated while creating.
DOCK POINT
Committing to a decision in order to keep working.
DOOR
A constraint that prevents the idea from progressing.
LOCK POINT
Finalizing part of the process.
04| Puzzle & Level Design
As the game progresses, previously introduced mechanics are combined into longer sequences that require the player to consider both the current state of the body and how committing to a decision changes the available path.
A Moving Dock Point combines the behaviour of a dock point and a door. Docking the body changes which anchoring position is available, turning a previously static interaction into a sequencing problem.
IN PLAY
Within the game's symbolic system, the Moving Dock Point represents tools, ideas, and approaches that may need to be abandoned or repositioned before the creative process can continue.
COMBINING THE RULES — LEVEL 05
Level 05 combines previously introduced rules into a multi-step sequence. The player must collect segments, revisit earlier spaces, and change the state of moving dock points in a deliberate order before reaching the final connection.
05| Narrative Design
The narrative is linear, but its unfolds through play. New lines are triggered by movement, collection, attachment, spatial conditions, or changes in the game state, allowing narrative and mechanics to advance together.
A | A narrative arc shaped by interaction
The experience begins with a simple creative impulse and gradually expands into an overwhelming field of possibilities. Interaction remains relatively simple while the player discovers the basic relationship between movement, accumulation, and thought.
Narrative lines appear directly inside the level and are revealed through movement and simple interaction.
The central chapters turn that impulse into a working process. Mechanics become denser and more repetitive as the player develops a working method, revisits problems from different perspectives, relies on established approaches, and eventually begins to question whether they still work.
During the central chapters, dialogue and gameplay become increasingly interdependent: completing or changing a mechanical state advances the narrative at the same time.
The final chapters deliberately reduce mechanical complexity. Action gives way to distance, observation, music, and reassessment, shifting the player from actively shaping the process to observing and reconsidering what has been created.
In the final chapters, mechanical density falls away. The narrative language becomes more introspective as the player is asked to step back from the process rather than continue shaping it.
B | Action → Text → Meaning Analysis
Rather than treating gameplay as a pause between lines of text, key narrative statements are deliberately tied to specific player actions. The examples below show how gameplay events, writing, and meaning are designed to reinforce one another.
GAMEPLAY EVENT
NARRATIVE LINE
Collecting segments and growing the body
“First, I need to gather my thoughts.”
The player’s growing body reflects the process of gathering and organizing thoughts before beginning focused work.
Docking at the Moving Dock Point
“Maybe I need to base my effort on something else.”
A change in the puzzle state becomes a narrative decision to stop relying on the same approach.
“To see my starting point from a different perspective.”
Progressing after the dock state changes
“Then I can realize I don’t need it anymore.”
What previously enabled progress is no longer necessary, turning the machanic of letting go into part of the narrative.
The abandoned method is not framed as failure; it remains part of the creator’s accumulated knowledge.
06 | Technical Implementation
The project is developed in Unity using a set of interconnected C# systems for player interaction, dialogue progression, puzzle state, music, scene transitions, and localization. The implementation was designed around reusable data and event-driven communication rather than hard-coding each chapter separately.
A | Narrative System Architecture
Data-driven dialogue through ScriptableObjects
Narrative content is stored as reusable ScriptableObject data rather than being hard-coded inside each scene. Every chapter references a LocDialogueSequence, whose individual line entries define not only the localized text itself, but also how and where it should appear, and which gameplay conditions or supporting scene elements are associated with it.
Dialogue progression is event-driven rather than time-based. The DialogueManager advances the sequence in response to gameplay events such as entering a trigger, collecting a segment, docking, or completing a mechanical condition. This keeps narrative progression tied to player action instead of separating it from play.
Because each chapter stores its lines in a LocDialogueSequence, scene logic does not need to hard-code individual narrative entries. The same manager can therefore present different chapters by resolving the data stored in each line and applying it at runtime.
Each line in the sequence stores more than text. Alongside a Localized Text reference, a line can define its spatial anchor, fine screen offset, text box size, typography settings, and related guidance elements such as a hint light. This allows the same dialogue system to control both content and presentation through data.
Some fields are only used in special cases. Text Effect supports specific visual moments, while Music Clip is used by the dedicated manager in the final chapters.. The system therefore remains extensible without requiring separate data structures for every variation.
B | Runtime Body & Docking System
Building and manipulating the player body at runtime
The player’s body is assembled dynamically during play. Collected segments are attached to the avatar at runtime, allowing the body to grow as the player progresses through each level. Docking temporarily shifts the interaction state, turning the current body configuration into part of the puzzle logic.
DYNAMIC BODY CONSTRUCTION
DOCKING AS A SYSTEM STATE
Segments are collected individually and incorporated into the existing chain rather than being represented by a fixed player model. This allows the visual form of the avatar to reflect the player’s accumulated actions while remaining mechanically usable throughout the level.
Reaching a Dock Point shifts the player from free movement into a constrained interaction state. The docking system coordinates body attachment, player control, camera behaviour, dialogue triggers, and interactions with other puzzle elements before returning control to normal movement.
COLLECT
BODY GROWS
DOCK - OPEN DOOR
C | Music, Progression & Synchronization
Original music composed and implemented as part of the game’s progression systems
Rather than functioning as a separate soundtrack, composed music changes role across the game: first as a guided musical sequence, then as a layered accompaniment to active puzzle play, and finally as a tightly synchronized structure where progression depends on the completion of musical parts.
01 — Guided musical sequence
02 — Layered music system
03 — Synchronized narrative progression
(Chapter 00)
(Chapters 01-06)
(Final chapters)
Music is organized as a sequence of separate tracks. Specific dialogue lines trigger the transition from one musical part to the next, allowing the opening chapter to unfold as a guided audiovisual introduction.
In the central gameplay chapters, music is built from layered loops that gradually enter as the experience progresses. Dialogue lines activate or solo specific layers, allowing the arrangement to evolve without interrupting the player’s movement or puzzle flow.
In the final chapters, music becomes structurally tied to progression. Each dialogue segment is linked to a musical part, and the next line is only shown after the currently playing section finishes, creating a tighter relationship between text, pacing, and reflection.
A | Chapter 00 — DialogueMusicController
The opening chapter uses a dedicated DialogueMusicController. It stores an ordered list of full music tracks and the dialogue line indices at which each change should occur. This allows the chapter to behave like a controlled audiovisual sequence rather than a layered gameplay loop.
B | Chapters 01–06 — MusicController01
The central chapters use MusicController01, a layered music system built around multiple looping stems. Individual dialogue lines activate new layers, while selected moments can temporarily solo a layer. This lets the music grow in density alongside the player’s progress while maintaining a continuous flow.
C | Final chapters — MusicChapterDialogueManager
The final chapters use a different manager, MusicChapterDialogueManager, because progression is no longer tied only to input or movement. Each dialogue unit is associated with a music segment, and when the player requests the next line, the system waits for the current musical part to finish before advancing. This supports a slower, more reflective pacing.
Beyond dialogue and music playback, the same manager also coordinates scene transitions, end credits, hint light behaviour, zoom-out movement, and line-specific events, making it a central controller for the final chapters’ audiovisual sequencing.
D | Localization
Supporting English and Greek through the same content system
Dialogue is stored through Unity’s Localization system using LocalizedString references, allowing the same narrative, gameplay, and presentation logic to support both English and Greek without duplicating chapter-specific content.
ENGLISH | ΕΛΛΗΝΙΚΑ
Because localization is resolved at the data level, spatial placement, text effects, gameplay triggers, and dialogue progression remain shared between languages.
07 | Iteration & Retrospective Revision
Later development decisions reshaped earlier parts of the game.
01 — Improving Narrative Readability
Playtesting showed that during the denser puzzle chapters, players could become focused on solving the immediate mechanical problem and overlook the accompanying text. I revised the presentation system so narrative lines were linked to specific points in the level, keeping their spatial direction readable even when the target was off-screen. A pulsing red hint light was added to reinforce the same point of interest.
This also contributed to a broader design shift: puzzle difficulty stopped being treated as an independent goal and was instead evaluated by how well it supported the experiential and narrative flow.
02 — Rebuilding the Opening Around a Shared Space
The first two chapters were originally designed as more isolated spaces, shaped primarily around the paths required by their interactions. As the later chapters established a shared environment for the creative process, this began to feel inconsistent.
I rebuilt Chapters 00 and 01 within the same broader spatial framework while preserving their original interactions. The game could then be experienced as repeated movement through — and transformation of — a common space rather than as a sequence of disconnected environments.
03 — Removing Unnecessary Visual Hierarchy
An early version gave a specific segment a key-like appearance so its function would be immediately distinguishable. In practice, the visual contrast made it feel like a fundamentally different class of object.
For the final version, I reassigned one of the existing segment designs to the same role. Its function remained distinct through context and behaviour without visually separating it from the system it belonged to.
04 — Closing The Loop
Designing the ending also changed the opening. Once the final chapter returned to the real workspace where the project had been developed, I added that same space to the beginning of the game. The experience now moves away from the creator’s physical environment into the abstract space of the creative process, before eventually returning to it.
08 | Outcome & Reflection
01 — What the project became
OUTCOME
I Made Something evolved from an initially puzzle-focused prototype into a short autobiographical game in which mechanics, spatial progression, writing, visuals, and music operate as parts of the same expressive system. The final experience prioritizes the relationship between player action and meaning over mechanical complexity alone.
02 — What I learned
KEY TAKEAWAY
The most important lesson was that meaning did not need to be defined before implementation. Several of the game’s central ideas emerged through prototyping and only became clear once mechanics, narrative, and audiovisual elements began influencing one another.
The project also reinforced the value of revisiting earlier decisions. Later chapters did not simply extend what already existed; they changed how I understood and redesigned previous parts of the game.
03 — What I would improve
IF I CONTINUED DEVELOPMENT
I would introduce structured external playtesting earlier and more frequently, particularly when evaluating the balance between puzzle readability and narrative attention. I would also refactor some systems that evolved organically during production into cleaner reusable components.
