With a paper-defined combat system in place, the next step is translating structure into Unreal Engine.
This is where abstract rules become concrete systems — but it’s also where many projects quietly go wrong. The goal is not to recreate the combat design verbatim in code, but to preserve its intent while adapting it to Unreal’s architecture.
This post focuses on three foundational decisions:
- Defining combat states
- Mapping turn flow to state machines
- Deciding what belongs in data versus logic
These choices shape everything that follows.
From Rules to Structure
On paper, the combat system is a set of rules:
- Who can act
- When they can act
- What happens when they do
In Unreal, those rules must live somewhere. If they are scattered across Blueprints, UI widgets, and character classes, the system becomes fragile and difficult to reason about.
The solution is to give combat a clear structure before worrying about implementation details.
What We Mean by “State Machine” (Concept First)
When we talk about a combat state machine, we are not necessarily talking about Unreal’s Animation State Machines.
A state machine, conceptually, is simply:
- A finite set of named states
- Clear rules for entering and exiting those states
- Well-defined responsibilities per state
For turn-based combat, this might look like:
- CombatStart
- TurnStart
- PlayerInput
- ActionExecution
- Resolution
- TurnEnd
- CombatEnd
At any given moment:
- Combat is in one state
- Only the logic relevant to that state can run
- Transitions are explicit and intentional
This is the real value — clarity and control.
Defining Combat States
Turn-based combat is inherently state-driven. At any given moment, the game is in exactly one meaningful combat state.
At a high level, combat can be broken into states such as:
- Combat start
- Turn start
- Player input
- Action execution
- Animation and effects
- Status resolution
- Turn end
- Combat end
These states should be mutually exclusive and explicit. The game should never be unsure of what phase combat is currently in.
Defining these states early helps answer questions like:
- When is player input allowed?
- When can stats change?
- When do status effects tick?
If a rule doesn’t clearly belong to a state, it likely needs refinement.
Mapping Turn Flow to State Machines
Once combat states are defined, they can be expressed naturally as a state machine.
Rather than thinking in terms of functions calling functions, it’s more useful to think in terms of transitions:
- What causes the game to enter a state?
- What conditions must be met to leave it?
- What happens on entry and exit?
In Unreal, state machines provide:
- Readable combat flow
- Predictable execution order
- Easier debugging
For example:
- Selecting a skill transitions from Player Input to Action Execution
- Completing animations transitions to Resolution
- Resolving effects transitions to Turn End
The important part is not the specific tool used, but the discipline of treating combat as a flow of states rather than a collection of one-off events.
Deciding What Lives in Data vs Logic
One of the most important architectural decisions in a JRPG is separating what the rules are from how they are executed.
In Unreal terms:
Data Should Define
- Stats and stat growth
- Skills and abilities
- Items and equipment
- Status effects
- Enemy configurations
These are values that designers should be able to adjust without rewriting logic. They change often and benefit from being visible and editable.
Logic Should Handle
- Turn order resolution
- Damage and effect calculation
- State transitions
- Validation and rule enforcement
Logic enforces consistency. It ensures that the same inputs always produce the same outcomes.
This separation makes the system easier to balance, debug, and extend.
Avoiding Common Pitfalls
A few common mistakes appear frequently when implementing turn-based combat in Unreal:
- Encoding rules directly in UI widgets
- Duplicating combat logic across characters
- Mixing animation timing with rule resolution
- Letting Blueprints grow without structure
Most of these issues stem from skipping the structural step and jumping straight into implementation.
Building for Change
Early implementations should expect to change.
By anchoring combat around:
- Explicit states
- Clear transitions
- Data-driven definitions
changes become localized rather than catastrophic.
This flexibility is essential during early prototyping, when tuning and iteration are constant.
What Comes Next
With combat structure mapped cleanly to Unreal concepts, the next step is implementation:
- Creating the core combat controller
- Building the first combat state machine
- Hooking up data-driven abilities
Only then does combat start to take physical form inside the engine.
Structure first. Implementation second.