My Contributions

My biggest takeaway from this project is one I keep being reminded of: communication is the most important factor in a project's success. Our non-programming team members often had no idea what the designers were changing about the game concept, which created constant friction. Still, we delivered — and I built two systems I'm quite proud of.

Save and Load System

The team needed two things: a checkpoint respawn system, and the ability to close the application and continue a run from where you left off. I designed a layered save architecture around a UGameInstanceSubsystem that wraps Unreal's USaveGame machinery. At startup it restores player and world state and kicks off an autosave timer. All runtime state lives in plain DTO structs (no behavior attached), organized into a logical hierarchy from per-entity data all the way up to the full save file. The subsystem exposes a clean interface for saving and loading, with multicast delegates so other systems can react to state changes without tight coupling.

Spell System

The spell system is data-driven — all numbers, VFX, sounds, and materials live in Unreal Data Assets that designers can edit without touching code. At runtime a lightweight manager spawns the correct projectile actor based on a spell enum. On collision, the projectile is replaced by a spell effect actor that runs the final logic: FireBall, BlackHole, ShockWave, and Gravity, each exposed as a BlueprintCallable so designers could hook in damage graphs that existed only in Blueprints. I would split the SpellEffect script into per-spell components if I were doing it again — it grew a bit long.

Technical Support

I acted as the team's designated support contact for Unreal and Perforce issues, so nobody stayed blocked for long when something went wrong. This consumed a fair amount of time — Perforce workspace issues were a recurring theme — but I think it was a net positive for the team's momentum.