← Back

08

ARPG-MMO (in development)

An ambitious solo project I'm using to push my AI-assisted development workflow as far as it will go, building a full ARPG-MMO in Unreal Engine 5.8 to see how far AI can take one developer. Under the hood it's real systems engineering: data-driven C++ architecture, a FastAPI and PostgreSQL persistence service consumed in-engine, and networked movement with client-side prediction. Private repository, but a live demo is available on request.

Unreal Engine 5C++GASFastAPIPostgreSQLNetworkingUMG
ARPG-MMO (in development) screenshot 1
Overview

This is a low-poly, stylised ARPG-MMO I'm building solo in Unreal Engine 5.8, and I took it on for a specific reason: to challenge myself with a project far beyond typical solo scope and push my AI-assisted development workflow as hard as I can, to see how far AI can genuinely take one developer. It's a game rather than a web app, but the bulk of the work is software engineering that transfers directly: a data-driven, modular C++ architecture, combat on Unreal's Gameplay Ability System, a separate FastAPI and PostgreSQL backend for player persistence consumed in-engine, and networked movement with client-side prediction. The mob combat pass is complete (data-driven AI with patrol, telegraphed and dodgeable heavy attacks, death, and a custom foot-IK animation node), and player combat is the next milestone.

The problem

I wanted a deliberately hard, sprawling project to stress-test how I work with AI, something that would force me to direct AI tooling across many unfamiliar domains at once: C++ gameplay systems, animation, networking, and backend persistence. An MMO is a large systems problem before it is anything else: it needs shared, reusable code that scales to many classes, abilities, mobs, and items without duplicating logic per instance, plus a real backend to persist player state and a networking model that stays responsive over latency. The goal was to build those foundations properly with AI in the loop, rather than script one-off behaviour I'd have to rewrite later.

My approach

The architecture is data-driven throughout: shared C++ base classes plus data assets define classes, abilities, and mobs, so new content is authored as data rather than new code. Combat runs on the Gameplay Ability System in C++, and player persistence lives in a separate FastAPI and PostgreSQL service, consumed in-engine through a custom C++ UPersistenceSubsystem that saves and loads player state. The UI is pure C++ UMG (spatial inventory, equipment and stats panels, HUD, talent tree, and the menu and character-creation flow, with no Blueprint UI), and the loot loop runs end to end from kill to interact to loot window to bags.

Key decisions

The key decision was to favour modularity over speed early: shared base classes and data assets rather than per-instance duplication, so each new mob, class, or item is a data change rather than a code change. For networking I used Unreal's Character Movement Component for client-side predicted movement and validated it in networked Play-In-Editor; a full dedicated-server build needs a source-built engine, so I've deferred that and test replication in networked PIE for now. On animation, creatures without Mannequin IK bones couldn't use the standard foot placement, so I wrote a bespoke AnimGraph node to drive foot IK rather than reworking every skeleton.

What I learned

The biggest thing this project is teaching me is how to work with AI at scale: directing AI tooling effectively across a large, multi-domain codebase, breaking ambitious features into pieces a model can genuinely help with, and staying the architect who reviews and integrates rather than offloading judgement. Technically it has stretched me well beyond web work, into a data-driven C++ architecture that stays modular as scope grows, the Gameplay Ability System, and reasoning about replication and client-side prediction under latency, while the FastAPI and PostgreSQL persistence service wired into the engine through a subsystem is the most directly transferable piece. It has also taught me to be honest about scope: it's solo and in active development, not released, and I've prioritised getting the underlying systems and my workflow right over rushing features.

PreviousTaskFlow