
Game
Forgive Me Not
The interesting problem was not any single system, it was making objectives, interaction, combat and enemy spawning composable enough that designers could build levels without asking me for code.
- C++
- Behaviour Trees
- AI Perception
- Gameplay Systems
- Tech LeadSecond lead role
- 6Core systems owned
Forgive Me Not was my second technical lead role. I built the systems layer: the things every other discipline on the team depends on and nobody sees directly.
Enemy behaviour
Enemy AI is built from C++ Tasks and Services running under behaviour trees, fed by a perception system and sharing state through a blackboard. Splitting the work that way matters because Services run on their own tick interval, so the expensive checks like re-evaluating a target do not have to happen at the same rate as the cheap ones.
The behaviours are composed rather than hardcoded. A new enemy type is a different tree over the same tasks, not a new class.
Systems the designers use
I built the core gameplay layer as a set of independent systems:
- Objectives, so a level can define what completion means without touching game code
- Interaction, covering doors, weapons and pickups through one interface
- Health and damage, tracking state and driving the outcomes that depend on it
- Weapons and abilities, sharing the same activation and cooldown handling
- Enemy spawning, exposed to the level designers so placement is a design decision rather than a code change
That last one changed how the team worked. Once spawning was a tool, the designers stopped filing requests and started iterating on encounter pacing themselves.
Feel
I wrote procedural camera animation that responds to what is happening in the game rather than playing fixed shots, and tuned the player movement against it until the two stopped fighting each other. Character animation transitions and the supporting VFX went in alongside, because in a horror game the camera and the animation are doing as much work as the AI is.
Breakdown
