Questions or Comments? Go ahead and e-mail me: blog@beerandgames.com

For updates and goings ons, Check out the Blog part of the site: http://blog.beerandgames.com

So you've got a great idea for a game. Now what?

Perhaps the most daunting task of making a game is actually getting started on it. There's a lot to do and while there's some really great resources out there on the net I've noticed most of them assume certain amounts of prior knowldge. My goal with this site is to lead you though the game design process and (hopefully) explain the "Whys" of what you're doing instead of just telling you to do it.

So that being said there's a few things I should probably explain up front:

 

Before you jump in I want to present a little 'document flow chart' if you will. This will be a list of seperate documents and a short general term on what they're for (and some of what they're not). If you haven't read though everything here the flow chart won't make total sense, but as you go through the steps you can refer back to it to get a better sense of how all this stuff fits together. So Head on over to The Anatomy of Documents, we'll be waiting for you when you get back.

With that out of the way. On with the show!

Step 1 - The Idea:

"I've got the greatest idea for a game"

To be completely honest there's thousands of good ideas out there. Don't think too highly of yourself just yet. What seperates a bad idea from a good idea is execution. A deritive clone of an existing game is a better idea by default than the awsome game you thought of that never got made.

First off you need to ask yourself something. Is the idea you have a good GAME idea? or is it a good STORY idea? It's very easy to get wrapped up creating worlds and characters and completely forget you're trying to make a game. If the world and characters are interesting, it certainly can make a game better. However if the gameplay is crap who's going to sit around and slog through it to get to these great story elements? If all you have is story and no game, you're better off writing a book.

If a random person asks you what your game is about. You should be able to provide the following:

  • What does the player do?
  • How do you want the player to feel?

    • The former could also be asked "What are the mechanics of the game". Mechanics cover the actual movements and operations of the game. In "Super Mario Brothers", these are things like movement, jumping, being able to jump on things, breaking blocks, etc. All the activities the player is able to perform. Later we will broaden the definiation to include all the little touches you put in as a designer (how long is the character in the air, how far can they move, etc). The deeper nut and bolt mechanics like that I will refer to as 'designer mechanics'. But for now we'll just focus on the top level design and for clarity we will refer to them as 'Player Mechanics'.

    The second bit is just as important as the first but is often over looked. These are considered the Asthetics of the gameplay. Two games can share very similar mechanical design but evoke completely different sets of emotions from the player. Are you trying to provide the player with a slow methodical thinking experience? Or are you trying to make an adrenaline pumping test of speed and dexterity? The asthetics you're aiming for will ultimately affect how you implement your mechanics in a later stage as well as which mechanics become the primary focus of your game. Laying out solid asthetic goals is a great way to give yourself a litmis test for later use. Now when you add a feature you can ask yourself "Is this feature good for my asthetic goals, or do I just want to add it because it's 'cool'". If it's a good idea but works against your asthetic goals, you're better off leaving it out.

    So with all that in mind we're going to move onto the first and most important document you're going to write.

    Step 2: The One Sheet

    The “One Sheet” aka “Pitch Sheet” aka “Waste of time” (Not really, but a lot of people tend to think of it as one, I contend otherwise.) The usual use of a document like this is to sell your game to a publisher and generate interest. To explain your game in the shortest amount of time possible. Due to that nature I find it's also a great tool for quickly explaining your core design goals to other team members so that everyone has a similar view of the project. Not so much what the game is about, but at the most basic level, what is the game trying to accomplish.


    Essentially you're going to be using your Player Mechanics and Asthetic ideas you thought up in step one and gel them into the 'game experience'.


    So Here we go.


    The document contains only four headings:


    Introduction, Description, Key Features, Genre, Platform


    1.

    Introduction:

    This is a one sentence description of your game. Despite only being on sentence this is probably the toughest bit to write. You're trying to distill your game down to a very basic essence. Each word carries a lot of weight in this portion and you have to choose your words carefully. Pick your adjectives and verbs carefully. Generally speaking you will find the adjectives you use evoke your asthetic principals, and the verbs you choose will help convey your mechanical goals for the player.


    Also a key point here is you're NOT discussing designer mechanics. If you were for instance, describing Tetris. How the blocks move, or even what the blocks are is largely irrelevant. That's a deeper mechanical discussion.We just need to get the general idea that the player is doing something.


    You can say something like “Tetris is a 2d puzzle game that challenges players reflexes and mental dexterity as they try to best their high score or beat out the competition.”


    So what do we know about Tetris? Nothing right?


    Well if you look we know the following facts:


    a) It's a 2d Puzzle Game, we now know it exists on the X and Y plane only, and it's a puzzle game.

    b) Challenges players reflexes and mental dexterity. We know it's going to require fast movements on the part of the player at some point, and we know its going to require them to figure something out. This is in contrast to something like bejeweled that for the most part allows a lot more 'think time' so we immediately know the game is more action based.

    c) The goal is to get a high score, and there is some form of competitive aspect. We didn't say the game was multi player, so its not concurrent multi player, but we know it keeps track of scores of different players.

    Now we know what sort of game it is, what direction its heading, but we don't really know all that much more about it. So on to;


    Description:


    This is the meat of the first page and will vary in length depending on the game, but it should all still fit on the first page. Again, no specific designer mechanics. The goal of this section is to describe what it is like to play the game. What do you do in the game? Key focus on YOU write it as if the person reading the document is the player.


    This is sort of the back of the box PRish write up. You are now a shill, SELL me on your game. Don't tell me how great it is though, describe what the reader is going to be doing, describe what sort of situations they will find themselves in.


    If you've ever read a vacation description, its not that far off.


    From a Cruise Line website


    “Maybe it's the fact that you're greeted by name. Perhaps it's because you merely mentioned a favorite dessert and it appears without your asking. As you cool off with chilled towels upon your return from a shore excursion, you just know something is different aboard Celebrity.

    With one staff member for every two guests, Celebrity's personal service anticipates your every need. In your stateroom, outside by the pool, in the AquaSpa®, anywhere at all, at anytime, our onboard family goes the extra mile to ensure every aspect of your cruise is just the way you want it.

    Combining traditional European hospitality and warm engaging service, Celebrity's service is consistently top-rated by such experts as Condé Nast Traveler. “


    Notice the liberal use of 'you'. They're describing the experiences you're likely to encounter when you go on their Cruise line. But they're also giving you information about some of their points of service.


    Mixing experience and features is the goal of this section. Which leads to:


    Key Features


    This ones easy “Multiplayer, Cooperative Gameplay, Challanging NPC's, Extensive Campign Mode, etc.” These are back of the box bullet points that will be in the game.


    Genre


    Been mentioned before, but reiterate and clarify. And finally we leave of with”

    Platform


    Pretty basic.

    So that's it.


    Formatting is nothing too special, for sake of uniformity we'll say:


    --------------------------------------------------------------------------------


    Introduction:


    Introduction Goes Here.


    Description:


    Description Goes Here.


    Key Features:


    Key Features Go Here.


    Genre:


    Genre Goes Here


    Platform:


    Platform Goes here.

    Remember, ONE PAGE.


    If you go over, find a way to cut it down, write it over several times, trim the fat. Each sentence you write should be either telling the person about the gameplay or the features. NO DESIGNER MECHANICS! No button presses, no hit points NOTHING.


    After reading this sheet every single person on the team should have a good understanding about the games goals and directions. Keep this document around so that when new ideas are on the table you can reference this sheet and check new features against your asthetic and mechical goals to see if the idea fits with the vision of the game. This will help you to avoid the number one destroyer of games 'Feature Creep'. (Feature creep is a term that describes the process of continually adding new features to a game well past the point where you should. It delays the processes, muddies the message, and wreaks havok on your schedules.)

     

    Step 2: The Design Document

     

    Alright, so we're on a roll! We've got an excellent concise vision for our game. Now what?

    Well, it's time to start putting it all in a design document. Design docs are different everywhere you go. Some of them are a couple of pages, some end up being the size of a phonebook. Those are bad and probably contain a lot of information a design document doesn't need.

    Generally speaking your Design Document should be an extension of your "One Sheet". If your "One Sheet" is your goal, the "Design Document" can be seen as your plan. It should contain specific features, mechanics, and implementations. This is where you get to say the 'How' to follow your 'What'.

    This document will also get into some light technical discussion, but nothing specific. With each new document we introduce you'll see we flesh out the things previously mentioned in the document before, and slowly introduce new ideas and concepts that will be fleshed out in later documents. The further down the chain you go in the Document Tree , The more specific things get.

    So some things you'll want in your Design Document:

  • Start off with your name and logo, it's flashy.
  • Follow that with a Table of Contents, this document could get big
  • Restate your Introduction
  • Expand on your Descriptions with some more specific mechanical discussion. You should now be answering all the questions anyone would have about how the game is PLAYED. What moves does the player have. How does the save system work, what do the buttons do? How does the player progress. What sort of weapons and vehicles are involved.
  • Expand your Key Features, introduce sub features, and layout an overview of how they're going to be implemented and work together. Dialog systems, combat, weapons. All this stuff should be gotten into now.
  • Expand your Platform discussion. Mention not just platform but engine and middleware tools. Are you building an engine from scratch? Are you planning on using Torque Game Builder? Things like collision and rendering will be gotten into here. But again, this is a brief introduction and should be about WHAT they do. Specifics on these systems and HOW they work is saved for Technical Design Documents written by coders.
  • Introduce your Game World. Where does the game take place, what does the world contain. What are the key locations, how does traveling work, is there a day and night cycle, how is time treated?

    • Essentially by the time this document is done, all the designers should be able to read it and know WHAT is in the game and what pieces are needed. The programmers should be able to read it and reach the same understanding about what they need to build to get it to work. All the games features should be in an contributing to the main asthetic goal of the game.

    If a designer says "Well I thought our game was supposed to do X" and 'X' isn't in the design document, then no, the game isn't supposed to do that.

    A good start for this is Chris Taylor's Design document. A quick google search should net you a copy. At some point I'll make my own template but as a time saver his will do nicely *yoink*.

     

    Next time:

     

    We'll go into the design bible, but the Design Doc part needs a lot of work (hopefully what I said makes sense and gets you going). So I'll probably go over that a bit more and flesh it out along with a functional example.