Game design for kids, and telling a class from a play session

Game design is the class children ask for by name, and 8 of the 22 schools in this directory advertise it. It is also one of the hardest classes to judge from a brochure, because the same two words cover everything from writing real code to arranging characters somebody else drew.

This page is about the difference between a class that teaches your child to build a game and a class that lets your child play with one.

Design and programming are not the same thing

Game design is the creative side: deciding what the levels look like, how the character controls, what makes the game fun or frustrating, and how the art fits together. It is a real skill, and a child who is good at it is thinking clearly about rules and balance.

Game programming is the code underneath that makes those decisions actually happen on screen, the part that says what occurs when a character collides with an obstacle or a timer runs out.

Both are worth a child's time. The thing to catch is a class that only does the first while being sold, and priced, as the second. A term spent choosing backgrounds and placing characters is a legitimate creative activity, but it is not coding, and it is worth knowing which one you are booking before term starts.

What the common tools actually involve

Singapore centres tend to reach for the same handful of tools. Each one sits at a different point on the design-to-programming line, and it is worth knowing where before you book a trial.

Naming the tool on a brochure tells you almost nothing on its own. A Scratch class and a Roblox class can both be either a genuine coding lesson or a supervised play session, depending entirely on how the teacher runs it.

The age question

A 7 year old in a game design class is usually decorating and arranging: picking a background, placing a character, choosing what happens when it is clicked. That is a real, worthwhile activity, and it is closer to early Scratch work than to programming.

A 13 year old is old enough to be writing actual rules and logic: what happens on a collision, how a score is calculated, why the difficulty increases. If a 13 year old's game design class still looks like the 7 year old's, in that it is all decoration and no logic, the class has not moved with the child.

The honest version for most families is that game design is a strong hook at any age, but what a child gets out of it changes enormously between seven and thirteen, and a class that has not adjusted for that gap is not doing its job.

How to tell a good game design class

• The class can tell you which parts are design and which are code. A good centre can name the split plainly, for example "this week is level layout, next week is scripting the enemy." If a centre cannot separate the two for you, it may not be separating them for your child either.
• Children build different games, not the same one. Look at what the class produces at the end of a term. Ten identical games with different sprite colours means the children followed a tutorial. Ten different games means they made decisions.
• Your child can explain a rule they wrote themselves. Ask what happens if you lose in their game, and why. A child who can answer built the logic. A child who can only show you the game without explaining it may only have played it.
• There is a stated coding component, not just a game-making one. Game design alone is a creative and worthwhile skill, but it is not coding. If the class is sold as a coding class, ask what programming your child will actually write and how much of the term it takes up.
• The pace matches your child's actual programming background. A child who has never coded before will spend a Unity class fighting the software, not learning game logic. Ask what a child is expected to already know before the first lesson.

A fair question to ask any centre before signing up: "In a typical lesson, how much time is spent designing or decorating the game, and how much is spent writing or editing code?"

Three things parents get told that are worth questioning

• "They are learning game development." Game development usually means the full pipeline, including programming, art, sound and testing. Many classes teach one slice of that, most often the design and decoration side. Ask what part of development is actually covered.
• "This is real coding because it uses Roblox." Roblox Studio can involve real scripting, but a class can also use it entirely through drag-and-drop parts with no code written at all. The tool does not settle the question, the lesson content does.
• "Kids learn best when it feels like play." True, and also the exact sentence that makes game design easy to oversell. Enjoyment is not evidence of learning on its own. Ask what your child can do at the end of the term that they could not do at the start.

Where game design sits in the Singapore school system

It does not, and that is worth knowing before anyone sells it to you as preparation for anything.

We read both Computing syllabuses to check. The GCE O-Level Computing syllabus (7155) does not mention games at all. The GCE A-Level H2 Computing syllabus (9569) mentions a game exactly once, and not as a topic: it suggests a tic-tac-toe game as one possible scenario for a networking exercise on socket programming. There is no game design or game development content in either.

That is not a reason to avoid a game design class. It is a reason to buy it for what it is, which is an engaging way into coding, and not as exam preparation. If a centre implies it feeds the Computing syllabus, that claim does not survive reading the syllabus. Python is the language those two papers actually specify, which is a genuinely different case.

What actually carries forward

Enjoying game making does not by itself amount to a career path, and it is worth being straightforward with your child about that rather than letting a centre imply otherwise. What carries forward is not the game but two things underneath it: the programming, when the class actually includes programming, and the habit of finishing a project rather than abandoning it half made.

A child who has built and finished a handful of small games, even simple ones, has practised planning, debugging and sticking with something past the point where it stopped being new. Those transfer into more structured coding later. The game itself mostly does not need to survive the term for the class to have been worth it.

For a teenager who stays serious about it there are real local routes, including Nanyang Polytechnic's Diploma in Game Development and Technology and Temasek Polytechnic's Diploma in Immersive Media and Game Development. Both are post-secondary, which for a primary school child is roughly a decade away and not a reason to pick a class today.

In short

Game design earns a place in a child's coding journey when it includes real design decisions and real code, not just arranging assets someone else made. Ask a centre plainly how much of the lesson is spent on each, watch whether a child can explain a rule they wrote, and be wary of any class that lets the word "game" do all the selling.