The game design process is the set of stages a team goes through to turn an idea into a finished game. Most modern game teams use an iterative process: they build a small version of the game, test it with players, improve it, and repeat until the game is fun. A popular approach built on this idea is Rapid Application Development (RAD).

Stage 1: The creative process

Every game starts with ideas:

• Brainstorming – a group discussion where everyone suggests ideas freely, without judging them at first.
• Ideation – developing, combining and choosing the best ideas, then describing the core concept (for example: “a puzzle game where you rotate the world to guide a ball home”).

Stage 2: The iterative process

Instead of planning everything and building the whole game at once, the team works in short cycles:

1. Rapid prototyping – quickly conceptualise, design, code and test a rough playable version (a prototype). Prototypes can even be made with paper, cards and dice before any code is written.
2. Play test – real players try the prototype while the team watches and takes notes. Is it fun? Confusing? Too hard? Are there bugs?
3. Revision – change the design based on what was learned: fix problems, remove what does not work and improve what does.
4. Repeat – build the next version and test again. Each cycle is called an iteration.

What is RAD?

Rapid Application Development (RAD) is an approach to software development that puts less emphasis on detailed planning up front and more on building working prototypes quickly and changing requirements as the team learns. The term is also linked to James Martin, who described a RAD method in the early 1990s. In games, RAD fits naturally with rapid prototyping and playtesting.

Plan-based methods: the waterfall model

Plan-based methods do most of the planning before development begins. The best-known is the waterfall model, where each stage is finished before the next one starts: requirements, design, implementation, verification (testing) and maintenance.

RAD vs waterfall

	RAD / iterative	Waterfall
Planning	Light planning at the start, refined as you go	Detailed planning at the start
Change	Changes are expected and welcomed	Changes are difficult and costly later on
Testing	Early and often, with real players	Mainly near the end
Working version	Available early (prototypes)	Only near the end
Best for	Projects where the “fun” must be discovered, such as games	Projects with clear, fixed requirements

Advantages of RAD in game design

• Problems and boring gameplay are found early, when they are cheaper to fix.
• Player feedback shapes the game, so it is more likely to be enjoyable.
• The team always has something playable to show to publishers, investors or clients.
• It is flexible when ideas, technology or the market change.

Disadvantages of RAD

• Without discipline, the project can keep growing (“scope creep”) and miss deadlines.
• It needs regular involvement from testers and decision-makers.
• Quick prototype code may be messy and need rewriting.
• It can be harder to predict the final cost and finish date at the start.

Example

Our Scratch game tutorial builds a game step by step, testing after each part, which is a small example of iteration: A simple game! For a team project, try Group Project – Create a Game in Scratch!

Video

Game Maker’s Toolkit explains why and how to prototype a game, including quick paper prototypes, before building the full thing.

Exercise

1. In a group, brainstorm at least 10 game ideas in 10 minutes. Choose one and describe its core concept in one sentence.
2. Make a paper prototype of your idea and play test it with another group. Write down three changes you would make.
3. Explain why an iterative (RAD) approach is often better than the waterfall model for making games.
4. Give one situation where the waterfall model might be a better choice.

Syllabus link: This post is relevant to the CAPE® Animation and Game Design Syllabus, Unit 1: Fundamentals of Animation and Game Design, Module 1: Understanding Animation and Game Design – Specific Objective 21 (“identify the main stages of game design”); Specific Objective 22 (“explain the importance of RAD in game design”).

Attributions to media used in this post:

Iterative development model.svg – Aflafla1 – CC0 (via Wikimedia Commons)

Diamond Trust of London – Paper Prototype.jpg – Jason Rohrer – Public domain (via Wikimedia Commons)

WikiGameJam SF 2025 – Playtesting.jpg – Kevin Payravi – CC BY-SA 4.0 (via Wikimedia Commons)

Waterfall model.svg – Peter Kemp / Paul Smith – CC BY 3.0 (via Wikimedia Commons)

© 2026 Vedesh Kungebeharry. All rights reserved.