Skip to content
Game 5 Unit 7 of 128 1 hr learning time

Title Screen

First impressions matter. Add a title screen with state machine architecture.

5% of Ink War

The game works. Two players can battle for territory, see who wins, and play again. But it starts abruptly — no introduction, no title, just straight into gameplay.

This unit adds a title screen. More importantly, it introduces a state machine — a pattern you’ll use in every game you build.

Run It

pasmonext --sna inkwar.asm inkwar.sna

Unit 7 Screenshot

Load the snapshot and you’ll see “INK WAR” with “PRESS ANY KEY TO START”. Press any key to begin playing. When the game ends, you’ll return to this title screen.

The State Machine Pattern

Games have distinct phases: title screen, gameplay, game over. The state machine pattern handles this cleanly:

Three states, each a single byte value. The current state lives in a variable. The main loop checks this state and dispatches to the appropriate handler.

Main Loop Dispatch

The entry point and main loop:

The flow is:

  1. Set initial state to GS_TITLE
  2. Draw the title screen
  3. Main loop checks state and jumps to the right handler

Using or a to check for zero is a common Z80 idiom. It’s faster than cp 0 and sets the zero flag if A is zero.

Drawing the Title Screen

The title screen is straightforward — two messages centred on screen:

We reuse the print_message routine from Unit 6. Null-terminated strings make it easy to add new messages.

State Handlers

Each state has its own handler:

Title state: Wait for any key, then transition to playing.

Playing state: Run the normal game loop (keyboard, input handling).

The start_game function handles the transition — it changes state, redraws the screen, and waits for the player to release the key they pressed to start.

Returning to Title

After game over, instead of restarting immediately, we return to the title:

This creates a complete loop: Title → Play → Results → Title.

Why State Machines?

The state machine pattern keeps code organised as games grow complex. Consider what you’d need without it:

  • Flag variables for “is game over?”, “is showing title?”, “is paused?”
  • Nested conditions checking multiple flags
  • Spaghetti jumps between different parts of the code

With a state machine:

  • One variable tracks current state
  • Each state has a dedicated handler
  • Transitions are explicit and clear
  • Adding new states (pause menu, options) is straightforward

The Complete Code

Try This: Add Credits

CREDITS_ROW equ     22
CREDITS_COL equ     8
msg_credits:    defb    "BY YOUR NAME HERE", 0

Add a third message to draw_title_screen.

Try This: Coloured Title

TITLE_ATTR  equ     %01000110       ; Yellow on red + BRIGHT

Change the title message attribute for a more striking look.

What You’ve Learnt

  • State machine pattern — Organise game flow into distinct states
  • Main loop dispatch — Check state and jump to appropriate handler
  • State transitions — Change state variable, reinitialise as needed
  • Code reuse — Leverage existing routines (print_message) for new features

What’s Next

In Unit 8, we’ll polish the two-player experience with better visual feedback and prepare the foundation for AI opponents.

What Changed

Unit 6 → Unit 7