Title Screen
First impressions matter. Add a title screen with state machine architecture.
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

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:
This code sample could not be loaded. The file may be missing or the path may be incorrect.
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:
This code sample could not be loaded. The file may be missing or the path may be incorrect.
The flow is:
- Set initial state to
GS_TITLE - Draw the title screen
- 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:
This code sample could not be loaded. The file may be missing or the path may be incorrect.
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:
This code sample could not be loaded. The file may be missing or the path may be incorrect.
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 code sample could not be loaded. The file may be missing or the path may be incorrect.
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
This code sample could not be loaded. The file may be missing or the path may be incorrect.
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.