#15825 - Ellipsis - Sat Jan 31, 2004 6:47 am
How would a game design document for an RPG be written? Considering all the different branches the game can take, how would that be kept in order in a written document?
Would damage be written as part of a game's technical document rather than the design?
Uh... just some questions I had to get off my chest.
#15828 - Lord Graga - Sat Jan 31, 2004 4:00 pm
I suggest something like this (for story only):
http://gazler.com/users/graga/rpgmap.gif (picture)'
Every "part" would have it's own document (part 1.txt, part5a.txt, part5b.txt, etc).
#15831 - poslundc - Sat Jan 31, 2004 4:23 pm
Of course, many console RPGs are much more linear in nature anyway, and don't require such mapping techniques.
Dan.
#15834 - Ellipsis - Sat Jan 31, 2004 7:46 pm
Yeah, I guess writing it the way the picture shows would make sense. I don't think I'm gonna be writing two endings, so I can probably wrap everything up into one ending. Oh! What if there're side quests? Are those included in the main document, or are they supplementary pages? Even harder would be if the optional quests were entrenched in the overall story of the game, changing the main quest dialogues and such. Hmm....
#15914 - sgeos - Wed Feb 04, 2004 1:34 am
You really want a bunch of documents. Start with these:
Rules Document
Scenario Document
Data Lists (Monsters, weapons, items, etc.)
Those will describe the game you want to make. Getting those documents out of the way will clear much of your requirements analysis. The next step is to finish requirements analysis. Then you'll want to figure out your program architecture, modules, and files. Then work on the detailed design for each component. You'll also probably want an art document.
-Brendan
#16004 - animension - Fri Feb 06, 2004 1:32 am
Designing a good program requirements document takes a lot of time, but is well worth the investment. The simplest answer would be to start from the most abstract ideas and work your way down into the nitty-gritty details. A well designed requirements doc starts off by stating what the program is going to do -- the most abstract answer to the most abstract question about your program: what is it? Asking yourself these questions, starting from the most abstract and working your way down, and then writing the answers out for yourself and team members to see clearly (a good design document is as much for your benefit as it is for your team's) will take the ideas floating around in the ether of your brain and cement them into something real.
A thing to remember when writing the document is to never get too specific too early. An architecht/engineer doesn't work on the fine details of the electrical wiring of the laundry room until he knows where the laundry room is, how large it is, what kinds of appliances can be expected to work in it, lighting requirements, etc. Only after all of these other questions have a clearly defined answer can he proceed to answer questions involving more minute detail. At the same time, don't be afraid to get as detailed as you want. If you want to write down pseudo code of how you think damage should be calculated, do it -- it might help you remember when you read the design document while you code.
You can expect a design document for a large scale project, like an RPG, to get to an enormous size spanning multiple chapters and files, and possibly take weeks or even months of writing and planning. A good program is 80% planning, 15% coding, 5% caffine ;)
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin
#16013 - sgeos - Fri Feb 06, 2004 5:56 am
| animension wrote: |
Designing a good program requirements document takes a lot of time, but is well worth the investment.
...
You can expect a design document for a large scale project, like an RPG, to get to an enormous size spanning multiple chapters and files, |
There is something that I would like to point out. You can properly design a game without a disign document. You can also write a proper design document without making a game.
When designing a game, you need to write the rules. A board game or a card game does not need a design document. When making a spreadsheet program one will really want a design doc. A design document is a software thing, *not* a game thing. If your game is going to be presented as software, skimping on important aspects of software development are a bad idea.
| animension wrote: |
| and possibly take weeks or even months of writing and planning. A good program is 80% planning, 15% coding, 5% caffine ;) |
I disagree. [EDIT: Over planning can be just as dangerous as under planning.] After requirements are done, I think about a third of the project should be spent designing it. The rest should be spent on construction- coding, unit testing, etc. More planning is needed for larger project. A 20 line project doesn't justify much planning.
QA is important too- a low defect rate goes hand in hand with getting things done quickly and cheaply.
-Brendan
#16046 - animension - Sat Feb 07, 2004 2:54 am
| Quote: |
A design document is a software thing, *not* a game thing.
|
What do you call a blueprint for a building, or a writer's outline for a novel? You can make a game by just writing rules you are conceiving in your mind down on a little napkin. Those rules are a small design document. A design document if a generic document that dictates how something is planned to be accomplished, laying a course for actions necessary to realize a potential design, the definition of which is an idea to be conveyed or expressed in visible form or as an action to be carried out.
| Quote: |
I disagree. [EDIT: Over planning can be just as dangerous as under planning.] After requirements are done, I think about a third of the project should be spent designing it. The rest should be spent on construction- coding, unit testing, etc. More planning is needed for larger project. A 20 line project doesn't justify much planning.
|
The context was that a role-playing game was being planned. A typical RPG is not a small undertaking. A GOOD RPG (anyone can write a game that sucks) takes a long time to plan, not just in the software realm. There's story building, world building, scenario drafting, script building (not the programming language kind, but the acting kind), music composition, sound effects editing, art creation and digitzation, and THEN software to tie it all together -- all of this becomes the program.
I can't emphasize enough that for a large project -- and this is true in (almost) every kind of project, you need a large amount of planning. It should be pretty obvious that a project's planning should be directly proportional to the scale of the project as a whole. The best answer, IMO, is to start at the top and work your way down answering more and more specific questions as you go. A small project will have less questions that need answering = less time planning. A large project will have a mountain of questions that must be answered, and if you don't take the time to answer them before you start, more likely than not it will come up when it's least convenient, possibly requiring you to change a large part of what has already been constructed.
It is much better to spend more time in planning than may have been necessary (to a degree) than to throw caution to the wind and end up pulling your hair out when it bites you in the rear. The larger the project, the larger the damage when improper planning takes place. Overplanning should be avoided, but if you are still answering important questions that need considering, chances are you are not overplanning.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin
#16053 - dagamer34 - Sat Feb 07, 2004 6:23 am
Go play Final Fantasy Tactics Advance. Pretend you developed it but forgot everything for some reason. What questions would you ask?
Examples:
1) How did the programmers do *insert effect here* effect?
2) When did they load the data?
3) How is the data saved?
4) What about collision detection (a BIG one!!)?
5) And the story, how did they come up with the story?
etc...
The idea is that you keep coming up with these kinds of questions until you have no more. Then you get someone fresh to look at it and if they see the same thing you are seeing, then you have a robust design document (chances are you won't though). But that is for a complete design.
A mini design would be the same idea except you don't get a stranger but someone who you haven't talked to much on your team (if you are the only person, then it better be small, large projects are overkill).
Get the idea? By the way, I have only made one game so i am just rambling. But something i said must be true.
_________________
Little kids and Playstation 2's don't mix. :(
#16072 - Ellipsis - Sat Feb 07, 2004 5:50 pm
Awesome. Everyone's views are really interesting. As of right now, I have a couple dozen pages of random notes that I'm going to compile into some kind of weird experiment for myself. Does anyone know about specifics though? Would I actually write each minor character's line of dialogue, like "Town's person #1 : walking near town gate - Hello, welcome to our shiny town!", or would I leave that in the air as to how I would populate the world? Coz I know my story details including NPCs and supporting characters, but I'm sure I'd want to have other people providing small details or having a personality beyond that of a typical store clerk (like Torenko from DW, only not). Anyway, I'm rambling, but the point to this post was to figure out if the smallest details needed to be included, and if anyone thinks I'd be better off including those in a seperate section or document from my main story? So, I'd a) write a screenplay (as it were), b) fill in the world with personality (i.e. NPCs and enemy descriptions), c) work out the game system and d) whatever else was needed?
#16078 - dagamer34 - Sat Feb 07, 2004 7:27 pm
Design documents aren't really for YOU but for other people on your team so that they know what you are talking about.
In the real world, the designer is not the programmer. Thats what the design doc is for.
If your engine can easily support the addition of another NPC, then it doesn't matter. You will easily be able to set up more NPCs wihtout any effort. If you have to spend hours on each NPC, you might want to add it in, because chances are you might screw up somewhere.
_________________
Little kids and Playstation 2's don't mix. :(
#16092 - sgeos - Sun Feb 08, 2004 1:34 am
| animension wrote: |
| Quote: | | A design document is a software thing, *not* a game thing. |
What do you call a blueprint for a building, or a writer's outline for a novel? |
Planning. I agree with you that planning is important. My opinion is that making video games is a two step planning process. First the game needs to be designed. After it is designed, it needs to be constructed. Constructing a video game requires writing a program. That program needs a separate set of plans. Supporting the game rules are one of the program's requirements. The program will have other requirements.
| animension wrote: |
| You can make a game by just writing rules you are conceiving in your mind down on a little napkin. Those rules are a small design document. |
That is a rules document. A rules document is not enough to build a game. A rules document for tic tac toe is very simple. Knowing that players take alternating turns, and that three in row is a win is identification of the problems to be solved. That is important, but we still need solutions. After we have solutions, we still need to construct the program.
| animension wrote: |
| A design document if a generic document that dictates how something is planned to be accomplished, laying a course for actions necessary to realize a potential design, the definition of which is an idea to be conveyed or expressed in visible form or as an action to be carried out. |
A design document has a slightly different meaning to me. By your definition of a design document, I think that a video game needs both a game design document and a program design document. A board game needs only a game design document. A generic computer program needs only a program design document.
| animension wrote: |
| The context was that a role-playing game was being planned. A typical RPG is not a small undertaking. A GOOD RPG (anyone can write a game that sucks) takes a long time to plan, |
Anyone can write a game that sucks, assuming that anyone can write a game. I do not think that anyone can write a game.
Good can be defined in many ways. I suspect that anything good (by any standards) that makes it to market must have at least a fair deal of planning behind it.
| animension wrote: |
| not just in the software realm. There's story building, world building, scenario drafting, script building (not the programming language kind, but the acting kind), music composition, sound effects editing, art creation and digitzation, and THEN software to tie it all together -- all of this becomes the program. |
80% planning still seems high to me. This may be a matter of what a given individual considers planning, and what one considers construction, assuming that there are no other activities in the breakdown. I'd consider music composition, sound effects editing, art creation and digitzation construction activities.
| animension wrote: |
| I can't emphasize enough that for a large project -- and this is true in (almost) every kind of project, you need a large amount of planning. It should be pretty obvious that a project's planning should be directly proportional to the scale of the project as a whole. The best answer, IMO, is to start at the top and work your way down answering more and more specific questions as you go. A small project will have less questions that need answering = less time planning. A large project will have a mountain of questions that must be answered, and if you don't take the time to answer them before you start, more likely than not it will come up when it's least convenient, possibly requiring you to change a large part of what has already been constructed. |
Agree. The earlier errors are found, the less chance they have to propogate downstream. Correcting errors in the planning phase is a lot cheaper in time and effort (= money, most likely) than finding and correcting them later. I'v heard that a good approach to planning is to keep refining the plan until it seems easier to stop planning and just put the thing together.
| animension wrote: |
| It is much better to spend more time in planning than may have been necessary (to a degree) than to throw caution to the wind and end up pulling your hair out when it bites you in the rear. |
The greatest danger in over planning is that the project may never get off the ground. A secondary danger is wasted time- most likely in the form of a solution before having a problem to solve. New problems pop up during construction. Not everything can be planned ahead of time. Changing requirements are also something that needs to be considered.
| animension wrote: |
| The larger the project, the larger the damage when improper planning takes place. |
Of course. The larger the project, the more there is downstream from planning. Losing a five hour project four hours in due to poor planning isn't a big deal. Losing a five year project four years in due to lack of planning would suck. (Understatement for the day.)
| animension wrote: |
| Overplanning should be avoided, but if you are still answering important questions that need considering, chances are you are not overplanning. |
IMHO, if one can actually get an overplanned project off the ground, that project is in a much stonger postion than an underplanned project. A little time was wasted planning, but there will be no lack of planning penalties later.
-Brendan
#16093 - sgeos - Sun Feb 08, 2004 1:44 am
| Ellipsis wrote: |
| Does anyone know about specifics though? Would I actually write each minor character's line of dialogue, like "Town's person #1 : walking near town gate - Hello, welcome to our shiny town!", or would I leave that in the air as to how I would populate the world? |
As far as the details go, first you need to define the problem- Characters in the game world need to be able to provide text feedback to the player.
From there, you'll want to find a bunch of solutions, and pick the one that works best for you. You could give each character a function to display his or her text, with or without strings located in the function. You could have a string associated with each character and have a generic function to display that string. You could have a pool of things that NPCs can say and select a random one each time the NPC is spoken to.
As far as any (other) details go, first figure out what the problem is. After you have done that, try to come up with solutions. If you need help with the solutions, or just want feedback in general, feel free to post on the appropriate forum.
-Brendan
#23314 - allenu - Fri Jul 09, 2004 8:03 pm
I'm going to have to chime in and say that design documents of any sort are
very useful, and not just if you are in a team. Even if you are working alone
on a project, you are going to want documents of some sort to help define
what you are trying to do.
For me, designing is more fun than actually coding everything. The coding
process is not boring, but I've found from my experience that if I design
things well enough in advance, coding is very trivial and things just
seem to fall into place.
As for designing an RPG of some sort. You'll want to start a high level
first and ask yourself just what it is you want it to look like. Then, you'll
have to determine just how you will implement it. This will likely require
a game engine of some sort.
I've designed some BBS games long ago and am now moving onto the
GBA platform just for fun. If you want to see how I'm progressing with
my project, just visit this page: http://www3.telus.net/allenu/Wiki/ProjectHazuki.html . I'm still in the
planning and designing phase.
Last edited by allenu on Thu Aug 12, 2004 3:51 am; edited 1 time in total
#24805 - phrax - Wed Aug 11, 2004 8:55 pm
Is there a sample on the web for a Game Design plan. I tried all of the links mentioned on this thread, but they were all broken.
#24836 - allenu - Thu Aug 12, 2004 3:54 am
| phrax wrote: |
| Is there a sample on the web for a Game Design plan. I tried all of the links mentioned on this thread, but they were all broken. |
I've fixed my link in the post above. It should work now. As for the design
that I'm thinking of, do a search on software development and design.
I think that might be more useful if you are talking about technical
aspects of designing a game engine. On the other hand, if you mean
designing games that are fun to play, I dunno.
#24839 - sgeos - Thu Aug 12, 2004 8:19 am
| allenu wrote: |
| if you mean designing games that are fun to play, I dunno. |
Reading Greg Costikyan's article on what makes a game (as opposed to a puzzle or story) is a good place to start.
-Brendan
#24857 - sandymac - Thu Aug 12, 2004 5:23 pm
#26040 - keldon - Sat Sep 04, 2004 3:52 pm
these links should be in the FAQ