Work

This is a dev-time area generator that lives inside the Godot editor rather than in the shipped game. A designer picks a short declarative JSON recipe, presses Generate, and a full 3D area is built as a live preview under the open scene: rooms, winding tunnels, stairs, gates, lighting and spawn markers. Saving writes a plain .tscn to disk that any Godot developer can open and edit by hand. The tool never ships; the game ships the baked scene.

The core guarantee the client wanted is determinism. The same recipe plus the same seed produces the exact same scene down to node names and transforms, so a designer can generate a base, inherit a copy, hand-tune it, regenerate the base, and keep every override. All layout randomness flows from a single seeded RNG consumed in a fixed order; a separate hash-of-cell-coordinate source drives per-tile art variety, so adding or removing an asset variant changes only that one tile instead of reshuffling the whole map.

The generator is deliberately asset-agnostic. It references no file paths itself: a kit descriptor is the only place asset paths live, so swapping the kit produces a different-looking area from the same algorithm. That split (recipe says what to build, kit says which assets to build it from) is what lets a future biome reuse the whole pipeline with a new asset pack and only a lighting rig in code.

Ultimatum is a competitive 3D platformer built for playing with other people. It ships two entirely separate multiplayer paths: an online mode built on Steam lobbies with host migration through the lobby list, and a local split-screen mode supporting up to four players on a single machine with gamepads.

The project started from an existing third-person controller asset, so the character movement and camera were not mine to write. What I built is everything that turns a single-player controller into a game two to four people can play at once: the networking layer, the lobby flow, the split-screen viewport handling, and the shared state that keeps everyone's client agreeing on who is who.

The awkward part of any networked character game is that animation state does not replicate for free. Position syncs cheaply; whether a player is grounded and how far through a blend they are does not. I keep an authoritative table of animation state keyed by peer, updated over RPC, so remote players animate correctly on every client instead of sliding around in a T-pose.

A 3D tower defense set in a low-poly village. Enemies enter from rotating spawn points and march on the base; the player answers by dragging defender pawns from an inventory onto the map, inspecting enemy stats mid-fight, and spending the gold that kills return.

The wave system is the core of it. Rather than authoring each wave by hand, waves are generated from a small set of exported parameters: surges per wave, base surge size, a growth multiplier, spawn interval, gap between surges, and how many entrances go live each wave. Changing the pacing of the whole game is a handful of numbers in the inspector, and every stage of the sequence broadcasts a signal so UI and audio can react without polling.

Enemies are Resources rather than hardcoded scenes. Each type carries its own stats, economy values, spawn weighting and description text, which is what lets the inspect panel populate itself from data instead of from a switch statement.

ClockWork is a 2D action platformer built around melee combat: a light and heavy attack chain, dash, shield block, parry, and a magic set, all driven through hierarchical state machines for both the player and the enemy.

What makes it more than an HP bar is what each hit records. Every hit also reads how the player is fighting, whether that is brutal, precise, or repetitive, and those readings accumulate in a place the enemy itself cannot reach.

That split is the core of the design. The enemy vessel holds the state of a single life: its composure, its combat pool, how intact its role is, how much the audience favours it. The vessel keeps no memory of its own. A separate persistent layer does that, tracking behavioural patterns across every encounter and pushing the accumulated weight back onto the vessel. A player who wins by mashing the same heavy attack finds the enemy getting faster and more erratic over time, because the game has been reading those habits rather than nudging a hidden difficulty slider.

A single-location survival horror game in the night-watchman tradition: the player sits in an office, works a bank of security cameras, and manages power, doors, and a mask while six animatronics converge on them. I handled the gameplay programming, every system between the main menu and the jumpscare.

The interesting constraint was that no two animatronics could behave the same way. Frednic tracks a gaze meter that drains when he's ignored and fills when he's watched, so both staring and looking away will kill you. Bronnie walks a fixed door route and forces the door at the end of it. Dave rolls one of three approach routes at the start of a run and is stopped by closed doors. Rena escalates through poses on one camera before committing to the window or the right door. The Ambassador occupies several cameras at once and punishes the player for dropping the monitor while she's on screen. Fredbear announces himself with a trumpet, then walks in on a timer the player has to beat with a gaze button.

Because the client needed to tune difficulty themselves, every one of those behaviours reads its numbers from a documented JSON file at startup. Roam intervals, meter drain rates, route probabilities, strike counts, gaze deadlines: all editable in a text file, with inline comments explaining what each value does. Retuning a night is a reload, not a code change.

This one starts from a bought racing template rather than an empty project, so it is worth being precise about the split. The template supplied the vehicles, the circuit, the car controllers, drift smoke, skidmarks, lights and the car select menu. What I built on top is the part that turns a driving demo into something with stakes: enemies that hunt you, objects that break, and resources you can lose.

The enemies run a hierarchical state machine over a navigation agent, moving between roam, chase and search behaviours. Detection is a raycast line-of-sight check on an interval rather than a plain area overlap, with a deliberate delay before a state change commits: without that debounce, an enemy standing at the edge of cover flickers between chase and search every frame.

A compact stealth prototype. The player crosses a walled compound gathering a key and two plane wings, then returns them to a grounded plane to escape. Guard towers and patrolling ships sweep the ground with detection volumes; walking into one is the fail state.

The alert model is what makes it read as stealth rather than as an obstacle course. Detection is not per-guard: a tower that spots you broadcasts to every enemy in the scene at once, and all of them switch into a frenzy state together. Getting seen escalates the whole level, not just the corner you were caught in.