Technical Designer · Combat
Turn-Based Combat Plugin
A Persona-style turn-based combat system another developer can drop into their own UE5 project. Characters, skills and elements are data: designers fill in tables, and BP_CombatManager runs the fight.
- Engine
- UE5 · Blueprints & CommonUI
- Role
- Solo
- Duration
- 8 weeks
- Context
- Production benchmark
- Delivered
- Build, How-To doc, trailer
Creating a character, then fighting with it
Research: weakness systems
We were taught to look for patterns in games: design templates that recur across different titles. As a turn-based fan I picked the weakness system that runs through most JRPGs, and compared how a set of them justify the mechanic.
The pattern underneath all of them: the weakness system exists to make the player feel smart. It turns an encounter into a puzzle, working out what this enemy is weak to, and pays out strategy and experimentation with a concrete reward.
What it changed: it named a design problem I had not considered: how do I reward the player for finding my game's optimal strategy? That settled One More as a core requirement rather than a stretch goal, and it shipped as a base function of the plugin.
Core loop
The plugin reproduces the Persona 5 battle loop: overworld encounter → combatants load in → turn order resolves on Speed, though in the demo whoever started the fight goes first → use a skill from your equipped persona, or guard → turn resolves.
- Skills
- A persona's abilities and the main way to deal damage. Defined by FSkillBase, listed in DT_Skills, and each carries an element from E_ElementTypes, which is what drives elemental weaknesses.
- Resource costs
- Skills cost HP or SP depending on whether they are physical or special. Physical costs health, and that is the trade: you spend HP to deal damage, but HP is far easier to restore than SP.
- Damage formula
- √(skill power) × √(stat) ÷ √(Endurance × 8), taken from my research into the source games. I carry the same stats minus equipment, so damage lands close to the original.
One More
- What
- Exploiting an elemental weakness deals double damage and grants an extra turn, for player and enemy alike.
- How
- When a skill resolves, CheckWeakness tests its element against the defender's weakness array. On a hit the attacker acts again immediately, capped at one per round.
- Result
- Playtesters were not noticing One More fire at all, so I made the popup unmissable. It reads clearly now, and it is the feature people come to this kind of template for.
Hitting a weakness and taking another turn
A level that teaches the system
Part of the brief was making the plugin as easy to import as possible. We had a museum template for showing off features, so I used it: a level that walks a first-time user through the system in-engine, alongside the How-To document covering installation.
A system nobody else can pick up is not a deliverable. The museum level and the How-To are what make it one.
Walking the museum level
Technical implementation
- BP_CombatManager: holds all the combat logic: InitializeCombat, StartTurn, ExecuteSkill, CheckWeakness. One place to debug, one Blueprint to drag in, no parameters to wire up.
- Plug-in architecture: any actor, player or enemy, that carries AC_CombatantComponent and implements BPI_Combatant can fight, using characters from DT_Characters equipped with skills from DT_Skills.
- BP_OverworldEncounter: a ready-made trigger volume, spawn points, arena camera and three enemy presets. The gateway into a battle.
A new character, skill or element needs no Blueprint changes. Adding a Wind spell is three data edits: add Garu to E_SkillID, add its row to DT_Skills, then give it to Pixie and add Wind to an enemy's weaknesses. CheckWeakness never changes.
Data architecture: enums define the vocabulary, structs use them, tables hold the content
Documentation & research
How-To document
An extensive guide to installing the plugin, playtested and verified with teammates. It gets anyone set up quickly and explains the systems behind it, for troubleshooting or for a deeper understanding.
Open the PDFWeakness system pattern analysis
The pattern analysis of the weakness exploit system that led me to the pattern above.
Open the PDFLimits & next steps
- Tested for 1v1 only, though the architecture should support more.
- No VFX, SFX or animations. The Speed stat ended up unused.
- Eight skills maximum. That is a UI limit rather than a system one, but a skill you cannot see is a skill you cannot cast.
- Researched GAS as the route for future development.
This plugin became the combat base of This Sheriff Sucks!: the skill and character structures and the turn handling carried straight over and covered the first weeks of production.