Unity 2D action-game engineering
We build the parts of an action game that are painful to retrofit: a character
controller with the feel already in it, combat with real hit windows and hitstop,
enemies with readable tells, and a front end that works on a controller from the
title screen down.
Proof
Sentinels of Gleamwood, built in Unity 6 on 2D URP. A hand-rolled raycast character
controller with one-way platform masks and an explicit commanded-versus-actual
velocity contract, a custom URP sprite shader with flash and slice effects, a
custom PlayerLoop tick system, and nine data-authored enemies.
Unreal Engine C++ gameplay and AI
The same work in the other engine. Player pawns and controllers, enemy AI that
reads clearly to the player, and the director-level systems that decide what shows
up and when.
Proof
Codename: Shifter, Unreal Engine 4.27. Our own contributions there are the player
pawn and its controller, a custom AI movement component, the AI controller on top
of it, a combat director, and the encounter subsystem with its spawn points.
Behaviour trees drive the enemies, with custom tasks, services and decorators, plus
weight-based swarm evaluation and a shared target distributor. Shifter was built by
a team, so this is the part of it we wrote.
Procedural generation you can prove is playable
The hard part is not generating a level. It is generating one that never strands a
player behind a jump they cannot make. We build generators as pure functions of a seed so
bugs reproduce, then verify the output against the real movement numbers instead
of hoping.
Proof
A level's layout is a pure function of seed and node, so a suspended run
regenerates rather than serialising geometry, and the generator unit-tests with no
scene loaded. The reachability auditor floods a state space of position,
vertical velocity and dash cooldown, sweeping the shipped collider box and reading
every constant from the live player settings asset rather than from code defaults.
Two separate gates: every shipped room is proved traversable under that model, and
a 200-seed sweep over a four-path layout built from the shipped room pool returns
four distinct paths every seed, zero overlapping rooms, and a room count inside the
designed 28–41 band on better than nine seeds in ten.
Systems your designers can tune without a programmer
If every balance change needs a build, your designers are queuing behind your
engineers. We author behaviour as data and generate the editing surface from that
data, so tuning is a slider or a text edit rather than a ticket.
Proof
Every enemy is a state machine authored as ScriptableObject sub-assets. Six of
nine shipped enemies needed no new code at all. The run web, all ten biomes and
every boss live in one text file that imports with validation. A typo raises an error
and leaves the field on the value it already had. Scene-view hitbox
handles are drawn through the exact method the combat code scans with, so the
preview cannot drift from the game.
Modding and player-authored content
Community content is a retention feature and a support liability at the same time.
The difference between the two is whether the safety was engineered or hoped for.
Proof
Five override tiers as plain text beside the executable. Levels authored as ASCII
room files, with the engine deriving footprint, door sockets and reachability from
the drawing, then auditing it on the player's machine where no editor exists.
Clone-never-mutate at two levels. Save slots bound to a campaign at creation, so
cross-campaign corruption is impossible rather than unlikely.
Steam release engineering and build automation
The last ten percent of shipping is depots, launch options, and being able to say
which commit a build came from. We have that wired, and we've run it twenty-one
times.
Proof
A real SteamPipe pipeline: templated VDF and a PowerShell upload driver with a
preview dry run. The build description is stamped
with the git SHA so any upload traces back to a commit, and the executable name is
pinned so a marketing rename can't break the launch option. In-editor build manager
with semver bumping, git capture and build info baked into the player.
Tests, validators, and a handover you can use
We write tests for the parts that are expensive to be wrong about, and we make the
build refuse to compile when the content is broken. When the contract ends you get
documentation written for whoever arrives after us.
Proof
58 play-mode test files on their own assembly definition, covering the hard parts:
state-machine golden sequences, kinematic physics, generator determinism,
reachability, save isolation and mod loading. Two content validators, one of which
throws a build exception, so an unreachable room or a broken run web cannot be
built. Plus a multi-page wiki whose tool screenshots regenerate from the real
editor.
