Work

Klaus is the client's own game, an adventure drawn entirely by hand in a loose ink style. I came in with a working prototype and a folder of animation the character had been drawn performing but could not yet do, and my job was the gameplay layer underneath: make Arthur move the way the art says he moves, and give the world enough furniture that a level designer can build with it.

The player was one 352 line script when I started. I took it apart in stages that were each safe on their own: fix the outright bugs first, then restructure without changing a single behaviour, then split the file into component nodes, and only then hang a LimboAI state machine over the top. By the end there is one state per control mode, sitting, walking, frozen for a cutscene, climbing, vaulting, on a ladder, crouched, mid stomp, and the rule that only the locomotion state moves the body, so every other state freezes Arthur simply by not doing that.

The hardest part was not the states, it was the art. The climb and vault clips were each drawn on their own canvas, against whatever obstacle the artist had in mind, with the character wandering around inside the frame. None of that lines up with a real fence in a real level. So I wrote ArtMotion: it measures the drawing's own translation, cancels it frame by frame with a sprite offset, and hands the movement back to the state to reapply against the actual obstacle. The artist's timing and shape survive; the distances come from the level. It also runs the playhead itself rather than letting AnimatedSprite2D do it, because a sprite that advances on the render frame is a coin toss when you read it from physics, and every mismatch is a visible twitch.

The rest is level furniture, written so a designer can place it and walk away: a ladder that is only a collision shape, a fence that also swaps its own art in front of and behind Arthur as he goes over it, a floor that breaks under a pushed object but not under a man, a camera that a level can borrow for an establishing shot or a bounded zone and always gets handed back exactly as it was.

Desvelado is the client studio's own game, already out on Steam and Android. I was hired for the ring around it rather than the game itself: getting an iOS build out of Godot and onto TestFlight, adding a lives economy the client could tune without shipping a build, and working out why Firebase, in app purchases and ads all behaved in the editor but not on a real device.

Godot cannot produce a signed .ipa without a Mac, so the build runs on Codemagic. The workflow pulls Godot 4.6.3 and its export templates onto a mac mini runner, imports the project headless, exports an Xcode project, runs CocoaPods when Godot emits a Podfile, fetches signing files through an App Store Connect API key, builds a signed .ipa and uploads it to TestFlight. Nothing secret is committed: the .p8 key and a generated RSA key live in a secure Codemagic variable group, and the workflow creates or fetches the distribution certificate itself.

The most valuable hour on the job went into proving where Firebase actually broke. In the editor it signed in against the client's live project and completed a full save round trip. On the phone it printed one line: "Unable to read Firebase config". The addon reads its credentials from a plain .env file, and Godot's exporter only packs files it recognises as resources, so that file never made it into the build. No sign in meant no cloud save, which is exactly why progress looked like it reset on device, on both Android and iOS. Renaming it to firebase.env and adding *.env to the non resource export filters on both presets fixed it without a line of code changing.

The lives system is the one piece of new gameplay. A life is spent on each death; at zero the game offers a rewarded ad that refills to full or a trip back to the menu. Lives also come back on their own against a wall clock deadline written into the save, so the timer keeps running while the app is closed and is checked again the moment the app returns to the foreground. Maximum lives, the refill interval and whether the system is on at all are read from Firestore, so the economy is retuned from a console rather than a release.

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.