In our series on translating turn-based combat into Unreal Engine, we’ve already talked about how combat itself should live in a clear, explicit state machine with well-defined responsibilities. But before the first combat state ever fires, the player is usually in a completely different loop — exploration.

In this post we’ll break down how exploration transitions into combat in a classic JRPRG, and what logic belongs in that early “combat start” phase.

1. The Player in World Exploration

While the player is free to move around and interact with the world, the game is in an exploration mode:

• The player can run, talk to NPCs, pick up items, explore terrain, and generally “live” in the game world.
• Enemies might exist as actors in the world, wandering, patrolling, or standing still based on AI logic.
• The world might present hazards, quests, triggers, and story beats — everything except structured turn-based combat.

Importantly, the combat system is dormant at this stage — no combat states have been entered yet.

2. Detecting Enemy Overlap (Triggering Combat)

The first step in entering combat is detecting an overlap or collision between the player and an enemy:

Why Overlap Is a Good Trigger

In many JRPGs (especially older classics), simply touching an enemy triggers combat. Designing a reliable trigger achieves two things:

• It separates exploration logic from combat logic cleanly.
• It lets designers build encounters based on proximity instead of menu choices or random numbers.

In Unreal Engine you can use:

• Trigger volumes / collision spheres on enemy actors.
• OnOverlap events in Blueprints or C++ to detect when the player enters a defined area.

When the player overlaps an enemy’s trigger:

• The game flags that combat should start.
• Relevant enemy and player data (stats, state, location) get bundled up for the fight.

This overlap check lives in the exploration code — not the combat state machine yet — because until overlap happens, combat logic shouldn’t be running at all. (Epic Developer Community Forums)

3. Initiating Combat: What Happens Before CombatStart

Once overlap is detected, the next step is to transition from exploration into combat start logic. This phase is distinct from the combat state machine itself and has its own responsibilities:

Preserve World State

Before transitioning:

• Save the player’s position and rotation (so you can return after combat).
• Record the current world state (player health, world time, active quests, etc.).
• Deactivate exploration controls (movement, camera panning, interactions).

Switch Input and UI Modes

Combat requires different input and UI:

• Disable exploration controls.
• Bring up combat UI (party status, enemy list, action menus).
• Switch camera if needed (e.g., battle vantage vs exploration view).

This ensures there’s no overlap in gameplay intent — exploration controls don’t steal focus from combat controls.

Prepare Combat Data

Before you enter your combat state machine, gather everything combat needs:

• A combat context with participating actors (player party and enemy group).
• Each actor’s relevant stats (HP, MP, Speed, abilities, etc.).
• Any special modifiers (terrain, buffs/debuffs carried from exploration).

This prep step stays outside the turn-based state machine so that once CombatStart begins, all resources are ready.

4. Entering CombatStart State

Once the pre-combat logic has run, you can transition into your state machine’s CombatStart phase — the first of the structured turn-based states defined in earlier posts. This is where the combat flow really begins — turn order calculation, UI setup, and initial animations.

At this point:

• The exploration game mode is suspended.
• Combat mode is active.
• Only logic relevant to combat is allowed to run.
• You are officially inside your combat state machine.

Separation of Concerns: Why This Matters

By dividing exploration, overlap detection, and pre-combat logic from the turn-based state machine, you achieve:

Clarity: Combat doesn’t accidentally run while exploring the world.

Control: Each system has a well-defined entry point.

Modularity: You can reuse exploration logic without dragging combat dependencies into it.

This separation mirrors how good JRPG architecture treats combat not as a side effect of exploration but as a distinct loop with its own rules and responsibilities.

What This Means in Unreal

In Unreal Engine, the simplest clean approach is:

1. Exploration Mode
   • Player movement, world interactions.
   • Enemy actors with collision triggers.
2. Overlap Event
   • OnActorBeginOverlap or trigger volume checks determine combat start.
3. Pre-Combat Sequence
   • Save world state.
   • Switch input/UI.
   • Gather participants.
4. CombatStart State Machine
   • Call your combat controller and enter the first state.

This isn’t necessarily tied to one specific Unreal feature (GameMode, GameState, etc.) — but keeping the logic out of UI widgets and character pawns, and in well-defined controllers or managers, will make your system maintainable.

Summary

Exploration ? Enemy Overlap ? Pre-Combat Logic ? CombatStart State

At each handoff, the logic shifts responsibility:

• Exploration only handles overlapping detection.
• Pre-combat prepares the system for the combat state machine.
• CombatStart hands control fully over to structured states.

This approach keeps your JRPRG architecture clean, predictable, and easy to reason about — especially as your combat system grows in complexity.