Ajene
Guest
|
|
« on: February 04, 2009, 09:11:48 PM » |
|
Learned a lot since then, just getting rid of old posts don't mind me
|
|
« Last Edit: December 30, 2009, 12:45:30 AM by Ajene »
|
Logged
|
|
|
|
Xion
|
|
« Reply #1 on: February 04, 2009, 11:03:29 PM » |
|
The games rating
Um, what rating?
|
|
|
Logged
|
|
|
|
Ajene
Guest
|
|
« Reply #2 on: February 04, 2009, 11:41:58 PM » |
|
Meaning Rated R, E, PG-13 basically what you plan on having in the game your target audience is what i should have put.
|
|
|
Logged
|
|
|
|
Mir@k
|
|
« Reply #3 on: February 08, 2009, 01:34:53 AM » |
|
And here i always thought a design document not only had to have storyline and descriptions, but resources to be made, gameplay, size of game screen, size of in-game sprites, color pallete limitations, aproximated quantities of enemy sprites, animation planning, frame rate, control schematics, GUI structure, sound effects, background music titles, you know, important stuff.
|
|
|
Logged
|
|
|
|
Problem Machine
|
|
« Reply #4 on: February 08, 2009, 01:51:27 AM » |
|
To be fair a lot of that stuff would probably wait until the proposal/design document draft was approved. There should be something about the overall aesthetic and gameplay style of the game in there though, and less about world-building. In fact, I think the only story that should be in the initial draft is major characters and a rough outline of the plot. Adding some concept art would be a really good idea if you want to pitch it to anyone as well; mockups are even better, and a prototype would be ideal.
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #5 on: February 08, 2009, 03:17:45 AM » |
|
Though your advice seems sound Ajene, I cannot help but wonder what your qualifications are. Have you actually ever put together a large game, starting from a design doc? Or are you just spouting truisms. Particular as I would have thought the first thing you should do with a design doc is decide on gameplay. You seem to be assuming that everyone is making an RPG.
|
|
|
Logged
|
|
|
|
ஒழுக்கின்மை (Paul Eres)
|
|
« Reply #6 on: February 08, 2009, 06:51:50 AM » |
|
Didn't I already post a design doc tutorial? Do we need two? I guess it couldn't hurt.
|
|
|
Logged
|
|
|
|
Cymon
|
|
« Reply #7 on: February 08, 2009, 07:46:41 AM » |
|
Personally I'd just say use a template and go from there. However, if you have a small development team, say less than 5, design docs are really redundant. It's one of those things you do once for the academics, and then probably never again, as in a professional software house the writers do the design docs, not the programmers.
|
|
|
Logged
|
|
|
|
ஒழுக்கின்மை (Paul Eres)
|
|
« Reply #8 on: February 08, 2009, 07:50:13 AM » |
|
I found them useful even for smaller teams; it depends on the length of the game. Big games made by one person benefit from design docs too, especially RPGs. And with most genres, the very least, you usually benefit enormously from having, say, a list of the items, weapons, areas, and enemies you intend to have in your game. Thinking about those ahead of time is usually a lot better than making them up as you go along. It'd be like trying to direct a movie without a screenplay, or trying to write a novel without an outline: it can be done, and has been done successfully, but it's not as easy.
|
|
|
Logged
|
|
|
|
|
Ajene
Guest
|
|
« Reply #10 on: February 08, 2009, 07:16:56 PM » |
|
|
|
« Last Edit: December 30, 2009, 12:46:28 AM by Ajene »
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #11 on: February 09, 2009, 03:19:44 AM » |
|
In 2005 i set up a MMORPG using a design doc as such. We had an engine, i had 6 3D Modelers, 3 Concept artist, 4 Plot writers, 5 Animators, 3 Composers, and 7 Programmers (including myself when i was working with programming) the engine we were using was Realm crafter so the game should've been simple to make, and easily able to get a beta out within 6months. Though it turned out i was working on it alone due to having a bad staff. I had a couple of people still working with me, But many couldnt do as much as the people i had put in charge of the division.
Why don't you write about your experience, then? A post mortem, or a discussion on how to get/judge other team members. Or even just "You know your project isn't going to work out when...". BTW, for anyone interested, the design doc for the never released "Sonic X-treme" can be found here. Might be good for giving you an outline, though I personally found it far too in detail to read.
|
|
|
Logged
|
|
|
|
Ajene
Guest
|
|
« Reply #12 on: February 09, 2009, 06:58:35 AM » |
|
I'll do a discussion on choosing team members later.
|
|
|
Logged
|
|
|
|
TheSpaceMan
|
|
« Reply #13 on: February 24, 2009, 03:24:30 AM » |
|
A misstake many people do I think. Don't mix up the design document with the tech document, and don't mix up a design document with a pitch.
The pitch can be short colorful and quickly describe the game for anyone to understand in just a few pages.
A design document according to me should contain little gameplay details and more suggested gameplay implementations followed with a flowchart containing cause and effect of said actions.
also the level layout, important objects, how much you can see.
The actuall resolution and implementation of the flow chart could go in to the tech design but probably not. It should go into a game specific documentation covering how stuff is implemeneted and work side by side with documentation over certain areas. This is a area from where designers are banned. If you are working on the implementation directly or a area affected by other implementations you are welcome. a designer would be allowed to read this, to get a insight in the code processs, but not change anything without making another flow chart of how the new system should work or a modification of a existing flowchart to patch holes.
The reason i don't think you should focus to much on this and that would be cool is that story still require underlying systems that needs to be tested before it's sure it's even going to be fun and even if it's nice to write say a 20 level walktrough with storyline and cool characters, be sure you will actually be able to use it.
|
|
|
Logged
|
|
|
|
r.kachowski
|
|
« Reply #14 on: March 30, 2009, 12:13:42 PM » |
|
I don't suppose it's theadcromancy if it's still on the front page, but are there links to examples of completed design docs? (aside from the ones referenced in Rinku's topic)
I think it would be quite handy to have a list of completed gdd's for referencing structure and level of detail.
Also, as an aside, how long would you spend working on an average design doc without the intention of turning into it a full game? I mean writing a gdd just for the sake of fleshing out an idea and giving it some rigidity.
|
|
|
Logged
|
|
|
|
ஒழுக்கின்மை (Paul Eres)
|
|
« Reply #15 on: March 30, 2009, 12:46:51 PM » |
|
Depends on the size of the game, type of game, etc., but in my experience my design documents have taken me anywhere from a few weeks to a few months.
I don't know of any good list of design documents other than the ones mentioned in my thread on this subject, unfortunately. There are a few on gamasutra.com though.
|
|
|
Logged
|
|
|
|
nihilocrat
|
|
« Reply #16 on: March 31, 2009, 07:14:56 AM » |
|
The design documents for Metal Gear Solid 2, Grim Fandango, and Planescape: Torment are freely available if you look for them.
The only use I see in design documents is the ability to think everything through before you start, and having a common document for a team to refer to when implementing the game.
|
|
|
Logged
|
|
|
|
Cthulhu32
|
|
« Reply #17 on: March 31, 2009, 02:37:45 PM » |
|
|
|
|
Logged
|
|
|
|
György Straub
|
|
« Reply #18 on: March 31, 2009, 05:45:30 PM » |
|
The only use I see in design documents is the ability to think everything through before you start, and having a common document for a team to refer to when implementing the game.
that's so seconded. I'm just through with my second game (in c++, on x86, etc.), a relatively big one and considerably bigger than the first one. I actually didn't use a document, but it's getting clearer and clearer how much headache could I have saved if I did. Not planning actually killed my original second-to-be game, because I wasted SO MUCH time switching back and forth between two solutions to different problems, that I missed the deadline without getting a lot done, then outside a competition I just didn't want to touch that game anymore.. So yeah, planning is important, in the beginning mostly - so that you know what you want and how.
|
|
|
Logged
|
|
|
|
|