Project Retrospective & Impact Narrative

Legacy System Extension
Extended an undocumented, 4-year-old boss encounter framework, adding clearer designer-facing configuration to make it easier for designers to work with directly.

Puzzle-Piece Systems Refactor
Refactored an existing, live puzzle-piece system to improve maintainability, and resolved a critical bug in multi-tile piece targeting logic uncovered during this work.

Boss Encounter & Mini-Boss Development
Built a main boss encounter alongside supporting mini-boss behaviors for upcoming late-game content, extending the puzzle-piece systems beyond the current level count.

Test Coverage Introduction
Introduced automated unit tests covering the existing mechanics, boss, and puzzle-piece systems via Unity Test Runner, reducing regression risk for an established codebase that previously lacked test coverage.

Cross-Disciplinary Risk Mitigation
Audited asset requirements early in the feature pipeline to surface technical bottlenecks ahead of implementation, and identified a backend-to-UI data synchronization mismatch, collaborating directly with production and design to realign milestones with core design intent.

Overview

I joined Forestrike midway through production, after many of its core gameplay systems had already been established. Working alongside designers, artists, writers, and engineers on a small, hybrid development team that narrowed to seven by release, my role shifted from feature ownership toward architecture: extending existing frameworks, replacing one-off implementations with reusable systems, and acting as a technical point of contact as the project moved toward certification and release across PC, Steam Deck, and Nintendo Switch.

Production Challenges

By the time I joined, Forestrike's roguelite structure was still relatively basic — the bulk of the system's complexity lived in combat: how weapons, hats, and techniques interacted with each other during encounters. The weapon and hat systems themselves were already established, but as the number of techniques grew, so did the number of possible interactions between all three, and iterating on combat feel meant repeatedly touching that same interaction layer. Run tracking didn't exist yet at all; it was only introduced late in development, alongside the rest of the game's data-driven expansion. The core engineering challenge wasn't managing existing scale — it was maintaining and extending the technique-weapon-hat interaction layer so the design team could keep iterating on combat feel late into production without every tuning pass requiring engineering time, all while preparing a fixed, resource-constrained platform that hadn't shipped on schedule.

Gameplay & Systems Architecture

Encounter Framework: Spawn & Character Introduction

Forestrike's roguelite structure required encounters of varying complexity that designers could author without engineering support for each variation. I built a modular spawn framework supporting multiple spawning strategies, letting each encounter select the implementation appropriate to its region, complexity, and design intent.

On top of that framework, I designed a Character Introduction system providing reusable presentation logic for every enemy encounter — configurable introduction behaviors, map-defined entry points, randomized entrance variation, and integration with both gameplay and cinematic sequencing. Layering introduction logic on top of spawning, rather than duplicating it per-encounter, eliminated redundant setup work across the game and gave designers a single system to extend as new encounter types were added.

Run Results & Progression System

Run-end statistics, progression, and UI presentation had grown into separate, loosely connected pieces of logic. I architected a unified Run Results pipeline built around reusable data structures and designer-configurable statistics, so new gameplay metrics could be added to end-of-run reporting without further engineering changes. The trade-off was more upfront architectural investment in a generic data layer, in exchange for removing engineering from the loop on future metric and progression changes — a system built to outlast any single run-tracking feature it currently supports.

Technique Operations & Proc Order Systems

Techniques didn't exist in isolation — each one hooked into the game's existing weapon and hat systems, and as the technique roster grew, so did the number of ways those interactions could go wrong. Two related but distinct problems emerged as a result.

First, technique modifications — learning, upgrading, and removing techniques — needed to happen safely without corrupting a technique operation already in progress. I designed a queued operations system that processed these changes in order, only after the in-progress operation completed, preventing state corruption from concurrent modification requests.

Second, because Forestrike is frame-animation-heavy, a single technique can proc multiple effects at different points within the same frame — pre-hit, post-hit, and post-resolution. Without explicit ordering, technique synergies could resolve in an order the designer never intended, breaking the intended player experience of combining techniques — and any change elsewhere in the weapon or hat interaction layer risked silently shifting that ordering and reintroducing the same problem. I built a proc order system that enforced designer-intended sequencing across these timing windows, so technique interactions played out consistently frame to frame, matching what designers expected regardless of how many effects were stacked or how often the surrounding systems changed underneath it.

Workflow Improvements

Several of the game's designer- and writer-facing systems existed as one-off implementations that required engineering involvement for every new use case. I generalized these into reusable tooling:

• Narrative Extensions — exposed gameplay systems as functions callable from the narrative system's Lua scripting layer, so writers could drive progression, techniques, and level behavior directly through dialogue scripts rather than requesting gameplay code changes.
• Text Effects Framework — built a reusable system for dynamically communicating gameplay mechanics, status effects, and narrative emphasis, functioning as a shared presentation layer across both gameplay and UI.
• Bark System — developed a system synchronizing dialogue, expressions, and animation for both world-space and UI characters, letting writers construct contextual narrative moments without new engineering work per moment.
• School Theming — built systems letting UI and gameplay elements automatically adapt appearance to Forestrike's distinct martial-arts-school identities, removing duplicated per-school content while keeping visual presentation consistent.
• Menu Development — built many of the game's later UI screens on top of an existing UI framework I didn't own, focusing each on reusability so screens could be composed into larger menus or flows rather than built as one-offs. I converted one-off UI strings into the localization-ready data type used by the team's localization framework, ensuring new menus were translation-ready by default and supporting the game's eventual release in 10 languages.

Each of these traded a larger initial system for the removal of an ongoing engineering dependency — the recurring goal across this tooling was to keep writers and designers unblocked as content scope grew late in production.

Optimization

Nintendo Switch's release slipped behind the PC and Steam Deck launches due to unresolved memory stability issues, and I took on diagnosing and resolving them during that gap. The investigation surfaced two distinct problems.

The first was our own: the replay system was leaking sprite and VFX material memory over time. I traced the leak to its source and cleaned up the underlying allocation and disposal logic, removing it as a factor in Switch's memory budget.

The second was harder to pin down — an inherent material memory leak in the Unity engine itself. I profiled intensively to isolate the behavior, ruling out our own systems step by step before confirming the leak originated in the engine rather than our code. With the root cause identified, the fix came from updating the Unity engine version rather than working around it in gameplay code, avoiding a fragile patch on top of an engine-level bug.

Resolving both issues was the deciding factor in getting Switch to a certifiable, stable state, and the platform ultimately shipped successfully once they were addressed.

Cross-disciplinary Collaboration

Beyond direct system ownership, I acted as one of the team's go-to technical resources in our hybrid development environment. I reviewed code changes, investigated production bugs, and answered implementation questions across disciplines, which let designers, writers, and artists resolve blockers without waiting on scoped engineering time. Within my own systems, I looked for opportunities to generalize one-off implementations into reusable frameworks, reducing how often other engineers or designers needed to route new requests through me. Being embedded in discussions across gameplay, design, art, and production meant issues could often be caught and resolved before they cost iteration time elsewhere in the pipeline.

Familiarity with the codebase and Unity's engine internals also became a specific asset for the team: I was frequently the first point of contact for bugs that looked irrational on the surface but turned out to stem from interactions between separate systems, or between our code and the engine itself. Being able to move across features I didn't own — without needing to ramp up on each one from scratch — let me catch and resolve issues other engineers hadn't had the context or time to trace, freeing them to stay focused on the systems they were building.

Results

The systems built during this period were designed to outlast the specific content they originally shipped with. The Run Results pipeline and Technique Operations & Proc Order systems allow new metrics and abilities to be added without further engineering involvement. The Encounter Framework and narrative/presentation tooling removed recurring engineering dependencies from content creation, letting designers and writers iterate independently. Resolving the Nintendo Switch memory issues cleared the blocker that had delayed that platform's release, ultimately bringing it to a stable, successful launch. Collectively, this work shifted several previously engineering-bottlenecked workflows into designer- and writer-owned processes, while helping bring Forestrike to release across PC, Steam Deck, and Nintendo Switch.

Joined Food Truck Fury just before its soft-launch release, stepping into an already-running production to help carry it across the finish line.

A major focus was the missions system: working closely with the team to finetune exposed parameters so mission pacing and rewards better supported early player retention (FTUE). This meant iterating on gameplay-facing configuration rather than just backend logic, so designers could tune the experience without engineering back-and-forth.

Also heavily involved in UI/UX work, improving overall game clarity and stability, in tandem with the driving minigame and building-shader systems captured in the highlights above.

On the performance side, target-device optimization was a recurring challenge, made harder by a telematics integration that was heavy on power draw. Using Unity's debugger and profiler, tracked down and resolved mobile texture memory issues that were affecting runtime performance on constrained devices.

Overview

BMO's Game Lab was developed as a vertical slice proposed by our studio for Cartoon Network, exploring the concept of a larger user-generated content platform centered around puzzle creation. Rather than delivering a traditional handcrafted puzzle game, the project aimed to prove that both designers and players could build compelling gameplay using the same underlying systems.

As Gameplay Engineering Lead, I was responsible for architecting the gameplay framework that powered content creation, establishing production workflows, and representing engineering in cross-disciplinary planning discussions. My work focused on building reusable systems that could scale with future content rather than implementing individual gameplay features.

Production Challenges

From the outset, the project's success depended on supporting a rapidly growing library of puzzle mechanics while maintaining fast iteration between engineering, design, and art. Creating bespoke implementations for every obstacle or gameplay variation would quickly become difficult to maintain and would slow production as new ideas emerged.

At the same time, the project envisioned user-generated content as a core feature. This required gameplay systems, creation tools, validation workflows, and production pipelines that were robust enough for both internal designers and eventual players.

Another technical challenge emerged during development around transitioning between menus and gameplay. Maintaining separate application flows increased resource management complexity, so we instead consolidated both experiences within Phaser's scene framework, simplifying transitions while allowing assets and resources to be managed more efficiently.

Gameplay Architecture

The foundation of the project was a modular puzzle framework designed around composition rather than bespoke implementations. Instead of creating unique classes for every obstacle, gameplay behaviors were decomposed into configurable components that designers could combine to produce new puzzle mechanics.

This architecture separated gameplay behavior from level definitions, allowing new content to be created primarily through configuration rather than additional engineering work. As puzzle mechanics expanded throughout development, the framework supported more than one hundred distinct puzzle pieces without requiring structural changes to the underlying architecture.

The same design philosophy extended to enemy behaviors. Because the project emphasized deterministic puzzle interactions over sophisticated artificial intelligence, enemies were intentionally treated as specialized moving obstacles. By reusing the same behavioral component system, gameplay rules remained consistent while reducing duplicated logic and simplifying long-term maintenance.

Creator Tooling

To remove iteration bottlenecks, I led development of an in-game level editor that enabled both designers and players to build and immediately test content without relying on traditional build-review cycles.

Moving creation directly into the game significantly accelerated experimentation, allowing gameplay concepts to be validated through rapid iteration instead of engineering intervention.

Supporting user-generated content also required ensuring published levels met a minimum quality standard. To address this, I designed a creator-side validation workflow requiring players to successfully complete their own levels before they could be shared. Beyond validating individual creations, this system established the technical foundation for future community sharing and rating features.

Asset Pipeline & Workflow

Anticipating a large volume of layered artwork, I established production standards governing sprite layout, animation integration, asset organization, and export workflows.

Source artwork followed a structured grid and marker convention that preserved alignment and rendering order throughout the import pipeline. Because these source assets naturally contained large transparent regions, texture packing was incorporated into the workflow to remove unused space while preserving the positional information required by the engine.

Standardizing these conventions reduced graphical integration issues, improved runtime efficiency, and minimized back-and-forth between engineering, artists, and designers by ensuring assets entered production consistently from the beginning.

Technical Leadership

Beyond implementation, I represented engineering during production planning discussions, helping translate gameplay concepts into scalable technical solutions while balancing creative goals against implementation complexity.

I also defined technical constraints for gameplay systems and asset production, establishing shared standards that aligned engineering, design, and art throughout development. These decisions reduced production uncertainty while allowing the team to iterate confidently on new gameplay ideas.

Results

BMO's Game Lab established the technical foundation for scalable puzzle creation by combining modular gameplay architecture, creator tooling, validation workflows, and standardized production pipelines into a cohesive engineering framework.

By shifting content creation from bespoke engineering implementation toward reusable systems and configurable workflows, the project enabled designers to iterate more independently, reduced production bottlenecks across disciplines, and demonstrated an extensible architecture capable of supporting future user-generated content beyond the initial vertical slice.

Holo Dance Studio is an independently developed augmented reality dance application created to explore rapid product development while maintaining a realistic production scope. Originally planned as a two-week prototype, the project evolved into a fully released cross-platform application after identifying opportunities that significantly increased its long-term value.

Project Goal

The objective was to deliver a complete, shippable product within a strict development schedule by intentionally limiting the initial feature set to the smallest viable experience.

The initial scope focused on four core objectives:

• Rigged 2D character
• Dance animation editing inspired by Halfne Miku Studio
• Green-screen background for external video editing
• Windows release supporting both English and Japanese users

By defining a clear minimum viable product before writing code, the project remained achievable while leaving room for future expansion if time allowed.

Engineering Decisions

Scope Management

As the sole developer, every engineering decision directly affected the project's ability to ship.

Rather than attempting to build every planned feature, development prioritized systems that delivered the greatest user value while minimizing implementation complexity. This allowed steady progress throughout the project and reduced the risk of missing the original release target.

Development was divided into several major phases:

• Character creation and rigging
• Asset pipeline
• Animation systems
• User interface
• Persistence
• Platform support
• Publishing

UI and Localization Strategy

One of the larger production challenges was localization.

Instead of maintaining multiple localized interfaces, the application was intentionally designed around animation, iconography, and visual feedback wherever possible. Only a small amount of English text remained for more complex functionality.

This significantly reduced localization overhead while allowing both English and Japanese users to navigate the application with minimal language dependency.

Cross-Platform Save System

Following the completion of the original prototype, the project scope was reassessed.

Rather than releasing immediately, development continued to implement several high-value features that substantially improved the overall product.

The largest addition was a custom save system capable of exporting and importing user performances across Windows and Android versions. The portable save format allowed users to continue their work regardless of platform while keeping the persistence system independent of platform-specific implementations.

Augmented Reality Expansion

The project also expanded from a desktop-only application into a cross-platform experience through ARCore integration.

Supporting augmented reality introduced additional considerations for input, camera behavior, and user interaction while maintaining feature parity with the desktop version. This transformed the original prototype into a more compelling mobile experience without requiring separate gameplay systems.

Publishing and Product Ownership

Beyond engineering, the project provided experience across the complete product lifecycle.

After development concluded, I independently prepared release builds, promotional materials, Play Store assets, and public documentation.

Throughout development I also maintained regular progress updates on Reddit and Twitter, monitoring engagement metrics to refine future posts and better understand how users responded to different aspects of the project. This iterative approach provided valuable insight into product presentation and community engagement alongside software development.

Outcome

Although originally envisioned as a short prototype, Holo Dance Studio ultimately became a fully released cross-platform application spanning engineering, product planning, localization, publishing, and marketing.

The project provided practical experience in making engineering trade-offs, managing scope, shipping independently, and delivering a complete end-to-end product from concept through public release.