How to Design a Turn-Based Strategy Game on iPad
A turn-based strategy game gives the player time to choose an action, then lets the game resolve the result before the next turn begins. You can prototype this structure on iPad with hyperPad using Attributes, conditions, UI, Scenes, and visual Behaviors.
This guide replaces the old play-by-mail framing. It focuses on a local two-player or single-device prototype. Online asynchronous play would require a verified networking, account, storage, and synchronization system beyond this beginner build.
The turn structure
| Phase | Player or game action | State to track |
|---|---|---|
| Start turn | Show whose turn it is | Active player |
| Choose action | Select a unit and destination | Selected Object |
| Validate | Check whether the move is allowed | Range, occupancy, and action status |
| Resolve | Move, attack, collect, or defend | Position, health, resources |
| End turn | Disable the old player and enable the next | Turn number and active player |
1. Build one small board
Create one Scene with a simple grid, one unit for each player, and one goal or resource.
Use placeholder Graphics. The first test is about turn order and legal actions, not art.
2. Store the active player
Use Set Attribute to store the active player. Display that value in the UI so both players know whose input is accepted.
Every player action should check the active-player state before it changes the board.
3. Select one unit
Use Started Touching on a unit. A valid selection should change its appearance and store which Object is selected.
Reject selection when the unit belongs to the inactive player or has already acted.
4. Validate a destination
When the player chooses a destination, check:
- whether it is inside the allowed range;
- whether another Object occupies it;
- whether the selected unit can still act;
- whether the destination is part of the board.
Show a visible valid or invalid response before resolving the move.
5. Resolve one action
Move the selected unit, update any affected value, and mark the unit as used for this turn. Keep the first version to movement or collecting a resource.
Add combat only after the turn and movement state are reliable.
6. End the turn
A clear End Turn button can:
- clear the selected Object;
- reset allowed actions;
- change the active-player Attribute;
- increment the turn number;
- update the UI.
Test alternating turns several times. Input from the inactive player should never alter the game.
7. Add a win condition
Use one visible goal, such as reaching a target, collecting three resources, or reducing an opponent’s health to zero.
When the condition is met, stop turn input, show the winner, and provide a restart.
8. Test state failures
Try to:
- move twice in one turn;
- select an opponent’s unit;
- move onto an occupied space;
- press End Turn without acting;
- restart during a selection;
- win and then continue playing.
The Project should respond according to the rules you wrote.
What about asynchronous online play?
A true play-by-mail-style game must store moves outside the current session, identify players, synchronize authoritative state, handle reconnects, and resolve conflicting updates. Do not describe a local Attribute system as online asynchronous multiplayer.
Finish the single-device prototype first. If you later add networking, use a documented server workflow and test failure cases such as duplicate moves, dropped connections, and stale state.
Build a turn system you can inspect
A small board with two units can teach selection, conditions, state, UI, action resolution, turn order, winning, and restart. Once those rules work reliably, expand the board or add another action.
