How to Scope a Mobile Game Prototype on iPad

A mobile game prototype should answer one design question with the smallest playable build you can make. On iPad, that could be one Scene, one control, one obstacle, and a restart. You do not need market forecasts, finished art, or a long feature list to learn whether the core mechanic works.

Use this process to turn a broad mobile-game idea into a hyperPad Project you can build and test.

Write the mechanic in one sentence

Describe what the player does and what changes.

Examples:

• Tap to keep a character between two obstacles.
• Drag shapes into matching spaces before the timer ends.
• Swipe left or right to avoid incoming Objects.
• Choose one card, then show how it changes the opponent’s health.

If the sentence contains several systems joined by “and,” choose one. The first prototype is a test, not the full product.

Choose one design question

Decide what you need to learn.

• Can a new player understand the control?
• Is the jump height predictable?
• Does the puzzle rule create a meaningful choice?
• Can the player read the score feedback?
• Does one round end at the right time?

One question gives the prototype a finish line. Features that do not help answer it can wait.

Set a small content limit

A useful first scope could be:

• one Scene
• one player Object
• one input
• one goal
• one fail condition
• one restart
• placeholder Graphics
• no account, shop, inventory, or online system

For a tap-to-jump prototype, build one short obstacle sequence. The player should be able to start, fail, restart, and reach the finish in under a minute.

Map the Project before building

In hyperPad, list the parts you need.

The Scenes guide explains how a Project is organized. The Behavior Editor overview explains Events, Actions, and connections.

Build in testable steps

Add one working connection at a time.

1. Make the player respond to input.
2. Add one obstacle and confirm collision.
3. Add the fail state.
4. Add restart.
5. Add the finish.
6. Show one piece of feedback.

Press Play after every step. If the prototype stops working, the most recent connection is the first place to inspect.

Use placeholder assets

A colored shape can stand in for a character. A rectangle can be a platform. A Label can show state while you debug.

Finished assets take time and can make you reluctant to change the design. Replace them only after the mechanic produces a result worth developing.

If the project needs original art later, use the iPad art and sound workflow to plan the asset pipeline.

Test the design question

Ask one person to play without explaining the control. Watch what they do and record the result that relates to your question.

If the question is “Can a new player understand the control?”, useful observations include:

• where they touch first
• how many attempts occur before the first successful move
• whether they ask for help
• whether they can restart without instruction

Do not treat one session as proof of market demand. It is evidence about this build, this tester, and this question.

Use the prototype feedback guide to structure the session.

Decide what happens next

After the test, choose one outcome.

Revise

The mechanic shows promise, but one clear problem blocks it. Change that problem and test again.

Expand

The mechanic works well enough to add one related feature, such as a second obstacle or clearer feedback.

Stop

The mechanic does not create the intended experience, or the cost of fixing it is larger than the opportunity. Record what you learned and try a different idea.

Stopping a prototype is not a failed project. It prevents a weak concept from consuming more production time.

Build the smallest playable proof

Use one Scene to answer one design question, like whether a tap feels good or whether a level runs too long, before you plan the full game.