Game Design Document Template for Kids and Teens

Last updated: October 2026

A game design document template for kids and teens should fit on one page. A game design document, or GDD, is a written plan for a game: what it is, who is in it, what the player does, and how it ends. Studios keep long ones. A young game maker needs eleven short sections, and the copyable template below can be filled in during a single sitting.

Key Takeaways

• A game design document is a written plan for a game. For a kid or teen, one page is enough.
• The template below has eleven sections, from a one-sentence log line to a list of ideas saved for later.
• Write it before building anything, then keep updating it as the game changes. Professionals treat it as a living document.
• Filling in the page is creative work in its own right: it is where the story and the feel of the game get decided.

What is a game design document?

A game design document is the plan a team builds a game from. Wikipedia's entry on the game design document calls it "a highly descriptive living software design document of the design for a video game," and describes it as something continuously improved throughout the project, "sometimes as often as daily." A studio version can cover story, characters, level design, gameplay, art, sound, controls and much more.

That is far more than a child needs, and short versions are nothing new. In a classic 1999 Game Developer article on the anatomy of a design document, Tim Ryan describes the concept document as "a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas." One page, brief and simple, is exactly the right size for a first game.

Why should a kid write one before building?

Because a game that lives only in a child's head changes every time they think about it. On paper it holds still long enough to be built.

I saw how much this matters with a teenage student who was building a game. Unprompted, the student went away and researched what a design document contains: a concept, a synopsis, a log line, world building, character sheets, flowcharts and a three-act structure. They came back having realised that this was the "story and vibe" work their game needed, the part that decides what the game is about and how it should feel. Nobody set it as homework.

That is the real case for a design document at this age. Tools can increasingly write the code. They cannot decide what your child's game is about. The page is where your child's own ideas live, and it gives them something to check the build against when the game starts drifting.

It often surfaces the real project too. The game a child names first is not always the one they care about, which I wrote about in the coding project your kid wants isn't the one they named. Filling in "the feel" and "what the player does" can bring the real one out.

What goes in each section?

Each section of the template asks one question. Here is what to write, with an example from an invented game about a hedgehog who delivers the post.

The story row is the three-act structure in kid-sized form: a beginning that starts the adventure, a middle where things get harder, an end that resolves it. The characters row is a tiny character sheet. The game flow row is a flowchart, and drawing it with arrows on paper is completely fine.

What does a one-page game design document look like?

Here is the full template. Copy it into a document, print it, or paste it into a text file at the top of the game's project folder.

GAME DESIGN DOCUMENT

Game title (a working title is fine):
Made by:
Started on:                    Last updated:

1. LOG LINE
   One sentence: who the player is, what they must do,
   and what stands in their way.

2. CONCEPT
   Two or three sentences. What kind of game is this?
   What does the player spend most of their time doing?

3. THE FEEL
   Three words for how the game should feel to play:
   1.              2.              3.

4. STORY
   Beginning (what starts the adventure):
   Middle (what gets harder):
   End (how it finishes):

5. WORLD
   Where does the game happen?
   Three rules of this world:
   a.
   b.
   c.

6. CHARACTERS
   The player character
     Name:
     What they want:
     What they can do:
     What they look like:
   One other character (a friend, an enemy or a boss)
     Name:
     What they want:
     How they help or get in the way:

7. WHAT THE PLAYER DOES
   The main actions, as verbs (for example run, jump, collect):

8. CONTROLS
   Key or button          What it does
   ...................    ....................
   ...................    ....................
   ...................    ....................

9. WINNING AND LOSING
   You win when:
   You lose when:

10. GAME FLOW
   List every screen in order and draw arrows between them.
   Title screen  ->  ...  ->  ...  ->  back to the title screen

11. NOT IN VERSION ONE
   Good ideas I am saving for later:
   a.
   b.
   c.

That is the whole page. Every line in it has a job, and nothing in it needs any coding knowledge to fill in.

How should a kid fill it in without getting stuck?

Start with the log line. If a child cannot write one sentence about their game, the idea is not clear yet, and that is worth knowing before any building starts. Everything else on the page gets easier once that sentence exists.

Fill it in during one sitting and leave blanks. A blank section is useful information: it tells you which part of the game has not been thought about yet. Come back to it later rather than inventing something just to fill the space.

Write the concept from the player's side. Tim Ryan's advice for describing a game is short: "Use the second-person perspective." It works well for children. "You race between houses as the sun goes down" is more vivid, and more useful, than "the game is about delivering letters."

Keep it to one page and put it somewhere visible. Game Developer's guide on how to write a game design document points to designer Stone Librande's one-page designs, which were inspired by the idea of documents people "would actually want to physically hang on their wall." A page pinned above the desk gets read. A long file buried in a folder does not.

Update it, and change the date every time. When the game changes, the page changes with it. That is what "living document" means, and it teaches a child that changing their mind is part of design rather than a failure.

For parents: ask questions about the page instead of editing it. "What happens if the dog catches you?" helps. Rewriting the log line for them does not. The page only works if it is theirs. Michelle, a parent whose daughter learned Python with me, wrote that "Completing challenges on my own was very motivating." A blank page a child fills in by themselves is exactly that kind of challenge.

Once the page is done, the next questions are which tool to build the game in and which parts to build first. I cover both in my guide to how a teen should start making their first game.

Frequently Asked Questions

What is a game design document? A written plan for a game, describing what it is, who is in it, what the player does and how it ends. Studios keep long, detailed ones that change throughout a project. For a kid or teen, a single page covering eleven short sections is enough.

What should a game design document include? At minimum: a log line, a short concept, the story, the world, the characters, what the player does, the controls, how you win and lose, and the order of the screens. A list of ideas saved for later is worth adding too, because it keeps the first version small.

How long should a game design document be for a kid? One page. Short enough to fill in during a single sitting and to pin above the desk. A long document for a first game usually means the game is too big, not that the plan is thorough.

What is a log line in game design? A single sentence that sums up the game: who the player is, what they must do, and what stands in their way. If a child can write it, they know what their game is. If they cannot, the idea needs more thought before any building starts.

Does this work for projects that are not games? Yes. The log line, the "what it does" section and the ideas saved for later work for any project. They fit the kind of Python projects kids actually want to build just as well.

Is making games a good way for kids to learn to code? Often, yes, if someone helps them carry the ideas beyond the game. I wrote a full answer in should kids learn game development first.

Want help turning the page into a game?

A filled-in design document is one of the best things a child can bring to a first lesson, because it shows me what they care about before we write a single line of code. Book a free Discovery Call and bring the page with you.

Written by Michael Murr for Kids Coding Tutor: online 1-on-1 coding tutoring for children ages 8 to 16, from Scratch to Python to AI.