Design Document

Discussion in 'Indie Basics' started by ProgrammingFreak, Apr 22, 2006.

  1. ProgrammingFreak

    Original Member

    Joined:
    Oct 22, 2005
    Messages:
    126
    Likes Received:
    0
    I am confused on how you go about making a game design document. Like how you put the code you will write or how the graphics will work and stuff can someone help on this.
     
  2. RWgames

    Original Member

    Joined:
    Jan 26, 2006
    Messages:
    24
    Likes Received:
    0
    IMO there are different types of design documents. There's the general overview of the game such as features, size, level designs, characters, story etc... Then there's a techincal design in which there's detail on how each aspect will be created. I don't necessarily add real code to my techincal design document, just the odd pseudo code. The techincal design would describe how you are going to go about implementing the aspects you've written in your design documents. This can be done in various ways such as writing down the order in which your will write things. Or you may write down the different classes you will use, and in turn, what these classes consist of. However, there are no set rules in design documents as they are only there for you, as the developer, to use as reference and to make things easier in the long run. This means that other people might have different ideas on how to write design documents, but this is the method I use. There are various books available, but I've never read them, so maybe someone else can make recommendations. :)
     
  3. Christian

    Original Member

    Joined:
    Mar 22, 2005
    Messages:
    769
    Likes Received:
    0
    Yes there are various ways, most of them are for big corporations that require a document for all members to follow, indies dont need this, they need other kind of document, a more personall one, not so complex since its just for yourself.
    I for example have notebook where i go doing my game design, i write ideas, i develop the mechanic, i write what the graphic should do, etc, and after that i write a more ordered design so i can know how to programm all that, so i have two parts of it, one with the game design, and another part that says how should i programm all that, but its really not very ordered, i couldnt expect to show it to someone else and understand it, so it just for myself, as a guide, to not forget about things, to decide what things should go and what not, etc etc. Do it as you feel most confortable with.
     
  4. Blue Falkon

    Original Member

    Joined:
    Apr 11, 2006
    Messages:
    39
    Likes Received:
    0
    One I found at GameDev is Alex Okita's "EmberScribe", though it's a commercial design document that was created for the Nintendo DS. It's the most professional design document I've ever seen and it's excellent to look off for help. Unfortunately, I don't know where you can get a link to it and the file is on my computer. It's 1.5 MB so I can't upload it onto this.

    Just write down all the basic details about the game you're making as well as artwork and diagrams to give a better idea about it if you're going to show it to your team. Explain game mechanics, towns and dungeons (if it's an RPG), how menus work, what buttons do, etc.

    Most design documents span over 50 pages. I'm not even on the real details of my game and I'm on page 15 at the moment (although I have a huge project).

    Hopefully you'll have good luck with it.
     
  5. mahlzeit

    Original Member

    Joined:
    Sep 26, 2004
    Messages:
    852
    Likes Received:
    1
    I'm not a big fan of design documents (they are usually wrong) but if you make one, always keep in mind that your goal is to write a game, not a design document. It's very tempting to spend all your time creating a kick-ass document, but that is time you could have spent on the actual game code and assets. It's the game that makes you money, not the design doc, so keep it in perspective.
     
  6. RWgames

    Original Member

    Joined:
    Jan 26, 2006
    Messages:
    24
    Likes Received:
    0
    http://www.okita.com/ES/EmberScribe_CompleteDesign_2005-06-03-1955.pdf
    Looks interesting.
     
  7. Blue Falkon

    Original Member

    Joined:
    Apr 11, 2006
    Messages:
    39
    Likes Received:
    0
    Haha, thanks. That'll help.
     
  8. ProgrammingFreak

    Original Member

    Joined:
    Oct 22, 2005
    Messages:
    126
    Likes Received:
    0
    Thanks, now I have a better understanding of the design document
     
  9. Game Submit

    Original Member

    Joined:
    Apr 20, 2006
    Messages:
    11
    Likes Received:
    0
    Great find! Looks just like a business plan to e-mail to publishers! This is the best design document and business plan I have ever seen (not that I have seen many :) )

    I think the most important takeaway is market research before the game.
     
  10. alexokita

    alexokita New Member

    Joined:
    Dec 17, 2006
    Messages:
    2
    Likes Received:
    0
    Wow, glad to see that people still find the doc interesting. It's actually not all that much of a commercial effort. The posted version is just an effort while I was between jobs.

    I'm still planning on expanding on it, making a ton of corrections, and fleshing out the story over the next few months. My office just got a DS development license, so I'm going to make the most of this opportunity.

    If anyone is interested I also started a blog of my own. http://alex.okita.com/ just started posting to it. I havent even really done anything about the default wordpress look to it. That'll change... when I have the time to do it.
     
  11. John Cutter

    John Cutter New Member

    Joined:
    Dec 12, 2006
    Messages:
    37
    Likes Received:
    0
    What a great design document, Alex! Very professional.

    I spent the first 23 years of my career designing and producing retail games, and I have to tell you that one of my favorite things about working at Big Fish is that I no longer have to write 250 page design documents whose primary purpose is to impress management and/or a publisher.

    Now my design documents are much smaller and they are intended ONLY for a small team of artists and programmers. Purely functional. No fluff.

    Of course, when I start on a new game, of any kind, I always write down the things that excite me about the concept and I refer to this list frequently during development. This is very important because I've seen projects that start with a cool idea and then stray wildly off course. Does anyone remember Interplay's "Castles"? For a late-80's title the premise was very cool: design a castle and then defend it from enemy attacks! But the development team probably thought it would be interesting to see little workers actually *building* the castle, and that begged the question of where the workers were getting the materials, so the developers added resource gathering and management. And by the time the game was released it had turned into a very slow-paced castle building simulation. When I bought the game I assumed that I would be able to drag my mouse across the screen to create walls, but instead I had to direct my workers to construct each wall, brick by brick. I was bored to tears after five minutes.

    On a somewhat related note, I also find it invaluable to create a list of design goals and keep it handy. What are the major features I want to include? What audience am I trying to reach and why will my feature list appeal to this audience? And so on...

    I'll also make a list of "audience reference" points. In other words, what images and ideas can I subtly invoke to create a feeling of familiarity in my players? (At least as a starting point.) If I was making a submarine game, for example, I would watch some popular films that include submarines ("The Hunt for Red October", "The Abyss", "Das Boot", "The League of Extraordinary Gentlemen") and I'd make a list of things that people, because of these films, have come to expect in submarine-based entertainment: red lights, depth charges, etc.

    (NOTE: Even if I'm going to stray from these reference points it's good to know what my players are likely to expect based on the subject matter.)
     
  12. alexokita

    alexokita New Member

    Joined:
    Dec 17, 2006
    Messages:
    2
    Likes Received:
    0
    Ah yea! castles was great! They have an arcade cabinet of that game at bungie studios over in seattle. There was a bungie team (right around when halo 1 was in development when I was there.) Working on a title called phoenix which was basically a physics driven version of castles. Would have been fun but it had a 300 page document filled with "it would be cool if..." in the end i think it got canned for being too ambiguous/ambitious.

    Focus is really important, not only for the content of the title and the sake of the programmers, but for the focus of the artists on the title. Part of that is why, especially with next-gen titles, the concept art and design doc should look slick.

    Getting the artists involved excited to work on a product is more important than ever. Sure on a title like castles the art isnt really all that important. But for a modern title like gears of war or something like stranglehold, the art has to be eye-catching as to be able to capture the attention of the buyer.

    Mind you this is really dependent on the scope of the game. For Emberscribe the target platform is a nintendo ds, not really the realm of the high res normal mapped shader heavy art, but it's still has its style, and it still has to excite the people building content for the title.

    Cell phone games are also at the disadvantage of being so low res. In the current trend of high res game art the artists working on cell phone games tend to feel under-utilized. good concept art will help keep artists inspired so to speak.

    (this is just form the point of view of an artist/technical director/programmer working on games.(mostly artist))
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer