The Turn-Based Game Architecture That Finally Made My Code Stop Fighting Me

Here's the thing—when I first tried building a turn-based game, I thought it would be simpler than real-time combat. No physics, no frame-perfect timing, just "you go, then I go," right? Wrong. Burned half a day on my first attempt before I realized my code was an absolute disaster. I had a massive Update() method filled with nested if statements checking isPlayerTurn, isEnemyTurn, isAnimating, isBattleOver—and every time I wanted to add a new feature, I'd break three others. That's when I learned that turn-based game architecture isn't about simplicity; it's about structure. Without a proper architecture for managing game flow, you end up with chaotic, bug-prone code that becomes exponentially worse as complexity increases. Let me show you the exact patterns that transformed my messy prototypes into clean, scalable systems.

Why Your Turn-Based Code Probably Looks Like Spaghetti

Been there. You're building your first tactical game or JRPG-style battle system. You create a GameManager script, and you start writing logic: "If it's the player's turn, check for input. If it's the enemy's turn, run AI logic. If someone's health reaches zero, play the death animation. If all enemies are dead, show the victory screen."

Actually, wait. That sounds logical, right? But here's what happens in practice: your Update() method becomes a nightmare of nested conditionals. You're checking boolean flags everywhere—isPlayerTurn, isAnimationPlaying, isAbilityActive, isBattleOver. Adding a new state, like a "special ability" phase, means touching dozens of lines of code and praying you don't break something.

This is the critical problem that proper turn-based game architecture solves: managing game flow in a way that prevents chaotic and bug-prone code as complexity increases. Without structure, it's like players all trying to take their turn at once in a board game—total chaos.

The Board Game Rulebook Analogy That Changed How I Think About Architecture

You know what's funny? The solution to organizing turn-based game code was sitting in my closet the whole time—literally. I was playing a board game with friends, and I realized something: board games work because they have rulebooks that define who can act, when they can act, and what actions are permissible, ensuring every player (and the game itself) follows a consistent and orderly sequence of events.

A well-structured turn-based game architecture works exactly like that rulebook. It allows you to create predictable, manageable, and scalable gameplay systems, from classic JRPGs to tactical grid-based strategy games. The architecture defines the rules of engagement, prevents chaos, and ensures that every system knows exactly when it's allowed to do its job.

Think about it: in a board game, you don't have all players shouting out their moves simultaneously. There's a clear structure. That's exactly what we need in our code.

Seven Core Terms You'll Use Every Single Day

Let me break down the terminology so we're all on the same page. From my time at CMU and working on turn-based systems at KIXEYE, these seven concepts are the foundation:

State Machine: A behavioral design pattern that allows an object to change its behavior when its internal state changes. This is the backbone of managing the different phases of a turn-based game.

State: A specific condition or phase the game is in, such as 'PlayerTurn', 'EnemyTurn', or 'BattleWon'. Each state contains the logic that is exclusively allowed to run during that phase.

Transition: The process of moving from one state to another, which is typically triggered by a specific event or condition, like the player ending their turn.

Command Pattern: A behavioral design pattern that turns a request into a stand-alone object containing all information about the request. This is invaluable for handling player and AI actions like 'Move', 'Attack', or 'UseAbility'.

Command: An object that encapsulates an action, its parameters, and the logic to execute it. This decouples the entity that issues a command from the one that executes it.

Turn Manager: A central controller, often a Singleton, that orchestrates the flow of the game. It is responsible for tracking whose turn it is and managing the transitions between states.

Data-Driven Design: An architectural approach that separates game data (like unit stats, abilities, or level layouts) from the game's logic. Unity's ScriptableObjects are a cornerstone of this approach.

The State Machine: Your Turn-Based Game's Traffic Controller

After working on multiple Unity projects, I've found that the Finite State Machine (FSM) is perfect for managing the distinct phases of a turn-based battle. Think of it as a traffic controller that ensures only one phase is "active" at any given time, preventing the chaos of multiple systems trying to run simultaneously.

We define a base state with common methods and then create concrete states for each phase. Here's the exact structure I use:

// Base class for all states
public abstract class BattleState
{
    protected BattleManager BattleManager;
    public BattleState(BattleManager battleManager)
    {
        BattleManager = battleManager;
    }

    public virtual void OnEnter() { }
    public virtual void OnUpdate() { }
    public virtual void OnExit() { }
}

This base class defines the contract for all battle states. Every state has three lifecycle methods: OnEnter() (called when transitioning into the state), OnUpdate() (called every frame while in the state), and OnExit() (called when leaving the state). This pattern is the backbone of the Unity state machine approach.

Why the Command Pattern Makes Everything Click

This one had me convinced. The Command Pattern lets us define actions as objects, which sounds abstract at first, but trust me—it's brilliant. This makes it easy to queue actions, create AI, or even implement a replay system. Here's the exact implementation I use in my projects:

// Interface for any action a unit can take
public interface ICommand
{
    void Execute();
}

// Example: A command for a unit to attack another
public class AttackCommand : ICommand
{
    private Unit _attacker;
    private Unit _target;

    public AttackCommand(Unit attacker, Unit target)
    {
        _attacker = attacker;
        _target = target;
    }

    public void Execute()
    {
        _attacker.Attack(_target);
    }
}

What makes this powerful is that the command pattern Unity implementation decouples who requests an action from who performs it. The same AttackCommand can be created by player input, AI logic, a network packet, or even a replay system. You're not hard-coding "when the player clicks here, do this"—you're creating reusable action objects.

ScriptableObjects: The Secret to Data-Driven Turn-Based Design

Let me tell you about the moment I discovered ScriptableObject game design—it completely changed my workflow. ScriptableObjects allow us to create templates for our units. We can define stats and abilities as data assets in the editor, completely separate from our code.

Here's the exact setup I use for creating data-driven units:

// A data container for unit stats
using UnityEngine;

[CreateAssetMenu(fileName = "NewUnitData", menuName = "Turn-Based/Unit Data")]
public class UnitData : ScriptableObject
{
    public string unitName;
    public int maxHP;
    public int attackPower;
    public Sprite unitSprite;
}

This simple script creates a data template. Once you have this, you can create dozens of different unit types (Warriors, Mages, Archers) just by creating new ScriptableObject assets in the Unity editor. No code changes required. Your designers can balance stats without ever opening Visual Studio.

Monolithic Code vs. Proper Turn-Based Game Architecture (The Comparison That Matters)

When I'm working on projects, I always start by deciding: "Do I actually need a full architecture for this, or can I get away with simpler code?" Here's the honest comparison that guides my decision:

For any turn-based game development project beyond a weekend prototype, I always reach for Approach B. The initial investment in proper architecture pays off the moment you need to add your third or fourth game state.

Five Reasons This Architecture Changed How I Build Games

After working on multiple Unity projects at KIXEYE and teaching hundreds of students at Outscal, here's why I always reach for this architecture pattern now:

1. Your Game Can Actually Grow Without Collapsing

A proper architecture allows you to add new units, actions, or game states (like a "special ability" state) without rewriting your entire game loop. This scalability and maintainability is the difference between a prototype and a shippable game.

2. Your Code Stops Being a Tangled Mess

The Command Pattern decouples input handling from character actions, meaning the same "Attack" command can be triggered by a player click, an AI decision, or a network event. This decoupled and reusable code is a game-changer for multiplayer or AI systems.

3. Your Teammates Can Actually Read Your Code

Separating logic into distinct states (PlayerTurnState, EnemyTurnState) makes the code self-documenting and far easier for new team members to understand. This improved readability has saved my team countless hours in code reviews.

4. Your AI Stops Breaking Player Logic

With a Unity state machine, your AI logic is neatly contained within its own state, where it can analyze the battlefield and issue commands without interfering with player logic. This enables complex AI that doesn't create spaghetti code.

5. Your Designers Stop Asking You to Change Code

Using ScriptableObjects for unit and ability data empowers designers to create and balance content in the Unity Editor without ever needing to touch the core game logic code. This data-driven workflow is how professional studios actually work.

My Three Non-Negotiable Rules for Turn-Based Systems

Trust me, you'll thank me later for these tips. I learned all of these the hard way, so you don't have to.

Rule #1: Use an Event Queue for System Communication

Instead of having systems call each other directly, use a central event queue or C# events to announce what has happened (e.g., OnUnitDied, OnTurnStart). This further decouples your systems and makes debugging infinitely easier.

Here's the exact pattern I use:

// In your TurnManager
public static event System.Action OnUnitSelected;

// In your UI script
private void OnEnable() {
    TurnManager.OnUnitSelected += HandleUnitSelection;
}

This event-driven approach means your UI doesn't need a reference to the TurnManager, and your TurnManager doesn't need to know the UI exists. They communicate through events.

Rule #2: Abstract Your Input System

Here's the thing—I see this mistake all the time. Don't tie your commands directly to Unity's old Input Manager (Input.GetKeyDown, Input.GetAxis). The official Unity documentation strongly recommends using the new Input System package for modern projects because it's more flexible, platform-agnostic, and separates input logic from game logic.

Setting Up the New Input System (Step-by-Step):

Before you can use the new Input System, you need to install and configure it. Here's exactly how I do it in every project:

1. Install the Input System Package:
   • Open Unity's Package Manager (Window > Package Manager)
   • Search for "Input System"
   • Click "Install"
   • Unity will prompt you to enable the new backends and restart the editor—click "Yes"
2. Create an Input Actions Asset:
   • In your Project window, right-click and select Create > Input Actions
   • Name it something like "PlayerInputActions"
   • Double-click the asset to open the Input Actions editor
3. Define Your Actions:
   • In the Input Actions window, create an Action Map called "Player"
   • Add actions like "Ability1", "Ability2", "Movement", etc.
   • For each action, bind the desired keys (e.g., bind "Ability1" to the "1" key)
   • Click "Save Asset" at the top of the window
4. Generate the C# Script:
   • With your Input Actions asset selected in the Project window
   • In the Inspector, check the box for "Generate C# Class"
   • Click "Apply"
   • This creates a C# script that you can reference in your code

Now you're ready to use it in your code:

// InputManager.cs
using UnityEngine;
using UnityEngine.InputSystem;

public class InputManager : MonoBehaviour
{
    // Reference to your Input Actions asset
    private PlayerInputActions inputActions;
    private Unit playerUnit;

    private void Awake()
    {
        inputActions = new PlayerInputActions();
        playerUnit = FindObjectOfType();
    }

    private void OnEnable()
    {
        // Subscribe to input events
        inputActions.Player.Ability1.performed += OnAbility1Performed;
        inputActions.Player.Enable();
    }

    private void OnDisable()
    {
        inputActions.Player.Ability1.performed -= OnAbility1Performed;
        inputActions.Player.Disable();
    }

    private void OnAbility1Performed(InputAction.CallbackContext context)
    {
        // Create a command instead of calling the action directly
        var command = new AbilityCommand(playerUnit, playerUnit.Abilities[0]);
        CommandQueue.Add(command);
    }
}

Why this matters: This separation means you can swap keyboard input for controller input, touch input, or even AI input without changing your core game logic. It also makes it trivial to add support for different keybindings or even rebindable controls. I learned this the hard way when we needed to add controller support to a project at KIXEYE—we had to refactor hundreds of lines of code because we'd used the old Input Manager everywhere.

Rule #3: Make States Data-Driven

Use ScriptableObjects to define your states. This allows you to configure state transitions or specific state properties (like turn duration) in the editor. It's an advanced technique, but once you start using it, you'll never go back.

How XCOM, Slay the Spire, and Final Fantasy X Actually Work Under the Hood

Let me tell you about how I've seen this technique used brilliantly in some of my favorite tactical game development examples. After analyzing these implementations, I realized the patterns we've been discussing aren't theoretical—they're how professional studios actually ship games.

What XCOM: Enemy Unknown Taught Me About State Machines

One of my favorite implementations of this is in XCOM: Enemy Unknown. Players command a squad of soldiers on a grid-based map. Each soldier has a set number of action points per turn to move, shoot, or use abilities.

From a developer's perspective, what makes this brilliant is the implementation: a sophisticated state machine manages the high-level game flow (PlayerTurn, AlienTurn). The Command Pattern is likely used for every action a soldier can take (MoveCommand, ShootCommand). This allows the AI to use the exact same actions as the player and enables the game's iconic action-replay camera.

What I find fascinating about this approach is the player experience it creates: the clear separation of turns and actions gives the player a strong sense of tactical control and clarity. Every action feels deliberate and impactful. This is why I always recommend studying XCOM's approach to turn-based combat system design.

The Slay the Spire Architecture That Convinced Me

This one really sold me on data-driven design. In Slay the Spire, it's a deck-building roguelike where players draw a hand of cards each turn and use "Energy" to play them. Cards are actions like attacking, defending, or applying status effects.

After analyzing this implementation, I realized the core loop is a state machine (PlayerTurn, EnemyTurn). Each card is essentially a Command object. The card's data (cost, effect, target) is likely stored in a ScriptableObject, and when played, it instantiates and executes the appropriate command.

Here's how you can adapt this for your own game: the architecture makes the complex interactions between hundreds of different cards and relics manageable and predictable, allowing for deep strategic planning. I always tell my students to look at how Slay the Spire handles card data—it's a masterclass in Unity game design patterns.

Final Fantasy X's Turn Order System Broke My Brain (In a Good Way)

Let me tell you about the mechanic that inspired my current turn management system: Final Fantasy X features a classic JRPG with a visible turn order (the "Conditional Turn-Based" system). Actions can affect a unit's position in the turn queue.

What I find fascinating about this approach is the implementation: a central TurnManager controls a list of all units in battle, sorted by their speed stat. The game is in a constant "Action" state, and the TurnManager simply gives the next unit in the list a turn. Actions are commands that can modify the turn order list itself.

This is why I always recommend studying this game's approach: the system makes turn order a key tactical element. Players can strategically use abilities to delay powerful enemies or give their own characters extra turns. The player experience this creates is strategic depth that goes beyond just "damage numbers."

Blueprint #1: Building Your First State Machine for Turn Management

Let's tackle this together and create a foundational BattleManager that uses a state machine to switch between a "Start", "PlayerTurn", and "EnemyTurn" phase. This is the exact method I use when starting any new turn-based project.

Unity Editor Setup

Here's my go-to setup process:

1. Create an empty GameObject and name it BattleManager
2. Create a new C# script named BattleManager and attach it to the GameObject
3. Create three more C# scripts: BattleState, PlayerTurnState, and EnemyTurnState

Step-by-Step Code Implementation

Let me show you how I approach this, step by step.

Step 1: The Abstract Base Class

This defines the contract for all states:

// BattleState.cs
public abstract class BattleState
{
    protected BattleManager BattleManager;

    public BattleState(BattleManager battleManager)
    {
        BattleManager = battleManager;
    }

    public virtual void OnEnter() { }
    public virtual void OnUpdate() { }
    public virtual void OnExit() { }
}

Every state will inherit from this base class and override the methods it needs.

Step 2: Implementing the Player Turn State

This holds logic for the player's turn. For this example, I'm using a simple key press, but in your production game, you'd wire this up to your Input System actions:

// PlayerTurnState.cs
using UnityEngine;

public class PlayerTurnState : BattleState
{
    public PlayerTurnState(BattleManager battleManager) : base(battleManager) { }

    public override void OnEnter()
    {
        Debug.Log("Player Turn: START");
    }

    public override void OnUpdate()
    {
        // In a production game, this would be triggered by an Input System action
        // For this example, we'll use a simple key check for demonstration
        if (Input.GetKeyDown(KeyCode.Space))
        {
            BattleManager.ChangeState(BattleManager.EnemyTurnState);
        }
    }

    public override void OnExit()
    {
        Debug.Log("Player Turn: END");
    }
}

Notice how the state can directly access other states through the BattleManager reference. This makes transitions clean and explicit.

Step 3: Implementing the Enemy Turn State

This will hold the AI's logic. Here, we'll just simulate a delay and then switch back to the player:

// EnemyTurnState.cs
using UnityEngine;

public class EnemyTurnState : BattleState
{
    private float _enemyTurnTimer;

    public EnemyTurnState(BattleManager battleManager) : base(battleManager) { }

    public override void OnEnter()
    {
        Debug.Log("Enemy Turn: START");
        _enemyTurnTimer = 2f; // Simulate a 2-second turn
    }

    public override void OnUpdate()
    {
        _enemyTurnTimer -= Time.deltaTime;
        if (_enemyTurnTimer <= 0)
        {
            BattleManager.ChangeState(BattleManager.PlayerTurnState);
        }
    }
}

In a real game, the OnEnter() method would be where you call your AI decision-making logic.

Step 4: The State Machine Controller

These are the exact settings I use in my BattleManager—I've configured this dozens of times:

// BattleManager.cs
using UnityEngine;

public class BattleManager : MonoBehaviour
{
    // State Variables
    public BattleState CurrentState { get; private set; }
    public PlayerTurnState PlayerTurnState { get; private set; }
    public EnemyTurnState EnemyTurnState { get; private set; }

    private void Start()
    {
        // Initialize all states
        PlayerTurnState = new PlayerTurnState(this);
        EnemyTurnState = new EnemyTurnState(this);

        // Start the battle
        ChangeState(PlayerTurnState);
    }

    private void Update()
    {
        // We must update the current state every frame
        CurrentState?.OnUpdate();
    }

    public void ChangeState(BattleState newState)
    {
        // Call OnExit on the current state before switching
        CurrentState?.OnExit();

        // Switch to the new state
        CurrentState = newState;

        // Call OnEnter on the new state
        CurrentState.OnEnter();
    }
}

This is the core of the entire system. The ChangeState() method handles the lifecycle: exit the old state, switch to the new state, enter the new state.

Blueprint #2: Implementing the Command Pattern for Actions

When I'm working on action systems, my process is to define Move and Attack actions as command objects that can be executed by a central system. Let me walk you through it.

Unity Editor Setup

1. Create a Player and Enemy GameObject (simple cubes are fine)
2. Attach a Unit.cs script (created below) to both
3. Create an empty GameObject named InputManager. Attach InputManager.cs to it

Step-by-Step Code Implementation

Step 1: The Command Interface

The blueprint for all actions is incredibly simple:

// ICommand.cs
public interface ICommand
{
    void Execute();
}

Every command in your game will implement this single method.

Step 2: The Unit Class (The "Receiver")

The component that will actually perform the actions:

// Unit.cs
using UnityEngine;

public class Unit : MonoBehaviour
{
    public void Move(Vector3 destination)
    {
        Debug.Log($"{name} is moving to {destination}");
        // In a real game, you'd use a NavMeshAgent or tweening library here
        transform.position = destination;
    }

    public void Attack(Unit target)
    {
        Debug.Log($"{name} attacks {target.name}!");
        // In a real game, you'd apply damage and play animations
    }
}

This is the "receiver" in the command pattern—the object that knows how to actually perform the actions.

Step 3: The Move Command

Encapsulates the move action:

// MoveCommand.cs
using UnityEngine;

public class MoveCommand : ICommand
{
    private Unit _unit;
    private Vector3 _destination;

    public MoveCommand(Unit unit, Vector3 destination)
    {
        _unit = unit;
        _destination = destination;
    }

    public void Execute()
    {
        _unit.Move(_destination);
    }
}

Notice how the command stores all the information needed to perform the action (who, where) and can be executed at any time.

Step 4: The Attack Command

// AttackCommand.cs
public class AttackCommand : ICommand
{
    private Unit _attacker;
    private Unit _target;

    public AttackCommand(Unit attacker, Unit target)
    {
        _attacker = attacker;
        _target = target;
    }

    public void Execute()
    {
        _attacker.Attack(_target);
    }
}

Step 5: The Input Manager (The "Invoker")

Creates and executes commands based on player input. Here's a simplified example using direct key checks for demonstration purposes:

// InputManager.cs
using UnityEngine;

public class InputManager : MonoBehaviour
{
    public Unit playerUnit; // Assign in Inspector
    public Unit enemyUnit;  // Assign in Inspector

    // NOTE: In a production game, replace these Input.GetKeyDown calls
    // with Unity's new Input System actions as shown in Rule #2 above
    void Update()
    {
        if (Input.GetKeyDown(KeyCode.M))
        {
            // Create a move command to a random position
            var moveDestination = new Vector3(Random.Range(-5, 5), 0, Random.Range(-5, 5));
            ICommand moveCommand = new MoveCommand(playerUnit, moveDestination);
            moveCommand.Execute();
        }

        if (Input.GetKeyDown(KeyCode.A))
        {
            // Create an attack command
            ICommand attackCommand = new AttackCommand(playerUnit, enemyUnit);
            attackCommand.Execute();
        }
    }
}

This is where input gets translated into commands. For production games, I strongly recommend migrating this to Unity's new Input System.

Blueprint #3: Creating Data-Driven Units with ScriptableObjects

In my projects, I always implement this third blueprint because it's the key to creating different unit types using ScriptableObject assets for their stats, separating data from the Unit logic.

Unity Editor Setup

Here's my go-to setup:

1. In the Project window, right-click -> Create -> Turn-Based -> Unit Data. Create two: "WarriorData" and "MageData"
2. Configure their stats in the Inspector (e.g., Warrior: 150 HP, 20 Attack; Mage: 80 HP, 35 Attack)
3. Use the Unit.cs script from Blueprint 2. Modify it to use the new data container

Step-by-Step Code Implementation

Step 1: The ScriptableObject Data Container

This holds the data for a type of unit:

// UnitData.cs
using UnityEngine;

[CreateAssetMenu(fileName = "NewUnitData", menuName = "Turn-Based/Unit Data")]
public class UnitData : ScriptableObject
{
    public string unitName;
    public int maxHP;
    public int attackPower;
    // You could add abilities, sprites, etc. here
}

The [CreateAssetMenu] attribute is what creates that right-click menu option in Unity.

Step 2: Modified Unit Class

This MonoBehaviour now uses a UnitData asset to configure itself:

// Unit.cs (Modified)
using UnityEngine;

public class Unit : MonoBehaviour
{
    public UnitData unitData; // Assign WarriorData or MageData in the Inspector

    private int _currentHP;
    public int AttackPower { get; private set; }

    void Start()
    {
        // Configure the unit based on the ScriptableObject data
        _currentHP = unitData.maxHP;
        AttackPower = unitData.attackPower;
        gameObject.name = unitData.unitName;
        Debug.Log($"Unit {name} created with {AttackPower} attack!");
    }

    // Other methods (Move, Attack) remain the same
    public void Move(Vector3 destination)
    {
        Debug.Log($"{name} is moving to {destination}");
        transform.position = destination;
    }

    public void Attack(Unit target)
    {
        Debug.Log($"{name} attacks {target.name} with {AttackPower} power!");
    }
}

Now you can create dozens of unit variations just by creating new UnitData assets in the editor, without writing any new code. This is the power of data-driven design—your game content scales without your codebase exploding.

Ready to Start Building Your First Game?

If you've made it this far, you understand the architectural patterns that separate amateur projects from professional game development. The turn-based game architecture patterns we've covered—state machines, command patterns, and data-driven design—are exactly the kind of foundational knowledge that will make you valuable to any game studio.

At Outscal, I've built a complete game development course that takes you from the absolute basics to building professional-quality experiences. We cover not just architectural patterns, but all the optimization techniques, design principles, and practical skills you need to break into the game industry.

Whether you're working on your first Unity project or trying to level up from hobbyist to professional, the Mr. Blocks course will give you the exact roadmap I wish I had when I was starting out. No fluff, no outdated techniques—just the real-world skills studios are looking for.

Key Takeaways

• State machines are the backbone of turn-based systems, providing a clean way to manage different phases (PlayerTurn, EnemyTurn, Victory) without nested if-statements.
• The Command Pattern decouples actions from input, allowing the same Attack or Move command to be triggered by players, AI, network events, or replay systems.
• ScriptableObjects enable data-driven design, letting designers create and balance dozens of units, abilities, and game elements without touching code.
• Monolithic GameManagers work for prototypes but fail at scale—proper architecture has higher upfront complexity but remains maintainable as features grow.
• Event-driven communication between systems (using C# events or an event bus) further decouples your code and simplifies debugging.
• Use Unity's new Input System instead of the old Input Manager for modern, extensible, platform-agnostic input handling that separates input logic from game logic.
• Professional games like XCOM, Slay the Spire, and Final Fantasy X all use these exact patterns—state machines for flow, commands for actions, data-driven content.
• The three lifecycle methods (OnEnter, OnUpdate, OnExit) in each state provide clear hooks for initialization, per-frame logic, and cleanup, making state behavior explicit and predictable.