My kid wants to make a video game. Where do we start?
The honest answer is smaller than the question. Most first attempts fail for one reason — the game was too big to finish — and almost everything written about this topic is a sales page for a course. Here is how to scope a first game your child can finish this week, the four routes in with what each actually costs, and an honest read of what the research says learning to code does and does not do.
The first game should be embarrassingly small
Your child does not want to make a game. They want to make the game they are currently playing, which took a studio of two hundred people four years. The gap between those two sentences is where most first attempts die, and the fix is not more ambition or a better tool. It is scope.
A finishable first game has one mechanic, one screen, and one way to win. Something falls and you catch it. Something chases you and you dodge. You jump over a gap. That is the entire design document. It sounds insultingly simple and it is the thing that separates a child who finishes something on Saturday from a child who has nine abandoned projects and has concluded they are bad at this.
The reason to protect that smallness is motivational rather than technical. A finished small thing can be shown to someone, and that is most of why a nine-year-old comes back to it on Sunday. When your child says "but I want it to have levels", the answer is yes — in version two, after someone has played version one.
The four routes in
Ranked by nothing: these suit different children and different households. The right-hand column is the one the course pages leave out.
| Route | What it is good at | The honest catch |
|---|---|---|
| Scratch, free, in a browser. | The default for a reason. Free — the Scratch Foundation states plainly "Scratch is free for everyone" — with a huge library of existing projects to open up and change. | No one teaches your child to scope. The tool will happily let them start the four-year game. Also worth knowing: the Foundation’s own page states no minimum age, despite every listicle quoting one. |
| A drag-and-drop game maker app. | Fastest route to something playable, often inside an hour, which is exactly right for a child whose interest is a short window. | The faster the tool gets you to a finished game, the more of the game it made. Fine as a first taste; a poor diet if it is the only thing. |
| A paid class or club. | Structure, a deadline, and other children — which solves motivation better than any tool choice does. | The most expensive option, and the research below does not support the "it will make them better at school" promise that often sells it. Buy it for the structure, not the transfer. |
| Building it with an AI, alongside you. | Removes the typing barrier that stops a lot of seven-to-ten-year-olds before they start, and keeps the child in the designer’s seat. | The failure mode is obvious and real: the AI makes the game and the child watches. Worth doing only if the child is the one deciding what happens next and saying why. |
Start by changing something that already works
The most reliable first session is not a blank project. It is opening someone else’s finished game and changing one thing — the jump height, the colour of the thing you catch, how fast it falls. The child gets a working game in minute one and immediate evidence that their change did something.
There is real evidence behind this instinct rather than just folklore. Dasgupta and colleagues looked at more than 2.4 million projects from over a million Scratch users and found that people who remix more often have larger repertoires of programming commands, even after controlling for how many projects they made and how much code they shared — and that meeting a new concept through a remix was associated with being more likely to use it later. Two honest caveats: it is observational, so it shows an association rather than proving the remixing caused the learning, and the children who remix the most may simply be the ones who were already the most engaged.
That approach also matches what Scratch was designed for in the first place. Its design paper argues that "digital fluency should mean designing, creating, and remixing, not just browsing, chatting, and interacting" — which is a statement of intent by the people who built it, not a measurement of outcomes, and should be read as the former.
Coding games for kids: the tools, compared · Which language, and when blocks stop being enough
What a finished small game looks like
Two games built with Luchi. They are deliberately the scale this page argues for — one idea, one screen, playable in a minute — and they are shown rather than described so the claim is checkable.
What this will and will not do for them
Worth being straight about, because the pages selling classes are not. The largest synthesis on this question — Scherer and colleagues, pooling 105 studies and 539 effect sizes — found learning to program does transfer to other thinking skills: a moderate overall effect of g = 0.49, stronger for skills close to programming itself (g = 0.75) and still moderate for more distant ones (g = 0.47), with positive transfer to creative thinking, mathematical skills and metacognition.
Now the parts that rarely make it into a brochure, from the same analysis. "School achievement and literacy, however, benefited the least from learning to program" — which are, of course, the two outcomes a worried parent is usually being sold. The transfer effects were significantly larger in studies that compared programming against an untreated control group than against an active one, meaning part of the measured benefit is "doing a structured activity" rather than "programming" specifically. And published studies showed larger effects than unpublished ones, the signature of publication bias.
So: a real effect, more conditional than the marketing, and weakest exactly where the marketing is loudest. The better reason needs no study behind it. They want to make something, finishing it is hard, and a child who finishes something hard learns something that does not depend on an effect size.
The research under this page
Four sources, one of which argues against the usual pitch for this activity and is cited for exactly that. None of them studied a parent and a child making a game at a kitchen table on a Saturday, which is the limit on all of it.
- Scherer, Siddiq & Sánchez Viveros, 2019 — The cognitive benefits of learning computer programming: a meta-analysis of transfer effects. Journal of Educational Psychology, 111(5), 764–792. (105 studies, 539 effect sizes: a moderate overall transfer effect, g = 0.49; near transfer g = 0.75; far transfer g = 0.47. "School achievement and literacy, however, benefited the least from learning to program." Transfer effects were significantly larger in studies with untreated control groups than with active ones, and published studies showed larger effects than gray literature.) The transfer figures, and — more importantly here — the three caveats: school achievement and literacy benefit least, the largest effects come from untreated-control comparisons, and published studies show larger effects than gray literature. What it does not show: CITED FOR ITS CAVEATS AS MUCH AS ITS HEADLINE. The transfer is real, but the biggest effects come from the weakest comparisons and from the published half of the literature, and the two things a parent most often hopes for — school achievement and literacy — are where it helps least. It does not license "coding makes your child better at school".
- Dasgupta, Hale, Monroy-Hernández & Hill, 2016 — Remixing as a pathway to computational thinking. Proceedings of CSCW ’16, 1438–1449. (More than 2.4 million projects from over 1 million Scratch users: users who remix more often have larger repertoires of programming commands even after controlling for the number of projects and the amount of code shared, and exposure to a concept through remixing is associated with an increased likelihood of using it.) The basis for "start by changing something that already works". Large-scale and well controlled for a correlational study, but still an association in one online community, not a causal finding. What it does not show: Observational data from one online community, and the authors state their result as an association. It supports "starting from someone else’s project is a real way in", not "remixing causes learning" — the children who remix most may simply be the children already most engaged.
- Resnick, Maloney, Monroy-Hernández, Rusk, Eastmond, Brennan, Millner, Rosenbaum & Silver, 2009 — Scratch: programming for all. Communications of the ACM, 52(11), 60–67. (The design paper for Scratch, whose thesis is that "digital fluency should mean designing, creating, and remixing, not just browsing, chatting, and interacting".) Cited only for the design intent behind block-based tools — a position paper by the tool’s own authors. It is not evidence that any child learned anything, and this page does not use it as if it were. What it does not show: A design and position paper by the tool’s own authors, NOT an outcome study. It is evidence about what Scratch was built to do and why; it measures nothing about what any child learned, and must never be cited as if it did.
- Weintrop & Wilensky, 2017 — Comparing block-based and text-based programming in high school computer science classrooms. ACM Transactions on Computing Education, 18(1), 1–25. (A 5-week quasi-experimental study: both conditions improved, students in the blocks condition "showed greater learning gains and a higher level of interest in future computing courses", while students in the text condition "viewed their programming experience as more similar to what professional programmers do and as more effective at improving their programming ability". No difference was found in confidence or enjoyment.) Used for the blocks-versus-text trade-off: blocks produced greater learning gains and more interest in future computing, while the text group felt their experience was more like real programming. High-school students, so the shape transfers and the numbers do not. What it does not show: High-school students in an introductory class, several years older than this page’s reader. Used only for the shape of the trade-off — blocks taught more, text felt more real — and never quoted as gains a nine-year-old would show.
- Scratch Foundation, read 30 October 2026 — Scratch Foundation home page. ("Scratch is free for everyone"; "200 million kids create on Scratch for free"; "Scratch was developed at the MIT Media Lab in 2007 by a team of educational experts and researchers led by Professor Mitchel Resnick. In 2019, Scratch was transferred from MIT to the Scratch Foundation: an independent nonprofit"; projects are shared "in a safe, moderated online community".) Quoted for what the Foundation itself states — free, MIT Media Lab origin, moderated sharing community — and noted for what it does not state anywhere: a minimum age. Read 30 October 2026. What it does not show: The organisation’s own page, read on one date. Worth knowing: it does NOT state a minimum or target age anywhere, which is why this page does not repeat the "ages 8 and up" line that most articles about Scratch assert without a source.
Questions parents ask
- What age can a child start making games?
- Earlier than most pages imply, if the first game is small enough. Worth knowing that the "ages 8 and up" figure repeated across articles about Scratch is not something the Scratch Foundation states on its own page. A better test than age is whether your child can describe one rule for their game in a single sentence. If they can, they are ready; if every description runs to five minutes, the work is scoping, not waiting.
- Should my child use Scratch or a game maker app?
- Scratch if you want the learning, a game maker if you want something playable before the interest fades — and there is no wrong answer for a first attempt. The trade-off generalises: in a classroom comparison of block-based against text-based environments, the block group showed greater learning gains and more interest in future computing, while the text group felt their experience was more like real programming. Easier to use and feels more real are genuinely different axes.
- Will learning to make games help at school?
- Least of anything it helps with, on the best evidence available. A meta-analysis of 105 studies found a moderate overall transfer effect from learning to program, with gains in creative thinking, maths and metacognition — but it specifically reports that school achievement and literacy benefited the least. Let them make games because making things is worth doing, not as a route to better grades.
- Is it cheating if an AI writes the code?
- It depends entirely on who is deciding what happens next. If your child says "the ball should bounce faster each time" and the AI implements it, your child is doing the design and the debugging — the actual work of making a game. If your child says "make me a game" and watches, nothing is being learned and you will be able to tell, because they will not be able to explain what any part of it does. That question — can you explain what this bit does? — is the whole test.
Let them finish one
Luchi is built for exactly this: a kid describes the game they want, builds it a piece at a time with a coach that asks what should happen next instead of handing over a finished thing, and ends up with something real they can show you — plus a short note, in their words, about how they made it.
Part of the series: Coding for kids
Related guides in this series
- Coding with AI for kids — The new way kids build real games and apps — by telling an AI what to make and checking what comes back. What “coding with AI” actually means, and why it’s the skill that lasts.
- Coding games for kids — Kids learn to code fastest when they’re building a game they want to play. The best game-first ways to start — free, on-screen and off.
- The best coding language for kids — Scratch, Python, or something else? A straight answer by age — and why the first “language” that matters now is plain English to an AI.