Introduction

Recursion was built as both a capstone project and a personal exploration of themes that have always fascinated me: bureaucracy, control, and the powerlessness of the individual in the face of a larger system. Across four sprints — roughly three months of development — the process became as much about understanding my own working patterns as it was about systems design.  

This post isn’t a feature breakdown (those have been covered in the dev logs). Instead, it reflects on process: what worked, what didn’t, and what I took away from it.

The below video displays the evolution of a few key spaces within the world of Recursion - from greybox to demo.

Foundations & the Vertical Slice

From the outset, I had a clear vision. I wanted:

• Diegetic interaction (minimal UI, no HUD)
• Latent freedom (the illusion of autonomy, punished as much as rewarded)
• Environmental storytelling (players uncovering fragments, never a full picture).

Greyboxing was where the project’s identity began to solidify. Leaving dev notes scattered across empty rooms became a natural part of my workflow — short phrases like “console wall here” or “cubicles repeating” turned into seeds for mechanics later.

Not everything stayed. A physics gun/device was tested, but it gave players too much power, undercutting the central theme. Cutting it was one of the first decisive choices, and a reminder that subtraction often sharpens focus.

Sprint Patterns

Sprint 1: Overengineering and Early Scope Creep

I began with technical groundwork: triggers, flags, and even a save/load system. The latter was unnecessary for a vertical slice, but it gave me comfort because it provided structure.  

Reflection: My instinct leans toward over-preparing. The lesson here was simple: sometimes ‘good enough’ beats ‘engineered perfectly.’

Sprint 2: Creativity Meets Burnout

This sprint coincided with real-world challenges (Covid, performances, stress). My response was to overproduce — modelling props, experimenting with a suitcase inventory system, and pushing lighting/shadow systems.  

Reflection: When stressed, I noticed I build more than necessary — almost as a way of reassuring myself with visible progress. Playtest feedback, however, pulled me back. Signage was added, onboarding improved, HR systems refined.  

Sprint 3: Balance Through Variety

Here I found a better rhythm. Coding systems (responsive cursors, regex console colours) sat alongside world-building (employee stats, material passes). That alternation between technical and creative tasks helped sustain momentum.  

Reflection: Some scope creep slipped in (keypads), but by tying them back into production later, they felt less like distractions and more like natural extensions.

Sprint 4: Focus and Deliberate Choices

Time pressure forced discipline. Every addition was intentional: WorldIterationManager, archive puzzles, occlusion fixes, layered audio, menu polish. Scope creep was no longer an option.  

Reflection: Constraints clarified priorities. What felt overwhelming earlier became manageable once there was no choice but to focus. This sprint ended up being the most satisfying.

Working Habits: The Good and the Bad

• Dev Notes as Breadcrumbs: Scattered notes in-scene worked – they turned greyboxes into evolving design documents

• Over-engineering: I repeatedly built systems too early (save/load, inventory) that were later cut or shelved. Comforting at the time, but a drag on progress.

• Scope Creep: Printers, scanners, keypads, inventories. I am easily tempted by shiny features, but the real skill was learning to cut them.

• Task Variety Sustains Energy: Alternating between technical systems and creative modelling and world-building kept me from stalling. I hated being stuck on a problem for too long.

• Focus Under Pressure: Deadlines forced me to cut ruthlessly. Without them, I tend to wander. Recognising this pattern is vital for future projects.

Themes and Cohesion

Despite the detours, the central systems converged on one theme: the player is powerless.

• Cutting powerful tools (physics gun, over-helpful sticky notes) reinforced this.
• HR sabotage, misleading terminals, and surveillance pushed back against player autonomy.
• Environmental design (lights, fog, sound) frames the world itself as an oppressive force.

What began as scattered mechanics eventually aligned into a coherent statement, because I kept asking: ‘Does this make the player feel smaller, less in control?’

Conclusion

Recursion’s development was less about accumulation and more about refinement through subtraction. I over-engineered, strayed and let scope creep in – but I also learned to cut, refocus and build systems that served a single unifying idea.

The clearest pattern in my work is this: I expand ambitiously, then carve back to essentials. The challenge moving forward will be learning to shorten that loop – spotting distractions earlier, focusing sooner.

Even so, the journey was worthwhile. Recursion became more than a demo: it is both the sum of experiments, overbuilt systems and cut features, and a record of my own growth – both as a designer, and as someone learning how to better manage themselves.