Design document anyone?

Discussion in 'Game Development (Technical)' started by Gilzu, Jul 28, 2004.

  1. Gilzu

    Moderator Original Member

    Joined:
    Jul 27, 2004
    Messages:
    368
    Likes Received:
    8
    I'm redoing my latest game Goose Chase while designing the next one. One of the lessons i've learnt was to document everything before you go coding, thing is that it sounds so obvius what you have to document when you get stuck not knowing what to do when coding, but when you go document it before, your mind goes blank.

    So i've browsed a few gamasutra articles & postmorterms and also to check out how fellow Indies approach the design document. Do you do a formal one? draw "scenes"/"screenshots" from your view on the game? how detailed are the controls/moves/screens/options?

    -Gil
    http://www.gilzu.com/
     
  2. Jim Buck

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,158
    Likes Received:
    0
    When I had my own company, we created the a very detailed document for the game we were working on. It was around 115 pages and broke the game down as much as possible. It included tons of concept artwork and Visio-based drawings for the UI (was windows-based) as well as the flow of the game (just a basic flowchart). It decribed in painstaking detail everything that could happen in the game and when. Visual and sound effects were described in words accompanied with, when possible, screenshots of similar effects from movies, other games, etc.
     
  3. Mark Fassett

    Moderator Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    541
    Likes Received:
    0
    My design document for Derelict was just lists of stuff I wanted to put in the game, along with maybe a few text passages describing the basic gameplay. In many respects, I didn't document enough, as I had long discussions with the artist about what I really needed, mostly because I didn't know the answer. But in others, I think the game turned out far better than it would have if I'd had a really detailed document and stuck to it.
     
  4. svero

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    3,392
    Likes Received:
    6
    The only time I ever use any kind of design documentation is

    1) If I'm coding with a large team and I want to organize everyone to work at the same time together towards a common cohesive goal

    2) If I'm working by contract and I want the details of the contract to be clear before I start work

    3) If I'm working on a very large project with many parts to it (usually goes hand in hand with 1)

    To be honest.. for smaller games like I currently make I don't find design documentation helpful at all. Usually a few concept images is enough to go by.
     
  5. Karukef

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    15
    Likes Received:
    0
    For big teams the most important task of the design document is to get the vision of the designer across to every member of the team, loosing as little of it's intended meaning on the way as possible. It has to be detailed, solid and engaging.

    For a small team, the design document is pretty much something you use to make sure you actually get to think about everything. Nothing is more devastating to the completion of the game than constantly realizing how much more work something is, right? I usually write quite structurally with all the detail I can until one day I just decide, ok screw this I've put enough thought into this!

    One good approach is to start with a concept documentation. Write what the game is about, why it is fun, why you are making it and how. Try to get everything in there while keeping details to a minimum. Then try to write the design doc adding as little features as possible. At any rate, if you are not a big team, don't overdo the design doc.
     
  6. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    I tried using a design document, but it doesn't work very well for me. It's usually a thing you need for synchronizing the "idea" with your team. Since I'm a one man army there is no need for such a thing.

    What I'm useing right now:

    Simple flow charts for the "scenes" (intro, menu, options, game, game over, highscores, demo mode... stuff like that) with arrows indicating to which scenes you can jump and some text describing the conditions.

    A list of missing (or "broken") graphics.

    A bug list.

    A never ending todo list ;)

    Oh and Mockups. They are really great.
     
  7. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    I discovered that if a design document beyond scribbles on a single bit of paper became necessary, the game was too complex and way beyond the sensible scope of return on investment.

    As soon as the idea encroached on another sheet of paper, I screwed it all up and tried to think of another game.

    Cas :)
     
  8. Jack Norton

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    5,130
    Likes Received:
    0
    I do everything while programming. I do have a "general" idea on how to make the game but in my experience for small games (but even for complex simulation like UBM) isn't worth to make a game design document.
    You better start coding, fixing bugs, and release the game, there's enough time to spend doing that ;)
     
  9. Gilzu

    Moderator Original Member

    Joined:
    Jul 27, 2004
    Messages:
    368
    Likes Received:
    8
    One of the reasons i'm asking this is that I want to code even when I don't have ambition/get the muse. You can do that by planning exactly what to do, so even when you don't want to be creative, you can still make progress.

    Or maybe, use both. Have certain tasks ready for those times you don't really want/cant be creative/concentrated enough to program.

    -Gil
    http://www.gilzu.com/
     
  10. Coyote

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    697
    Likes Received:
    0
    I've had some mixed feelings on Design Docs.

    I did an informal poll once at a couple of GDCs and found that the success of a game (or game development studio) was inversely proportional to the size of their design documents. It was funny listening to people expound on how WONDERFUL their upcoming game would be because they had such thorough TOMES they'd developed to document every last inch of the game, so that there was no way the developers would screw it up. Then said people were often very silent on the matter the following year, when their game was cancelled or had been released with a resounding thud as they failed miserably in the marketplace and met with critical disdain.

    By contrast, many of the top developers, when asked about their design documents, often responded with things like, "Oh... I think we had one... we needed to have one to get the project approved. I think it was about three pages - we didn't look at it after the first month."

    Now of course, this is all anecdotal and I'm sure there are plenty of counterexamples. I certainly wouldn't want to be an advocate of going forward in something as ambitious as game design - especially in a team - without a plan. I think design documents are a Good Thing, even if you are a lone-wolf developer. But my feelings are:

    * You can't design fun on paper. You can only describe what you think will be fun.

    * Game design is, and should be, an iterative and interactive process. Thus, a design document is a starting point, not an exact blueprint.

    * The longer (and more long-winded) a design document is, the more readers' eyes will glaze over as they read it, and the more likely the whole thing will be ignored, or that the important parts will get lost amidst the more trivial matters. Keep it short, sweet, and to-the-point. Lists, tables, charts, and pictures are pretty useful - they'll get used when they are needed by whom they are needed, and can convey a lot of data without mind-numbing paragraphs of text getting them across.

    * I subscribe to the 'evolutionary prototype' development model. Using that model, the design document can be considered your very first prototype. Treat it as such. Use it to experiment with ideas. When parts of it have outlived their usefulness or been replaced with an actual game, throw them away (okay, that's "Throw-Away" prototyping, but since little of the design doc will actually be shipped to the end-consumer, its GOING to get thrown away...)
     
  11. Jim Buck

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,158
    Likes Received:
    0
    I think you need a detailed design document in the situations where you need to predict a schedule. If you are shooting from the hip or are doing this for fun or don't have to finish by a defined time, then it's perfectly fine to not have one. But without one, it's awfully hard to know many of the tasks that will need to get done. Just the process of thinking through a design document will uncover many, many small tasks that would have "surprised" you down the road. Sure, it's not fun and pretty much a burden to write such a document when you want to code code code away, but who said game development is always fun. :)
     
  12. GameStudioD

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    154
    Likes Received:
    0
    If you are redoing a game, the design document will be a lot easier to write. You already have visually seen how things work. The game will be better if you map out what you want to do on paper.

    I think a design document is critical. For my current game Spider, I have a half-written design document. I got a bit frustrated with the doc and started code design & coding. This is the biggest mistake I have made with this game so far.

    I am constantly running into situations where I run into a design issue, plan a little, and then code. This is extremely unproductive and difficult to predict how long it will take to complete something.

    I will never make a game again without a design document or a very good brain storm of key features of the game. At the very least, the doc needs to answer fundamental questions about gameplay.
     
  13. gmcbay

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    280
    Likes Received:
    0
    IMO, the need for design documentation (either talking about game design, or code architecture) varies based on how many people you're working with.

    If the team is 1-3 people, particularly if they know each other in real life and collaborate often, design documents aren't that important. If the team is larger than that, or geographically dispersed, well that changes things...
     
  14. Air

    Air
    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    90
    Likes Received:
    0
    Barring role-playing games, most indie games are almost entirely based on visuals and a pretty simple set of rules for how users interact with those visuals. These sorts of games benefit mostly from screenshot mock-ups. Having a good set of mock-up designs to go by can make a programmer's job tremendously easier as you can look at what the game is supposed to look like, what it currently looks like, and quickly and easily assess needed changes.

    Laying out a mockup and making it look pretty can take some time... but it's far easier still than actually programming the game to look one way or another and then deciding to try something else. I feel this applies to almost everyone, whether a solo job or a five-man team!

    Role-playing games obviously need much more textual design, not only in the storyline or progression of areas, but in terms of descriptions of player interaction since that too often has many varieties throughout an RPG. Still a good RPG's design doc should be littered with visuals-- preferrably ones that emulate what the actual final product will look like. But other than Dan, I'm not sure there are many people here aspiring for a real role-playing experience in their game.

    - Air
     
  15. Chris Evans

    Moderator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,162
    Likes Received:
    0
    For my current game Pow Pow's Great Adventure, I didn't do a formal design document. However I did do design notes.

    I basically keep a notebook that has all my notes and sketches. While I agree a huge 100 page formal design document can be an overkill for a smaller project, I do think you should write down your designs in some fashion even as a lone wolf.

    The problem with "designing as you code" is that it's very easy to lose focus. Often times you spend way too much time coding or tweaking something when you really should move on to something else. Also Gilzu made a good point how it's hard to code on "sluggish" days if you don't have a clear plan or set of tasks to do. And Jim is also right that it's hard to lay out a schedule and establish a release date if you don't have some kind of design document or notes.

    If you project is really small or it doesn't matter when it's released, then I guess it's okay to fly a bit blind without any design notes. But I'd at least try to get your thoughts on paper.

    With that said, I really believe your initial design document or notes should be as broad and general as possible. You shouldn't lock yourself into anything until you actually have a playable game. It happens all the time where something sounds great on paper but ends up being uninteresting / unintuitive once it's in the game. You design document or notes should be flexible enough to allow for any necessary gameplay modifications or improvements.
     
  16. Mithril Studios

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    94
    Likes Received:
    0
  17. Evak

    Original Member

    Joined:
    Aug 3, 2004
    Messages:
    100
    Likes Received:
    0
    don't know how importnt a design doc really is untill you get a publisher. If you have a commercial publisher for a PC game they will most likely want both a technical doc, and design doc.

    the design doc is about the game design. the technical doc is about the engine, tools, libs and a whole bunch of um technical stuff. like file type descriptions, directory structure, system specs, codecs. That kind of thing.

    With a Indie game I think its less important unless you feel it helps you get your work done. but you probably won't get a publisher and money up front if your trying to get published without them.
     
  18. Nemesis

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    273
    Likes Received:
    0
    Besides dealing with a commercial publisher, a design doc has other uses. For example, if you're working as part of a team, say, as the leader and you need to delegate tasks to other team members, especially if working remotely and you do not know the members personally, nor are in a position to meet face to face. In that case a design doc will come in very handy to keep the team in focus and to provide the details required (concept art, gameplay etc.) for the members to carry out their tasks effectively.
     
  19. Mark Sheeky

    Indie Author

    Joined:
    Aug 7, 2004
    Messages:
    448
    Likes Received:
    0
    The problem with a design doc that is too detailed is that if when change the game (as all games will), you've wasted time on the doc. Use a rough idea to start with, like artists do when they draw, and work out the difficult techincal bits. After that refine as needed.

    I use that system, and rarely put much in writing although I make sure that any txt files are in the source folder for future revision. After a game, I always make a post-design document in paper that details all of the difficult things, custom file structures and sometimes things like the pseudo code for the AI... In the late 80's I used to include the listing but that was on C64 Machine Code (not ASM!). Looking back on games I wrote 10 years ago to remember how I did things is something that I do and is really valuable. It's suprising how much doesn't change with time.

    Mark
    Cornutopia Games
    http://www.cornutopia.net
     

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