Planning your game: the Design Document

You’re set. You’ve chosen a language and a webhost, and now you’re ready to sit down and start hacking away at building your game. You’ve got a pretty cool idea that you’re excited to turn into something.

A browsergame is a pretty big undertaking. Where will you start?

For a lot of people, that one question stumps them, and they stop there.

That’s why it’s important to plan ahead, before you just dive head-first into writing your code. Are users going to need to sign up? What kind of game will it be? What sorts of items will be available? These are all questions you’ll want to answer sooner, rather than later.

The best way to start planning your game is to get a piece of paper and a writing utensil(or create a text document), and just write out everything you can about your game, as clearly as possible. Write everything, whether it’s how users sign up, to what sort of stats they start out with, to what each page on your game’s site will do. You need to write everything out.

When this is done, you should have a pretty big document – and it should have everything you need to know to build your game on it. If it doesn’t, you need to go back and add it. Keep doing this until there is absolutely nothing left that you can write about your game – every piece of unique gameplay is on that page, and every little action a user can take is on there.

This will be your Design Document. When you’re starting a project, you should always write one of these – it will help you keep track of what your goal is for your game, along with allowing you to sit down and plan everything out first. It will also allow you to quickly gauge whether or not this is the right idea – you will quickly see just how much work will go into building your game(whether you decide to do it or not afterwards is completely up to you).

Your design document is the guide to writing your game. It should be so complete that, if you were to get hit by a bus tomorrow, someone else could use it to finish your game, exactly the way you wanted it.

The design document will actually serve two purposes. To begin with, it will help you get everything figured out for your game. And secondly, it will help you prevent something known as “Scope Creep”.

Scope creep is the process of a project growing from being something small and managable to being a huge pain that you can’t actually work on. Usually it starts with small, often innocent statements like “it would be cool if…”, and you end up adding features and ideas to your original design. If you want to get your game finished, you need to do your absolute best to prevent scope creep – it’s killed a lot of promising projects. Your design document will help you do this, by providing you with a guide – any time that you think of a new feature to add, check if it’s on your design document. If it’s not, seriously consider whether you need that feature now, or you’d be better off adding it later. In most cases, you are better off adding it later – as long as you can get something out the door, you’ll have something to build off of for when you add those features later.

As long as you have a design document, you have a clear idea of what your game will be like, and what you need to do to build it. As far as planning is concerned, that’s one of the best tools you have at your disposal to help you build your idea out into a fully functional browsergame.

Wish there was more?

I'm considering writing an ebook - click here.


Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Wednesday, April 30th, 2008 design
  • I agree completely.
    This is how I started. I'm not a coder. I can do html but thats it!
    I had some extra time on my hands and had played pbbg's for a while and I just started putting together all the things I had been thinking of for years. Things like "Why can't I do this?" and "Why does it have to be like that, why can't it work differently?"

    My original game document is 39 pages, single spaced. Nearly a year after the game's release and we've added all but one of the features in it. Lots more planned, but I use smaller docs focused on a single update.
    I used Word's headers and the Document Map to help organize it all.

    For any would-be designers I would GREATLY suggest checking that out. I have my headers short-keyed Ctrl+Alt+1, 2 or 3 for headers 1, 2 or 3.

    Enjoyed what you had to said :)

blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at