After releasing Dawngeon in high school, I started Overdawn as a solo project. The game iterated for years, starting as a PvP game and slowly finding its identity as a bullet-hell, bullet-time shooter. When I came to USC, I brought the game with me and started assembling a team of people who shared the vision. Recruiting wasn't easy, but through game development clubs and networking events, the team grew to 20+ programmers, artists, designers, and writers. As the director and lead engineer of Overdawn, I'm grateful every day for the people who keep this game alive.

None of it would exist without countless all-nighters with teammates who became my close friends.

• Director — 20+ person USC team, shipped on Steam
• Designer — quests, skill tree, sequence system
• Artist — HUD, inventory, and skill-tree UI
• Programmer — Unity / C# architecture, tools, AI

With a team of 30+, the architecture had to let distinct game systems — controls, level management, quests — grow in parallel without stepping on each other. That was my goal from day one.

Scenes: I built a central SceneManager that handles transitions, async loading and unloading, and a PersistentGameplay layer that survives scene changes.
State: A singleton GameManager owns the high-level game states, Main Menu, In-Game, Paused, Game Over, and the transitions between them.
Events: I connected everything through a decoupled event bus, so systems can talk to each other without coupling their lifetimes. This same backbone powers the sequence system.
Persistence: A save/load layer retains player choices and progression across sessions.

Designing Architecture

In-Game Console

I built an in-game console early in the project because I knew the cost of bad debugging compounds over a 3-year project. It lets us execute commands, inspect variables, and edit game state at runtime.

Custom Unity Editor Tools

I built a suite of designer tools on top of Odin Inspector. The custom Painter lets designers paint terrain and props directly onto our 2.5D levels, and the Scene Switcher and Scene Behavior pair lets them manage transitions and per-scene logic without ever leaving the editor.

Quests

I built the quest system covering objectives, progress, and rewards across main quests and optional side objectives. Quests are ScriptableObjects, so designers can author and iterate on them without writing a single line of code. Everything is bound directly to the UI, so players always get clear, immediate feedback.

Cross-Scene NavMesh

Unity ships with basic pathfinding through NavMesh, but Overdawn's async, multi-scene levels needed much more. I indexed each scene with valid navigation points and built a NavigationManager that calculates paths across scenes using BFS, so NPCs and enemies can move through the world regardless of scene boundaries.

This same layer powers the transportation system that subways and elevators run on. It switches based on the player's currently active NavMesh, which determines which scene's behavior is active at any moment.

Three Rewrites to Get It Right

The sequence system is event-driven for modularity, and dialogue runs through Yarn Spinner. Getting the authoring right, though, took me three full rewrites:

v1: I started with a simple GameObject-based system, which quickly became unmanageable as sequences grew.
v2: Then I built a graph with XNode for visual scripting. It was better, but Unity's IMGUI made it slow and unfriendly to use.
v3: I finally landed on Unity 6's Behavior Tree. It was originally meant for character behaviors, but the model fit our actor-centric authoring far better — and designers finally gained real flexibility over individual actions.

An Expandable Actor Hierarchy

I built the player from the ground up — responsive movement, combat, and interaction. The actor class hierarchy is designed to be extended, so new behaviors land as subclasses without ever touching the player core. I also wrote a custom animation layer that drives our 2.5D characters across multiple camera angles, with the object structure tuned for the dense interactions a bullet-time shooter demands.

Weapons

I designed the weapon system so that adding a new weapon is cheap. Projectiles share an object pool to keep performance steady and allow multiple behaviors such as homing, bouncing, and AoE to stack naturally. All damage flows through an IDamageable interface, which keeps the health system decoupled from any particular weapon.

AI (Enemies)

I designed and implemented multiple enemy archetypes, each with its own attacks and decision logic. A Behavior Tree drives their moment-to-moment choices, while the FOV system and take-cover behavior add just enough depth that combat never collapses into a shooting gallery.

HUD & Inventory

I designed and built the health, ammo, and inventory UI, plus the surrounding chrome that ties the rest of the interface together. My goal was simple: the player should always know what's going on without ever having to stop and read.

Skill Tree

I developed a skill system and designed the skill-tree UI, which adds depth to the gameplay.

As a designer, programmer, artist and director of this project, I've made so many mistakes. I was overly ambitious, but I could do so little. Through this process, I learned what it is like to take responsibility, trust and collaborate with my teammates, and the nitty gritty of indie video game publishing and marketing. The game is playable right now on Steam. Feel free to check it out and wishlist!