What is "Coding TicTacToe: Game Loop and Controller" about?

How to implement a clean game loop and a "Thin Controller" that delegates logic to models without leaking implementation details.

What topics does "Coding TicTacToe: Game Loop and Controller" cover?

This article covers: tictactoe game loop, thin controller pattern, game controller lld, polymorphism lld, machine coding loop.

Coding TicTacToe: Game Loop and Controller Wiring

The design is finalized. The models are written. Now comes the part that separates knowing the design from actually implementing it: writing the code that drives the game. Where does control begin? Who calls what? Here is how I wire up the game loop.

The Essentials

The main class is the client: In a command-line game, main runs the loop that prints state, checks for undo, and prompts for moves.
The GameController is the abstraction: All methods the main class calls go through the controller. The controller delegates to models.
The loop condition is state-based: Never use a move count. Use game.getStatus() == IN_PROGRESS.
Player.makeMove handles both humans and bots: Polymorphism ensures the main class never needs to check the player type.
Validation belongs in the game, not the client: Never trust external input. The game class must validate every move internally.

The Main Class as Client

In a desktop game, we write the client ourselves in the main method. The main method is intentionally "dumb." It does exactly three things in a loop:

Print the current board.
Ask if anyone wants to undo.
Ask the current player to make a move.

Everything else -- validation, board updates, winner detection -- happens inside the game layer.

function main(): void {
  const controller = new GameController();
  const game = controller.createGame(dimension, players, winningStrategies);

  while (controller.getGameStatus(game) === GameStatus.IN_PROGRESS) {
    controller.displayBoard(game);

    const wantsUndo = prompt("Do you want to undo? (yes/no): ");
    if (wantsUndo === "yes") {
      controller.undo(game);
      continue;
    }

    controller.makeNextMove(game);
  }

  controller.printResult(game);
}

The Stateless Controller

Notice that the GameController has no state. It doesn't store a game object as a field. Instead, the main method passes the game object as a parameter to every controller call.

This means the same controller can serve multiple games simultaneously. This is the standard pattern for controllers in both desktop and web applications.

Creating a Game: The Builder Pattern

In the controller, createGame doesn't just call new Game(). It uses the builder we designed to ensure all validation rules (e.g., distinct symbols) are checked before construction.

class GameController {
  createGame(dimension: number, players: Player[], strategies: WinningStrategy[]): Game {
    return Game.getBuilder()
      .setDimension(dimension)
      .setPlayers(players)
      .setWinningStrategies(strategies)
      .build();
  }
}

Why Validation Stays in the Model

If validation lived in the client (the main loop), it could be skipped or forgotten. By putting validateMove inside the Game class, we ensure it runs on every move, regardless of who calls it.

The controller and game loop are in place, but several methods still return stubs. In the final post, we will finish the bot strategy, the O(1) winning logic, and the state-reversal undo.

Coding TicTacToe: Game Loop and Controller

The Essentials

The Main Class as Client

The Stateless Controller

Creating a Game: The Builder Pattern

Why Validation Stays in the Model

Further Reading and Watching