Welcome, Guest. Please Login or Register.  • Help
SMF Underground
+ SHMUP-DEV » SHMUP DEV FORUMS » Assistance
|-+ Design document's

Pages: [1]   Go Down
0 Members and 1 Guest are viewing this topic. Topic Tools  
Read December 31, 2005, 02:01:54 PM #0
Taiphoz

Design document's

Game Design is one of the most important aspects of creating your own game, if you are like a lot of us working in a team or a solo programmer then it is very important to have a plan for what your about to work on.

In my experience I have found that projects started with no design , or design documentation tend not to be completed, or if they are they fall far short of what the programmer had in mind at the start.

As a result I am creating this guide, well what I hope will end up as a guid to creating a good , simple, and easy to follow design docuemnt.


  • What Is A Design Document
    A Design document is your road map to the project your working on, and it can consist of a large number of sections, I will try and cut all of these down to only a hand full of sections that are used by most people, if I cover them all right away then it could put some people off and thats not what i want.

    High Concept : A High consept is a description of your game in 255 characters, or one line of text. Its been said that if you cant explain the basics of your game in one line then you need to be rethinking your idea.

    Here is an example of one of mine.

    "Control :: A game set on an alien planet, tons of aliens , tons of bullets, and you need to control it all by capturing land"

    In the above example you can draw a few conclusions, one is that its probably going to be an RTS style game, possibly FPS, its going to involve shooting or killing lots of oncoming aliens, while you try to take over and control area's of land on some alien planet.

    Game Description :: Your game description should describe in as much detail ass possible what your objectives are, what your game is all about , who your hero is, and how your hero is supposed to progress through the game.

    I have seen Game Description come in the form of a short story, or a level by level description of how the hero progresses, it will be upto you to work out the best way for you to describe your game in detail.

    What I do is try to imagine I am telling a friend about the game Idea that I have, and I then put that down on paper.

    Here is an Example

    Game Asteroids , The game starts you out on a planet surface, you can see your ship on the launch pad, you have access to some ship menus allowing you to chose a ship type, fire type and some other cool stuff.

    When your ready you can click launch and you watch your ship taking off, as the screen fades out the menu screen and fades in the action, you find yourself surrounded by asteroids and they all look hard as nails, you let rip with your guns to clear them out but find that they split in two when you blow them up, this creates more chaos, some seem to drop powerups that you can collect and use to clearl the levels fastre.

    Every now and then some crazy alien ship flys in and gives you a few shots, before it turns and runs for cover, your clear the level of all asteroids and land back on the planet to collect your bonis and repair and upgrade your ship. while your doing this your base asteroid warning alarm goes off, its time for action again.


    A game description can tell you things about your idea that you may not first be aware of, it also allows you to elaborate and expand your idea when it comes to develop your game, for example in mine above I explain how some pesky aliens come in shot and then run, this can easily be exanded on in game to have them coming in ever increasing waves as you progress through the game, you could add more planets to laucnh from, the scope here is huge.

    Game Flow This can be the most important Aspect of your design document, and if I have time I will try and include a picture of a flow chart, until then I will use some text to describe what I am talking about.

    The bottom line is that a Chart is created to show the flow of your game from your first line of code to the last. this sounds really daunting but its not, your not showing per line your just showing each function, and how it flows into the next.

    In the example I have provided in the Image bellow, its a programme that creates some variables, asks the user for a number, and if the number is over 10 the programme ends, if not then it loops.

    Looking at this chart will enable anyone to create this programme, they instantly know they need an If else. they know how many functions they are going to use and they know or can guess how many lines of code they are going to need, they should also be able to work out any possible problems that might crop up.

    There are a lot of standards for this level of design, UML , SSADM can be used, and a number of others, TBH its all bull shit, what you need to do is create your own method of doing this that makes it easier for you to manage and understand when looking at it.

    Datalflow charts can then be made, using your process flow chart above as a backing you can create new charts to show where the code will need to pass information, like the variable which stores the user's number, it would be getting passed from one function to another, so you can show this in a similar diagram , just add the variables to the side of the lines and arrows to show what way the data is traveling in.

    I dont want to go into this much more because it is such a detailed subject in its own right.

    Level Design or Structure In the same way that art style is important to your game, level design and structure is also very important.

    Creating a level design plan for each level will help you plan where to put your aliens, or bad guys, how many there will be, what the level will look like, what its settings are , what its effects will be and how all of this will effect the player.

    You can do this section of your design docuemnt with lots of images, scetches or just a description in text of how each level is played and made up, I find that its best to draw or scetch your levels and then fill it with clip notes explaining how stuff works, where a key fits or what dor or enemy dies if the player shoots a particular base or door.

    Concept Art If you cant draw, or if you can draw but cant model it does not really matter, in your design docuement its important to have a section for your concept's, these can be images of space ships cut out of a magazine that you like the shape or design of, it can be colours or textures you like and think will fit your game,  if you can draw then you should make as many detailed drawings of your project from all angles, the more detail you use the better as it enables you to have a plan when it comes to creating them in digital form.

    Its important at this stage to try and come up with a theme, to many Indie game developers fall flat on their ass here, they have all nice looking sprites and bad guys, the problem is they all look way to different, what I mean is that you have to invent a style for each game, or each race of aliens, you have to invent a colour scheme to use for them, its important that your game style looks right. if you just have a patchwork collection of random sprites on screen, even if the game is awsome to play, it will put people off.

    Style is important, colour is important.

I think thats about it for now, you will note there is not real code listed above, at the design stage you shouldnt be thinking about code at all, your simply working out how your going to do things, what its going to look like and how many of an alien or enemy you plan to have, and where your going to put them.

Once you have a good design document, which should consist of some procedure flow charts, some data flow charts , some concept art and some level designs, then your ready to start programming your game.

Just follow your design, and try to stick to the Original plan, Another HUGE pitfall is thinking of a new cool idea in the middle of your development and then trying to fit that into the project, this is a HUGE mistake, what to do instead is jot the idea down, and save it for Version 2 of your game, if you try to add new stuff to your project you will only end up messing your design plan up and this will cause problems further down the line.

I hope this helps some of you, I know some of you dont use any design doc's at all and some of you think you dont need them, but take it from me, its a god send it will help and it will save your project.

[attachment lost, please re-upload]


Offline  
Read January 03, 2006, 03:38:59 AM #1
caseyd

Re: Design document's

This www.gamedev.net/reference/articles/article1063.asp is a design doc written by Chris Taylor if anyone wants to take a look at it.
Offline  
Read January 03, 2006, 06:50:43 AM #2
Taiphoz

Re: Design document's

This www.gamedev.net/reference/articles/article1063.asp is a design doc written by Chris Taylor if anyone wants to take a look at it.

Yeah note the complexity to it, Iv actually seen a lot worse, the above is a lot like what we had to do for our Uni Games Development course, and its over bloated, this is really only used for the AAA Games Industry as those people who like to back games developers, the publishers, like to have things described like 100 ways before they agree to anything.

We got to see a sony Design doc, that was a bloody piss take, it was about 125 pages long and that was the template.

Iv also seen one by peter molenue < spelling ?.. his was rather .. shall we say deep.

The out I have outlined and as I stated in the post a cut down version for small time Indie developers, mostly as it is now for those of you who have not used a design doc before, or have never heard of one but are still trying to make games.


Offline  
Read January 19, 2006, 12:02:16 PM #3
heyto

Re: Design document's

Yavin,

You make some very interesting and relevant point, however at the risk of starting a flame war - hopefully not  Wink I'm going to disagree with one of your suggestions, the Game Flow section. I believe very few (if any) code design decisions should be presented in the Game's design document, especially those as low level as illustrated by code flow charts. If you did code flow charting, or UML, in the design document then the design document for any non-trival game would be completely swamped by the code flow section. I'm not saying the code design shouldn't be documented only that its design doesn't belong in the game's design document, in fact I think the code design should belong in a separate detailed design document. This leaves the game design document (mainly) detailing what the game should be like (with a few hints towards how that will be achieved).

As a side note, I'd be happy with a section of Game Flow that described how you progress though the game from the player(s) perspective, e.g. Startup -> main menu -> select game -> play game -> main menu...

Regards,

Tom
Offline  
Read January 19, 2006, 10:36:28 PM #4
Taiphoz

Re: Design document's

If you did code flow charting, or UML, in the design document then the design document for any non-trival game would be completely swamped by the code flow section.

Tom

Your right of course, I was showing a flow chart with an example to demonstrate how they look, I was not trying to suggest that the flow chart be as detailed as your leading to be beleieved.

Instead a more genralised chart for an game overview would be add for a propper game. for example on one of my projects I have 22 source code files, each contain chunks of code relevant to 1 part of the game, for example bullet.src containts all moveing, updating and drawing code.

My flow chart in my design document for this game was all on 1 A4 sheet of papper, and simply showed the flow of the code from function to function as the game run through.

As I begun to develope the game I from that 1 A4 sheet had a good idea of what functions I was going to need and then proceeded to creating flow charts per function.

The flow chart can be as detailed or as genreal as you want to make it, show line by line interactions, show nested code by nested code or show function by function, you could even show file by file interactions.

Its all a matter of sorting out what your wanting to show and then showing it. I always start off with a very basic shart that outlines the game flow, never going any deeper than showing functions. I then go deeper if needed.


Offline  
Read January 20, 2006, 10:20:21 AM #5
d000hg

Re: Design document's

I'm in the process of creating a design doc. One thing to bear in mind: the doc isn't just used to help YOU make your game. It's also one of the best ways of making your game look professional - whether that's to a publisher (unlikely), or to attract some volunteers to your team.
There's always loads of teams wanting help and most die out. Showing that you are prepared and approaching the game from a professional direction looks pretty impressive.
Offline  
Read January 20, 2006, 05:56:53 PM #6
heyto

Re: Design document's

Yavin,

It sounds like in the past you've performed a functional decomposition to designed/document the game code, this is IMO a very reasonable way to outline the code. If you still have it, any chance chance you could post your decomposition as an example (I'm hoping this will help other people who are working on there own designs)

I still stand by my point that very few code decisions belong in the game's design document, they belong somewhere else. But I'll concede this really comes down why you're working on a game's design document, i.e. who's the intended audience (and what do you want from them)

To attract code developers codes design in your design document is probably helpful, to attract artists it's less useful and to interest publishers less again.

Cheers,

Tom
Offline  
Read January 21, 2006, 08:15:50 AM #7
Taiphoz

Re: Design document's

Dont have anything in digital form just now, When I make one I get it onto paper and then photo copy it when I need to send it out to some one.

Dunno about others but I find it a lot easier to read if I have it in hand on a bit of paper, I'm like that with code manual's as well, id rather have a book in my hand than be looking through a manual online.

I will see if I can find one tho and let you see it. I should be starting one soon for a shooter I am planning, what I will do is show you guys the design doc I make for it. once its done of course.


Offline  
Read January 21, 2006, 09:36:31 AM #8
Indiepath

Re: Design document's

Here is the design doc template that we use for all games : http://indiepath.com/public/DesignDocumentTemplate01.doc

This document usually goes through at least 10 revisions before we begin any coding. Our latest game, slated to start development within a month, has gone through many many revisions over the past 6 months!

If you share this then please let people know where you got it from. Thanks.

« Last Edit: January 21, 2006, 09:40:07 AM by Indiepath »



www.pjio.com - Upload, Tag, Share and Play.
Offline  
Read January 22, 2006, 09:07:51 PM #9
Taiphoz

Re: Design document's

Yeah thats prity much what im talking about, thats a good example, please note that although the template looks as though it has way to much content, its not really as its still just focusing on the main need to know information.

Thats a lot like what we use, although we tend to do a different one to fit each game instead of having genrelised sections. so one of ours for a shooter has sections for shooters only.

Thats a good template tho nice of you to share it.


Offline  
Read January 23, 2006, 11:12:12 AM #10
d000hg

Re: Design document's

Yeah, thanks.
Offline  
Read January 27, 2006, 06:13:41 PM #11
gamesmad

Re: Design document's

Nice template, might use that in future.  The deign doc for the game my team is currently 15 pages and is certainly still growing.

Will
Offline  
Read January 27, 2006, 06:21:59 PM #12
Matt McFarland

Re: Design document's

I'm not using a design document.  I'm sure many people will probably tell me to get with the program, but I prefer the abstract method of design.  This might be considered a curse.  Well, honestly, if I do ever feel that it is worth the time and effort to work on a Design Document then perhaps I'll change my mind.  Until then, I'll be doing things the personally-preferred abstract way.


<a href="http://www.mattmcfarland.com/flash/myFlashSig.swf" target="_blank">http://www.mattmcfarland.com/flash/myFlashSig.swf</a>
Offline  
Read January 27, 2006, 07:49:53 PM #13
gamesmad

Re: Design document's

Doing things in an "abstract" way can sometimes be good, and it will stop you getting bored with your project.  But it is VERY important to remember to keep your goal in mind, or you will end up with a game that bares virtually no resemblence to what your original idea was, which is quite annoying.

Will
Offline  
Read February 07, 2006, 06:55:51 PM #14
Doctor P

Re: Design document's

I've not done a design doc per say, but I do tend to scribble down ideas when they strike, things like baddie designs and class structures. I guess I could compile it into a formal document but I prefere to do it freestyle. I think a design doc is more relevant to a large scale development.

/has a shoebox which has all the notes and drawings for Celerity in.
« Last Edit: February 07, 2006, 06:58:48 PM by Doctor P »
Offline  
Read February 07, 2006, 08:08:31 PM #15
oNyx

Re: Design document's

The main purpose of a design doc is keeping the idea of the game in sync with the other team members. With a big team it surely does make sense. But it also means that the design doc needs to be updated all the time.

With smaller projects and smaller teams there isnt much of an advantage, but it might be worth (depending on the genre) to create specific parts of a design document like:
-screen flow charts (they are helpful when fleshing out the flow skeleton)
-character details with background (they are helpful when writing dialogs)
-scoring system details (a scoring system can get pretty complicated and its good to have it on paper as reference or if you would like to discuss possible problems with it etc)

Stuff like that... or basically everything which is actually useful for you. Well, I just think that approaching it overly formally isnt much help... but I also think that without any written outlines its easy to get on the wrong track. Try to find out whats working for you and what doesnt.
Offline  
Read February 07, 2006, 10:38:44 PM #16
jbadams

Re: Design document's

Just to throw out another great link on the subject, there's a great article (actually a short series) on writing functional specs here.
Offline  
Read February 08, 2006, 04:56:49 AM #17
gamesmad

Re: Design document's

I read the first bit of that article and it looks very interesting.  Ive bookmarked it and Ill read it later, thanks for the link.

Will
Offline  
Read February 08, 2006, 10:18:03 AM #18
d000hg

Re: Design document's

Doing things in an "abstract" way can sometimes be good, and it will stop you getting bored with your project.  But it is VERY important to remember to keep your goal in mind, or you will end up with a game that bares virtually no resemblence to what your original idea was, which is quite annoying.

Will
Which is why writing it down and then fleshing out the details on paper keeps it safe. You know exactly what the game should do before you start coding. Obviously the design may change once you start implementing it but you can update the design doc to still be accurate.
Offline  
Read February 08, 2006, 04:01:55 PM #19
gamesmad

Re: Design document's

Its also good to have a design doc if you are working in a team, because then everyone is working to exactly the same target, and you dont get little hitches...

Will
Offline  
Read February 09, 2006, 10:32:41 AM #20
d000hg

Re: Design document's

Exactly. In a team, I reckon any half-way serious development MUST have one to be taken seriously!
Offline  
Read February 12, 2006, 01:20:11 PM #21
gamesmad

Re: Design document's

By the way Yavin, Ive just realised that there is a mispelling in the title of this thread.  It should be "Design documents", otherwise you are suggesting that the document owns something...  Sorry for nit picking, I just noticed it and it was bugging me Tongue

Will
Offline  
Read March 06, 2006, 01:27:42 PM #22
ELLioT

Re: Design document's

Hi all. About flow charts, diagrams etc, I used this software a few years. It appeared to be very efficient and easy to learn :
http://www.smartdraw.com/exp/ste/home/ .
Offline  
Read December 16, 2006, 07:52:25 PM #23
Aubrey

Re: Design document's

You might want to consider using a Wiki for your design document:

Pros:
  • Collaborative
  • Always up-to-date
  • Everyone's input/changes are tracked
  • Easy to revert to old versions
  • Online, so you don't have to have the the lastest copy with you - jump on anyone's 'net connection when inspiration hits you.
  • A useful "scratch pad" for little ideas you want to write down, and want to share
  • Wikis force your design to be organized into conceptual chunks, encouraging modularity and accurate functional descriptions, naturally leading into code design.
  • Less repetition - concepts are defined in one place, and one place only. They are then linked to. (Conventional documents often re-define things, and inconsistently, too).
  • Hyper-linking between concepts (lets users read as much or as little depth as they like)
  • Easy to search
  • Meta-pages for discussion of subjects/questions about pages
  • Embed images easily (just like a forum, really).


Cons:
  • Anyone can edit anything, so you have to create your own rules to stop malicious edits/politicking.
  • The bigger the wiki gets, the more work it is to maintain. You kind of have to plan your wiki's structure up front! Establish things like "categories" early on to save headaches later.
  • A wiki is only as good as its worst user: everyone has to learn the "house rules" and stick to them, or you end up with a mess.
  • Because they're so inter-linked, wikis can be a bit frightening to read for the first time: you want to read about one feature, but you end up reading 3 pages linked by it, and those pages have 3 more pages... before you know it, you're reading the entire wiki, rather than the one concept! As a result, you give up! Two things: First, Index a lot. Make lists of links at the bottom of pages which link around a lot. Hyperlinking mid-sentance should NOT be the only way to link between pages (this encourages people to leave the current page behind, mid way through a sentance!). Making lists helps people create a "mental map" of the wiki a bit easier. Second, try to put different levels of detail in each page - start with an overview which tries not to connect to other pages. Then, in sub-headings, go into more detail, feeling free to branch to other concepts using wiki-word links.
  • When things get really detailed, maintaining the wiki feels like overkill (unless you have a fairly big team). However, it is good record to have in case of arguments.
  • Some wikis have real "quirks" that you have to get used to - media wiki requires "CTRL F5" to properly refresh, sometimes. And different wikis have different tags for different things.
  • Others are hard to set up with access/security - secret pages, access levels and such. This is getting better, though.
  • Because wikis can be changed at any point, people don't actually check them as often as they should. You CAN have "watch this page" type stuff, where an e-mail is sent based on changes, but since the average change to a page involves about 4 edits, it can swamp people with e-mails, which they disregard.
  • If you want to send a publisher/marketing a "normal" document, you have to spend a lot of time copying/pasting/editing a new document from the contents of the wiki. Not fun, but if you have to make pitch documents from regular design docs, likelyhood is, you'll have to make something specifically targeted to the audience, anyway.
  • Formatting is typically done through forum style tags - this is a personal grip, but I think it would be really nice to be able to use Rich Text, so that formatting can be done in something wysiwyg like open office (also handling spelling nicely!), and then copied into the wiki.

Wikis, all in all, are a big effort. They are by no means a magic bullet for design documents, but I do believe that they nurture a higher quality of design document - keeping ideas precise and consistent, making it much easier for anyone to read, and make to spec. Used and maintained properly they are lovely things to behold - an excellent way to organize your information.

I've heard of a lot of pros using their own official or unofficial wikis for work... I introduced them to my old company, and they still use them today for all sorts of public documentation - from asset tracking to Human Resources. Because of that, publishers are also getting used to being sent to Design Wikis, rather than being sent reams of paper. And publishers who still request tailored design documents ought to know that asking for them disrupts the flow of development, and that they ought to feel more at home with the honest, working version of the design document, rather than one that has been polished up for their approval. *cough*. The better publishers I've dealt with have recognized this.
Offline  
Read December 15, 2009, 01:46:35 PM #24
Substance20

Re: Design document's

I suggest spreadsheets in Google Docs, or at least excel/spreadsheet format in whatever word processor you're using.

This is especially useful for team members who are trying to keep tabs on asset lists and to-dos (no pun intended). Furthermore, the one maintaining the design doc can easily split up the sections into individual tabs especially designated for a particular purpose or team member (art asset lists and art direction guide for artists, core mechanics and features for designers, technical docs and lists of known coding issues for programmers, and even scheduling).

Using this in tandem with other documentation formats (standard word docs for game story flow, flowcharts for game progression, etc.), the designer or design team can avoid having everything in one file and overloading it. It gives everyone their own place in the sun, too, so you don't have to wade through tons of stuff in a single file to find exactly what you need.
Offline  
Read December 15, 2009, 07:31:46 PM #25
Null1024

Re: Design document's

I don't write design documents for one reason:

I never get to the actual game making part if I do. I write the document, get ready to work on it, and then the document just sits there, and I've moved on to something else.

Also, I never touch it again.

On the other hand, if I have a game started, I might go back to working on it every once in a blue moon. The chances are slim if I haven't gotten very far, but they're at least nonzero at this point.
Offline  
Pages: [1]   Go Up
Jump to:  

Page created in 0.319 seconds with 17 queries.