What’s in the game

Overview

This was my year-long extended project where I focused on broadening my Unreal Engine knowledge by building a vertical slice of a third-person RPG. The goal was to design and implement multiple interconnected gameplay systems, iterate through testing, and improve my development workflow throughout the project.

A UE5 vertical slice showcasing core RPG systems: inventory/equipment, quests/objectives, combat, traversal, UI, and save/load.

My development approach

Used blockout/greyboxing to prototype mechanics quickly and validate spaces before investing time into full level work.

Built and tested features in a separate sandbox level, then transferred stable mechanics into the main world.

Worked through iteration: early concepts were adjusted after research and scope review, shifting from a looter-shooter idea to an RPG that would push me into new systems and workflows.

Quest System with multiple quest givers and objective tracking (e.g., open chests, eliminate enemies/wildlife, clear areas). Quest and objective data is stored using structs, with progress displayed via widgets/UI.

Inventory + Equipment Slot System (melee/ranged/armour/shields) built to be scalable using data-driven thinking (data tables/structs).

Combat System including a sword-based attack system using traces (line/sphere) for hit detection, built as an Actor Component so it can be reused on other characters.

Player Stats System tracking Health, Stamina, XP and Level, with XP earned from activities like defeating enemies/opening chests.

Traversal Mechanics including vaulting, climbing, and mantling, prototyped in a blockout “sandbox” level before integrating into the main level.

Save/Load System saving key player and progression data (location, health, ammo, XP/level, active quest, inventory, etc.).

Stealth Takedown Mechanic using Motion Warping to align animations and create a satisfying execution flow.

Technical spotlight: Combat Actor Component

One of the decisions I'm most happy with was building the sword combat logic as an Actor Component rather than directly into the character class. This kept the character Blueprint focused on movement and input, while the combat component handled attack state, trace-based hit detection (line and sphere traces), damage application, and animation signalling independently.

The practical benefit showed up quickly: I was able to attach the same component to enemy characters with minimal changes, rather than duplicating logic. It also made testing easier — I could swap or disable combat behaviour without touching the rest of the character.

​​​​​​​

Technical spotlight: Quest system data architecture

Quests and objectives are entirely data-driven using structs and data tables, with no hard-coded quest logic in the game flow. Each quest entry defines its objectives, required counts, and reward references — the quest manager reads from the table and tracks state at runtime.

This meant adding a new quest was a data entry, not a code change. It's the same principle behind scalable live-service design, and implementing it this way made me appreciate why data-driven approaches matter at scale.