One project, two leadership tracks
Shiftscape was co-led across two complementary disciplines. I owned the game's art and design direction while my co-lead owned programming and technical leadership. We shared production responsibilities, including meetings, milestones, coordination, and overall project direction.
Leon
Game-design direction, puzzle-system development, level progression, mechanic sequencing, art direction, and playtest observation.
Co-Lead
Programming leadership, technical implementation, and engineering direction.
Shared leadership Production · Meetings · Milestones · Coordination
The player moved by moving the world
Shiftscape began with a world-shifting mechanic developed by the team. Instead of navigating through a completely fixed board, players reposition sections of the world around themselves.
The team's initial world-shifting mechanic became my design starting point. As design lead, I focused on understanding the behaviors it created and turning them into a learnable puzzle system.
Players showed us something we hadn't planned
Playtesters surfaced an emergent behavior we began calling circling. Repeated shifts could reposition players around the board. I documented its implications for player movement and used it to analyze what the base system could actually reach.
Repeated shifts let players circle into a different relative position.
An emergent behavior exposed a systemic constraint
I created these maps to trace how shifting changed the player's relative position. They revealed a repeating pattern: some cells could be reached through the base movement rules while others inherently could not.
The analysis turned an observed behavior into a design constraint. Instead of treating unreachable spaces as accidental problems, I could see where the system needed new possibilities.
Observation → Model → Design response
New mechanics expanded what shifting could do
Accessing positions the base system could not reach
I created Jump Tiles to open routes into positions that the original shifting rules left inaccessible.
Treating the world as a repeating spatial structure
Looping lets shifted space continue across the boundaries of the level, effectively connecting opposite edges.
I designed the mechanic so later puzzles pushed players to think about the world as a repeating spatial structure rather than a fixed board.
I wasn't placing every tile. I was shaping the learning curve.
Level implementation was collaborative. My responsibility was the broader experience: how maps should feel, when mechanics appeared, what each stage should teach, and how complexity escalated as those mechanics began interacting.
Initial participants → core contributors by the end
The team changed faster than the design did
Shiftscape began with roughly 70 students involved across disciplines. Over seven months, academic workload, changing interest, motivation, and loss of project continuity reduced participation to a core group of roughly 10.
As Co-Lead, I helped keep production moving through recurring meetings, milestone planning, and cross-discipline coordination while continuing to own the game's art and design direction.
Our original vision was also larger than what the remaining team could realistically finish. Keeping the core puzzle experience playable became more important than preserving every planned system.
One of our student-development meetings during the project.
Three dedicated playtests, then WreckCon
We ran two milestone playtests and one final playtest before showcasing the game at WreckCon 2025. Roughly 50 people played Shiftscape across those three sessions and the WreckCon showcase.
These sessions weren't only end-stage validation. Player behavior actively changed how I understood the puzzle system. Circling became important because players discovered it before we had fully formalized what it meant for level design.
One of three dedicated playtesting events during production.
What I learned from Shiftscape
The strongest part of the project was treating unexpected player behavior as design material. Circling wasn't something I introduced, but documenting it led to the reachability model and helped shape the mechanics and progression that followed.
Our original vision extended beyond the puzzle stages into a larger hub, quests, and connected world structure. I would define the smallest complete experience much earlier and treat broader systems as extensions rather than dependencies.