What is a good format for game designing in a step by step method?
Some might say look at gamedev articles but they don’t say it the way I would like to see it by saying it in steps and how much detail to put in.
I find the art of a design document not perfected to be a standard yet since I see many contradicting articles about it. One article is this new one that GD posted http://www.societygames.com/ramblings/OneDevOneGame.html
Well what do some designers say about a good design document? And when do u go to the point of putting details on every inch of the level?
There are lots of examples of Game Design documents available on the web, and a simple web search should yield fair results. But you must keep in mind that game design IS an Art, not a science -- there is no "Right" way to design a game.
Regarding design documents specifically,though, there are a number of elements that it probably should include, depending on the target audience of your game. If I had more time I''d elaborate, but I don''t exactly keep a list on hand, it would take time to research it, which you could probably do yourself.
A few off the top of my head (in no partiular order except for the order in which they come to my mind):
1) A summary of the game. Something that catches the attention right up front and makes the reader want to keep reading.
2) Target audience. Who is your game intended for? This is important; different audiences will want different things from your game, and it gives you a set of shoes to put yourself in while designing.
3) Treatment. I don''t know that this is a must in every document, but it can''t hurt to include a longer description of your game that describes what it actually is in more detail. This is usually called a treatment, and is occasionally mistaken for a design document in itself -- it goes into significant detail about how the game works, but it''s generally not more than a few pages long, and it doesn''t deal with the inner workings of the game so much as what the user will see.
4) In-depth technical evaluation. Is your game feasible using current technology? What about with the current team? What hurdles must be overcome before the game can begin production? I say "in-depth" because you should address every aspect of the game -- from A.I. programming to level mapping to texture art.
5) Market evaluation. This addresses the reasons the target audience will buy your game, the competiting games of the past, present, and future, and how much money is spent on those games. Why do I include this in a Design document? Simply because if no one will buy the game, its not very wise to produce it.
6) Cost projection. How much will it really cost to make your game? Again, included because If you can''t afford it, you shouldn''t make it.
7) Interface. How will the user interact with the game? If the interface sucks (i.e. it''s clunky, unnatural, unresponsive, slow, or ugly), it doesn''t matter how good the graphics, the story, or the gameplay mechanics are, people just won''t play it.
8) The story. Obviously, if there''s anything remotely resembling a story in your game you should include it in the design document. If your game is story-intensive, you should include relevant backstory and depth about the game world, the characters, and the plot as well as the progression of the story.
9) Graphics. This goes along with the technical evaluation, but this is especially important because games that sell well have great graphics. Sad fact to some but hey, people want to get the most out of their expensive video cards, after all. Are you going to license an engine? Are you going to use Cel Shading technology, or is all the art going to be a stylized pre-rendered 3D anime-nouveau hybrid? Whats going to make your game stand out visually?
10) Economy. Many games nowadays have an internal economy -- MMORPGs in particular, but this plays a big role in RTSs and sandbox games as well.
Ok I''m really tired. I could probably come up with more but I''ve got to get to bed. Please note that, again, Design Docs are not a science; you might write a design doc thats 2 pages long and includes not one of the above elements, and it might still serve its purpose.
Brian Lacy
Smoking Monkey Studios
Comments? Questions? Curious?
brian@smoking-monkey.org
"I create. Therefore I am."
Regarding design documents specifically,though, there are a number of elements that it probably should include, depending on the target audience of your game. If I had more time I''d elaborate, but I don''t exactly keep a list on hand, it would take time to research it, which you could probably do yourself.
A few off the top of my head (in no partiular order except for the order in which they come to my mind):
1) A summary of the game. Something that catches the attention right up front and makes the reader want to keep reading.
2) Target audience. Who is your game intended for? This is important; different audiences will want different things from your game, and it gives you a set of shoes to put yourself in while designing.
3) Treatment. I don''t know that this is a must in every document, but it can''t hurt to include a longer description of your game that describes what it actually is in more detail. This is usually called a treatment, and is occasionally mistaken for a design document in itself -- it goes into significant detail about how the game works, but it''s generally not more than a few pages long, and it doesn''t deal with the inner workings of the game so much as what the user will see.
4) In-depth technical evaluation. Is your game feasible using current technology? What about with the current team? What hurdles must be overcome before the game can begin production? I say "in-depth" because you should address every aspect of the game -- from A.I. programming to level mapping to texture art.
5) Market evaluation. This addresses the reasons the target audience will buy your game, the competiting games of the past, present, and future, and how much money is spent on those games. Why do I include this in a Design document? Simply because if no one will buy the game, its not very wise to produce it.
6) Cost projection. How much will it really cost to make your game? Again, included because If you can''t afford it, you shouldn''t make it.
7) Interface. How will the user interact with the game? If the interface sucks (i.e. it''s clunky, unnatural, unresponsive, slow, or ugly), it doesn''t matter how good the graphics, the story, or the gameplay mechanics are, people just won''t play it.
8) The story. Obviously, if there''s anything remotely resembling a story in your game you should include it in the design document. If your game is story-intensive, you should include relevant backstory and depth about the game world, the characters, and the plot as well as the progression of the story.
9) Graphics. This goes along with the technical evaluation, but this is especially important because games that sell well have great graphics. Sad fact to some but hey, people want to get the most out of their expensive video cards, after all. Are you going to license an engine? Are you going to use Cel Shading technology, or is all the art going to be a stylized pre-rendered 3D anime-nouveau hybrid? Whats going to make your game stand out visually?
10) Economy. Many games nowadays have an internal economy -- MMORPGs in particular, but this plays a big role in RTSs and sandbox games as well.
Ok I''m really tired. I could probably come up with more but I''ve got to get to bed. Please note that, again, Design Docs are not a science; you might write a design doc thats 2 pages long and includes not one of the above elements, and it might still serve its purpose.
Brian Lacy
Smoking Monkey Studios
Comments? Questions? Curious?
brian@smoking-monkey.org
"I create. Therefore I am."
Ingredients:
1 cup soy margarine, softened
1 1/2 cups tightly packed brown sugar
1 cup table sugar
1 ripe, mashed banana (if the banana peel isn''t, like, spotted black, cover the mashed banana with the juice of half a lemon for about 15 minutes before incorporating it into the mix)
3, 4, or 5 teaspoons vanilla (be generous)
2 tablespoons water
1 3/4 cups all-purpose or whole-wheat flour
1 teaspoon baking powder stirred into the
2 1/2 cups rolled oats (quick oats work well)
2 1/2 cups vegan chocolate chips
Directions:
Beat together the margarine and sugars. Electric mixers are unnecessary. Add the well-mashed banana and mix well, then add the vanilla, then the water. The water will try to separate; keep mixing with a figure-eight motion and add the dry ingredients, in the order above, bit by bit (say, by half-cup increments).
The final batter should be almost too dry to hold the chocolate chips; if it isn''t, I''ve misrepresented the amount of flour or oats you need and you should add more or less, according to the problem. Dry batter is good, since any chips that fall off the batter can go directly into your mouth, and no one will miss them.
Bake them for 9-10 minutes in a pre-heated, 375-degree F oven on an ungreased cookie sheet. Cook them longer if you prefer a hard cookie, but be aware that bananas only approximate the action of an egg in the mix, and you can get cookies as hard as the cookie sheet if you aren''t careful.
Let them congeal on the sheet for a moment after removing them from the oven, then cool on a plate or a wire rack. Store in an air-tight container. They taste even better after they sit overnight or in the fridge.
There U go, now let me pull your pants down and teach you how to crap.
1 cup soy margarine, softened
1 1/2 cups tightly packed brown sugar
1 cup table sugar
1 ripe, mashed banana (if the banana peel isn''t, like, spotted black, cover the mashed banana with the juice of half a lemon for about 15 minutes before incorporating it into the mix)
3, 4, or 5 teaspoons vanilla (be generous)
2 tablespoons water
1 3/4 cups all-purpose or whole-wheat flour
1 teaspoon baking powder stirred into the
2 1/2 cups rolled oats (quick oats work well)
2 1/2 cups vegan chocolate chips
Directions:
Beat together the margarine and sugars. Electric mixers are unnecessary. Add the well-mashed banana and mix well, then add the vanilla, then the water. The water will try to separate; keep mixing with a figure-eight motion and add the dry ingredients, in the order above, bit by bit (say, by half-cup increments).
The final batter should be almost too dry to hold the chocolate chips; if it isn''t, I''ve misrepresented the amount of flour or oats you need and you should add more or less, according to the problem. Dry batter is good, since any chips that fall off the batter can go directly into your mouth, and no one will miss them.
Bake them for 9-10 minutes in a pre-heated, 375-degree F oven on an ungreased cookie sheet. Cook them longer if you prefer a hard cookie, but be aware that bananas only approximate the action of an egg in the mix, and you can get cookies as hard as the cookie sheet if you aren''t careful.
Let them congeal on the sheet for a moment after removing them from the oven, then cool on a plate or a wire rack. Store in an air-tight container. They taste even better after they sit overnight or in the fridge.
There U go, now let me pull your pants down and teach you how to crap.
I think the key question about a design document is for what purpose and for whom are you writing it? If you are writing it in order to sell your game to some sort of management, then you should include all or most of the points IRBrian raised. If you are writing it for a programming team, then you can afford to leave out things like market research and cost projections, but probably want to go into more technical detail.
If you are writing it for your own use, or for use with a team you will be closely involved with, then it depends heavily on your individual/collective style. If you are better working with everything planned in advance, and a heavily structured system in place, then you probably want to have details on everything before you start writing any code. If you aren''t sure exactly what you want to produce, or prefer to improvise, then you may be better off not writing too much - particularly if you are then going to be bound by what you''ve written. On the other hand, doing this, you have to accept that you will either need to document everything as you produce code, or accept that there will be times you have to discard whole chunks of code because you have no idea how they''re supposed to work, or how they''re supposed to interact with other parts of your project, or else come up with some way to hold every detail of the code in your head, along with any decisions made about the future of the game, and be on call to the programmers constantly (less of a problem in a one-man project).
Basically, approaches to design documents vary widely - if you''re writing it for someone else''s benefit, then consider what information they need to know and try and put that in. If you''re writing it for yourself, put in as much detail as you think you need, and in whatever format makes it easiest for you to use.
For one project I was involved in, the final design document ended up so detailed that, in the portions of code for which I was responsible, it wasn''t so much a matter of writing the code as compiling the design into C... Other stuff I''ve done (admittedly very small projects) have had practically no design document, or (in the case of some simple board games) just a copy of the rules.
If you are writing it for your own use, or for use with a team you will be closely involved with, then it depends heavily on your individual/collective style. If you are better working with everything planned in advance, and a heavily structured system in place, then you probably want to have details on everything before you start writing any code. If you aren''t sure exactly what you want to produce, or prefer to improvise, then you may be better off not writing too much - particularly if you are then going to be bound by what you''ve written. On the other hand, doing this, you have to accept that you will either need to document everything as you produce code, or accept that there will be times you have to discard whole chunks of code because you have no idea how they''re supposed to work, or how they''re supposed to interact with other parts of your project, or else come up with some way to hold every detail of the code in your head, along with any decisions made about the future of the game, and be on call to the programmers constantly (less of a problem in a one-man project).
Basically, approaches to design documents vary widely - if you''re writing it for someone else''s benefit, then consider what information they need to know and try and put that in. If you''re writing it for yourself, put in as much detail as you think you need, and in whatever format makes it easiest for you to use.
For one project I was involved in, the final design document ended up so detailed that, in the portions of code for which I was responsible, it wasn''t so much a matter of writing the code as compiling the design into C... Other stuff I''ve done (admittedly very small projects) have had practically no design document, or (in the case of some simple board games) just a copy of the rules.
Irbrain you game a lot of good points to keep in mind.
******
I would prefer a more detailed layout that would be presented to a team. art, sound, programmer, level, controls, options, story, statistics of the game type in how it sold and if it can the pros and cons, time it might take to make depending on the people it takes, etc.
How many of those are their and how many things would each one talk about like levels for example would be a general layout of all the levels and then you go to each individual level like
------
1a.general layout of level 1.0
The name, the length (by block size, the time limit, the # of enemies, Total score, etc.
2a.Detailed layout
what and where the a specific objects go on (level layouts should be done on a graph paper), where the specific enemy goes on, where you start from, where the events activate, where the backgrounds are and front grounds, etc..
------******
Well something like that.
Does things seem to be more organized and more motivational to add your ideas in than a big blank paper? Its better to have a template I think since you can see what you and have you are missing and it can appeal in every aspect from art to programming. Being able to read the document and feel like you are playing the game.
What do some think?
******
I would prefer a more detailed layout that would be presented to a team. art, sound, programmer, level, controls, options, story, statistics of the game type in how it sold and if it can the pros and cons, time it might take to make depending on the people it takes, etc.
How many of those are their and how many things would each one talk about like levels for example would be a general layout of all the levels and then you go to each individual level like
------
1a.general layout of level 1.0
The name, the length (by block size, the time limit, the # of enemies, Total score, etc.
2a.Detailed layout
what and where the a specific objects go on (level layouts should be done on a graph paper), where the specific enemy goes on, where you start from, where the events activate, where the backgrounds are and front grounds, etc..
------******
Well something like that.
Does things seem to be more organized and more motivational to add your ideas in than a big blank paper? Its better to have a template I think since you can see what you and have you are missing and it can appeal in every aspect from art to programming. Being able to read the document and feel like you are playing the game.
What do some think?
just watch out that your big design doc actually gets read... unfortunately that´s always a danger.
as for presenting your idea: nothing works as well as a few detailled scribbles or a prototype (needn´t be digital)..
as for presenting your idea: nothing works as well as a few detailled scribbles or a prototype (needn´t be digital)..
here''s how I write my design documents:
I think my method the "upside down tree method". Each branch of the tree is represented by a hyperlink, so my design doc consists of a bunch of html files.
The "root" of the tree is a 1 page summary of the game, then a list of game features. Then at the bottom should be a list of all the links to other sections.
Once you write your game summary, you may think "how should I divide this summary into more specific sections", so you do that and those sections become branches. So you just keep splitting more general into several specific ones, until you get satisfied with your level of detail.
This method is good cause it helps you think of the game as a whole, rather than coming up with a whole bunch of elements and hoping they fit together perfectly. Also, it''s hard to write a truely complete design doc, so it''s better to focus on describing the game as a whole rather than small parts of it.
Here''s my design doc for a space game.
I think my method the "upside down tree method". Each branch of the tree is represented by a hyperlink, so my design doc consists of a bunch of html files.
The "root" of the tree is a 1 page summary of the game, then a list of game features. Then at the bottom should be a list of all the links to other sections.
Once you write your game summary, you may think "how should I divide this summary into more specific sections", so you do that and those sections become branches. So you just keep splitting more general into several specific ones, until you get satisfied with your level of detail.
This method is good cause it helps you think of the game as a whole, rather than coming up with a whole bunch of elements and hoping they fit together perfectly. Also, it''s hard to write a truely complete design doc, so it''s better to focus on describing the game as a whole rather than small parts of it.
Here''s my design doc for a space game.
I always like to have some pseudo code of some things like the game loop, initiating the game, AI algorithms, etc so I know what to work step by step so I don''t loose interest in the creation of the game.
- Rob Loach
OverTech Technologies
__________________________
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller
- Rob Loach
OverTech Technologies
__________________________
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller
Yes you all say good things and thanks for the information.
But I would like to see a actual template to fill in the questions as I showed an example of.
It''s easier, faster, and more organized to answer and understand a multiple question paper than a blank paper.
Maybe I should make another post to ask everyone to help make a standard design document. Well we are at the main place to do this and if we don'' then who will? If bill gates did it he would charge you and monitor you just for using the layout lol.
But I would like to see a actual template to fill in the questions as I showed an example of.
It''s easier, faster, and more organized to answer and understand a multiple question paper than a blank paper.
Maybe I should make another post to ask everyone to help make a standard design document. Well we are at the main place to do this and if we don'' then who will? If bill gates did it he would charge you and monitor you just for using the layout lol.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement