Hi,
Just registered, first post here, been a lurker for a while. I'm not sure if this post belongs here or in the newbie area, so mods, please move it if needed.
Background: I'm a software developer, with about 14 years experience with C/C++. Lots of game playing experience, no game development experience. I started playing around with Java and Android a few months ago. I have 3 fairly basic games out on the market, and have decided to try and tackle something more substantial. I read many articles on writing game design documents, and the only thing in common is they all say "Each one is different". So I tried to write down some stuff that I hope will help focus and drive the coding phase. I honestly have very little idea of what I'm doing, so I would appreciate feedback on things I haven't thought about that could turn into "oh sh*t" moments later during development. Warning: This is fairly verbose, some of it might seem like a ramble. I would also like to know the areas where I need to focus my thoughts more. Also, I realize that some parts are pretty vague. At this stage, I know what I want to do in some areas, so those are described in greater detail, while other aspects are still largely TBD.
Part 1
Part 2
Thanks for looking.
Ziggy
Tried to write my first game design document, would appreciate feedback
I'm not in the business, so take my advice lightly... but I've written many docs for myself. One thing that really sticks out for me. There really isn't anything in there about how the game is going to work other than stating it's a plat former, with these weapons and these bad guys.
Some of the things I like to incorporate in my docs, just as an example;
1: When the player is hit, he should stagger backwards. This along with maybe a small blood spurt should act as a visual que that the player was hit.
if (hit)
{
adjust velocity in opposite direction.
play stagger animation.
play blood spurt animation
}
Ofcourse the above psuedo code makes more sense, because I would also describe how my animation and event systems would work. The main thing to think about is this, if someone else that's not using your brain read it, would they envision the same idea you have. You want to put enough detail in there that your design stays the way you see it, but not so much that you're coding it twice.
Also take for example an arkanoid clone. I would have somthing along the lines of;
2: The player's score increases by;
- each block that breaks adds points
- each falling bonus adds points
- each ball alive at the end of the level adds points
- the score should never go above 999,999
The players score decreases by;
- each negative bonus lowers the score
- the score should never go below 0
Once again, there nothing coding specific, but it gives a concrete idea of how that one variable in the game is going to change throughout.
What you have is more of the summary, rather extended summary, but it summarizes your goals for the game. So pretend you're not you when you're writing a doc. I'm not you, and despite the fact you keep mentioning prince of persia, your doc keeps making me think of metroid.
Also, if you haven't found it yet... check out www.gamepitches.com, they have a collection of design docs, and game pitches, concept docs and so forth from the AAA guys in the industry. My favourite being the one from the original Grand Theft Auto (renderer design), and fallout;
Some of the things I like to incorporate in my docs, just as an example;
1: When the player is hit, he should stagger backwards. This along with maybe a small blood spurt should act as a visual que that the player was hit.
if (hit)
{
adjust velocity in opposite direction.
play stagger animation.
play blood spurt animation
}
Ofcourse the above psuedo code makes more sense, because I would also describe how my animation and event systems would work. The main thing to think about is this, if someone else that's not using your brain read it, would they envision the same idea you have. You want to put enough detail in there that your design stays the way you see it, but not so much that you're coding it twice.
Also take for example an arkanoid clone. I would have somthing along the lines of;
2: The player's score increases by;
- each block that breaks adds points
- each falling bonus adds points
- each ball alive at the end of the level adds points
- the score should never go above 999,999
The players score decreases by;
- each negative bonus lowers the score
- the score should never go below 0
Once again, there nothing coding specific, but it gives a concrete idea of how that one variable in the game is going to change throughout.
What you have is more of the summary, rather extended summary, but it summarizes your goals for the game. So pretend you're not you when you're writing a doc. I'm not you, and despite the fact you keep mentioning prince of persia, your doc keeps making me think of metroid.
Also, if you haven't found it yet... check out www.gamepitches.com, they have a collection of design docs, and game pitches, concept docs and so forth from the AAA guys in the industry. My favourite being the one from the original Grand Theft Auto (renderer design), and fallout;
Author
Thanks a lot for taking a look through it. I see what you're saying about it being more of a summary than a design document. I like your suggestion about writing this so someone else could develop the game and end up with the same idea that's in my head. That would lead to specifics about how the game works, and might also help me figure out the parts where I haven't yet fully formed the ideas in my head.
Ziggy,
The purpose and the audience determine the form of what you should write.
The concept doc is to get short-attention-span type folks (execs, for instance) excited so they want to see more.
The treatment, or pitch doc, is to get money people and decision makers enough info so they know whether or not they want to fund the project.
The GDD is to tell the team what to develop.
The purpose and the audience determine the form of what you should write.
The concept doc is to get short-attention-span type folks (execs, for instance) excited so they want to see more.
The treatment, or pitch doc, is to get money people and decision makers enough info so they know whether or not they want to fund the project.
The GDD is to tell the team what to develop.
Author
That's a good point. I'm just by myself, and I'm doing this in my spare time, and not looking for funding. What I'm mostly trying to do is lay out my thoughts on paper so I can look at it and have some level of confidence that it makes sense, I don't think I've missed anything, and I've described stuff in enough detail that I hope I won't be doing a lot of code refactoring a few months later. That's my primary objective. So I figured a design document was the closest to what I wanted to write, but there isn't a development team that I need to communicate ideas to. I guess I should focus on all the TBDs and unknowns, and make sure I've described all the game mechanics and the characteristics / behavior of all the things in it, and then hopefully that should be a good point to start coding from.
Seems okay. Concept is very simple. You could always figure things out as you're making it.
Author
Thanks. I started coding up some utility classes for weapons and enemies, since it looks like those are the areas of the game where I have the most concrete ideas. Once I have a couple of enemy and weapon types, I'll put them into a world and start prototyping the gameplay. I'm hoping that once I've been through a couple of prototypes, I'll have a better idea of how to structure the code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement