Before opening Unreal Engine, the most important system in a JRPG needs to exist on paper.
Turn-based combat is not something you “discover” through implementation. It is something you decide, deliberately. The clearer the combat rules are upfront, the easier every technical decision becomes later.
This post focuses on designing a turn-based combat system at a conceptual level — independent of engine, tools, or code.
Why Combat Design Comes First
In a JRPG, combat is the primary interaction loop. Exploration, progression, narrative pacing, and even UI design eventually bend around it.
If combat is vague, everything downstream becomes unstable:
- Stats feel meaningless
- Skills overlap or become redundant
- Encounters are difficult to tune
- UI becomes cluttered or unclear
Designing combat early creates a gravity center for the rest of the game.
Start With the Combat Loop
At its simplest, a turn-based combat loop answers four questions:
- Who acts next?
- What options do they have?
- How is the action resolved?
- What changes as a result?
Everything else is an extension of these questions.
For this project, the combat loop is intentionally explicit:
- Turns are discrete and readable
- Outcomes are deterministic
- Players are given time to plan
The goal is not speed, but clarity.
Turn Order: Who Acts, and Why
Turn order is the backbone of turn-based combat.
Common approaches include:
- Fixed turn order (party ? enemies)
- Speed-based order
- ATB-style time gauges
- Hybrid systems with conditional interrupts
The key design decision is not which system is chosen, but whether the player understands it.
A good turn order system:
- Can be predicted
- Can be influenced
- Communicates upcoming turns clearly
If players cannot explain why an enemy acted before them, the system has failed.
Player Options: Meaning Over Quantity
On a player’s turn, available actions define the game’s depth.
Typical options include:
- Basic attacks
- Skills or abilities
- Items
- Defend or wait actions
Depth does not come from having many options — it comes from meaningful trade-offs.
Every action should answer at least one of the following:
- Does this change positioning, tempo, or turn order?
- Does this interact with another system (status, resource, synergy)?
- Does this create a short-term gain at a long-term cost?
If two actions lead to the same outcome, one of them does not belong.
Resolution: Making the Math Honest
Combat resolution is where player trust is built or destroyed.
Behind every action is math — damage formulas, hit chances, status application, resource costs. The exact formulas matter less than consistency.
Key principles:
- Identical situations should produce identical outcomes
- Randomness should be bounded and visible
- Player stats should have understandable effects
Players do not need to see every formula, but they should be able to reason about cause and effect.
Feedback: Showing What Happened
Once an action resolves, the game must clearly communicate the result.
This includes:
- Damage numbers
- Status effects applied or removed
- Changes to turn order
- Resource consumption
Feedback closes the loop. Without it, even a well-designed system feels arbitrary.
This is where combat design directly informs UI and animation requirements later.
Party Design and Synergy
Turn-based combat shines when characters are designed around the system.
Each party member should:
- Solve different problems
- Interact differently with turn order or resources
- Create opportunities for synergy
Synergy does not require complex combos. It can be as simple as one character creating conditions that another can exploit.
The important part is that party composition meaningfully affects how combat plays out.
Status Effects as System Glue
Status effects are one of the most powerful tools in a turn-based system.
They:
- Modify rules temporarily
- Create urgency or opportunity
- Encourage players to think beyond raw damage
Good status effects change decisions, not just numbers.
Designing them early prevents them from becoming an afterthought later.
Difficulty, Pacing, and Learning
Combat design must account for how players learn the system.
This means:
- Introducing mechanics gradually
- Reinforcing concepts through encounter design
- Allowing players to fail safely early on
Difficulty should come from understanding, not surprise.
Writing the Rules Before the Code
At this stage, none of this exists in Unreal Engine. That’s intentional.
Before implementation, the combat system should be expressible as:
- A written rule set
- Simple flow diagrams
- Example encounters
If the system cannot be explained clearly without code, it is not ready to be built.
What Comes Next
With a paper-defined combat system in place, the next step is translating structure into Unreal Engine:
- Defining combat states
- Mapping turn flow to state machines
- Deciding what lives in data vs logic
Only then does it make sense to open Unreal and start prototyping.
Design first. Engine second.