Fluxuate
A 3D hack-and-slash built in Unreal Engine 5, where the player turns the engine's physics against variable enemy types. Team project by Pocket Change Games.
overview
Fluxuate is Pocket Change Games' team project - I'm the Engine/UI programmer alongside a gameplay programmer and
a tools/gameplay programmer. It's a C++-first UE5 project (5.4, blank template, no starter content) versioned in
Perforce, with a full design document, coding standards, and semantically-versioned changelogs from
v0.0.1 on. The game is in development - no release claims here; what follows is the
engineering that exists today.
what I built as engine/ui programmer
- 3-slot save system. A
SaveGameSubsystem(game-instance subsystem) with per-slot save files, slot-selection UI widgets, and persistence for game state - including which enemies you've already defeated. - Game-state flow. The Main Menu → Game → End State loop: game instance and game modes, menu controllers that manage input-mode transitions, pause handling, and win-condition detection.
- UI framework. Main menu, pause menu, end-state, and options widgets built around a reusable
ButtonWithTextcomponent with hover styling - plus audio-settings and music subsystems so volume preferences persist across sessions. - Gameplay and animation systems. Character movement on Enhanced Input, a health component, the enemy base class, weapon animations, health/stamina bars, and a climbing system built with component reparenting.
Case study: enemies that wouldn't stay dead
While building the 3-slot save system we hit a bug where every defeated enemy came back on load - kills were
being written to the save file, but nothing consulted that data when enemies spawned. My fix gave every enemy
a stable ID (set in-editor or derived from the actor name) and added a persistence check in
EnemyBase::BeginPlay(): query the save subsystem, and if that ID is already in the killed list,
destroy the actor before it finishes spawning. Deaths register through the same subsystem
(AddKilledEnemy), so progression finally survives the save/load round-trip. I documented the
whole investigation with a before/after capture - diagnosing across successive builds is the part of this
project I'd bring up in an interview.
process
Perforce over a studio-style depot (checkout discipline, daily submits, changelist tags), a shared coding standard, and a keep-a-changelog file that has tracked every version since the first sprint. Code is available on request - the depot is private to the team.