I've been designing an action RPG for over a year now as a side-project. I've also been working on a my own game engine for the sake of learning more about game programming for about 4 years now, and even made some headway on getting some of the basics programmed for this game.

My design is over 200 pages long at the moment (more than Pirate_Lord could ever write), and growing... Like I said, this game is fully-featured game that has a lot of elements in it from various games such as Zelda: Ocarina of Time, Diablo II, and a couple of Final Fantasy games. The plot is deep and follows 4 characters. The plot's narrative alone is currently around 20 pages (single-spaced), and it is being revised. I full descriptions of all main and supporting characters, but I do not have a complete Bestiary (kind of like an encyclopedia of all enemies and bosses encountered in the game) yet. I have a complete set of equipment such as armor, weapons, their "classes", descriptions, etc setup. I also have plans on having an complete original soundtrack for this game. This document also consists of a variety of floor plans for the game's maps the player will travel on. The game is open-world, and pretty expansive for my targeting platform aim (iPhone).

I know this project sounds ambitious, and it is! I am also well-aware that with my current resources, this game cannot be developed right now. I'm actually working on much smaller projects for other people, and stashing this one away until I can make it actually happen. I'm also still trying to strengthen the stability and features of my engines so that when it does go into production, it will look, sound, and feel amazing. One thing I would like to mention that I do have access to very talented friends who can actually develop the entire soundtrack for this game for free right now. So... the soundtrack is about the only major task I could finish if it was necessary.

Now that I have given you an idea of how deep the scope of this particular game is, I would like some information on how long the design documents usually are for triple-A RPG games. This is actually what I'm going for design-wise. I have read in past articles that design documents can get to be around 700 pages or even more. Judging by what I currently have in my game's design, how much more tweaking should there be?

I have not done much on the actual dialogue scripts yet. Would the complete dialogue script be developed preproduction as part of the design document, or during the game's actual production as an asset? I know Uncharted 2 had quite a bit of dialogue involved with that game despite its linear gameplay. Amy Hennig at Naught Dog said she wrote a script that was around half an inch (roughly 1cm) thick. Seeing how much work went into utilizing this script in the form of motion-capture scenes while voice recording, double-over voice recording, etc. In my game, there isn't much based off of the dialogue script since it is all text for dialogue like older games.

One question regarding audio in preproduction: I do have a little bit of an idea on how I want the music to sound,but who's decision is it for when the music is being written? How should I discuss music in my design document? Right now, I think the director (me) would give the composer a ballpark idea of how the music is supposed to sound, and then the composer would have to fill in the blanks himself. The composer will usually have access to certain cut-scenes to get an idea of what is going on to project the right emotion.

Quote:

Original post by Vincent_M 1. I would like some information on how long the design documents usually are for triple-A RPG games. ... how much more tweaking should there be? 2. Would the complete dialogue script be developed preproduction as part of the design document, or during the game's actual production as an asset? 3. I know Uncharted 2 had quite a bit of dialogue involved with that game despite its linear gameplay. 4. I do have a little bit of an idea on how I want the music to sound,but who's decision is it for when the music is being written? 5. How should I discuss music in my design document? Right now, I think the director (me) would give the composer a ballpark idea of how the music is supposed to sound,

1. As much or as little as you want, since there is no project lined up yet. Gap-filling can safely wait for now.
2. You can go ahead and write that now, and polish it when the project starts.
3. Why is the word "despite" in that sentence?
4. I don't understand the question "for when the music is being written" -- but since it's your design, put whatever you want in it.
5. Yes. Do that. Cite composers and instrumentation, genre, example pieces, whatever you need to get the idea across.

Well at work some guy from Brazil wrote out a 50 pages.pdf MMORPG design concept ... and it was a disaster. We - the game designers - didn't approve it because the gaps and leaks were too many and too big. It was like building a skyscraper on sticks. It felt really uncompleted. Maybe if it was a little more descriptive about - well everything - we could approve it and begin development.

So my advice is to be descriptive and do not mind the page counter - great things don't happen easily. I mean people don't mind to read a lot of paper - they'll just do it instead of wasting their time on facebook aps X_X .

Quote:

Original post by altras Well at work some guy from Brazil wrote out a 50 pages.pdf MMORPG design concept ... and it was a disaster. We - the game designers - didn't approve it because the gaps and leaks were too many and too big. It was like building a skyscraper on sticks. It felt really uncompleted. Maybe if it was a little more descriptive about - well everything - we could approve it and begin development. So my advice is to be descriptive and do not mind the page counter - great things don't happen easily. I mean people don't mind to read a lot of paper - they'll just do it instead of wasting their time on facebook aps X_X .

It's an MMORPG with 50 pages of documentation. What do you expect? :P

Quote:

Original post by Hardcharger Quote: Original post by altras Well at work some guy from Brazil wrote out a 50 pages.pdf MMORPG design concept ... and it was a disaster. We - the game designers - didn't approve it because the gaps and leaks were too many and too big. It was like building a skyscraper on sticks. It felt really uncompleted. Maybe if it was a little more descriptive about - well everything - we could approve it and begin development. So my advice is to be descriptive and do not mind the page counter - great things don't happen easily. I mean people don't mind to read a lot of paper - they'll just do it instead of wasting their time on facebook aps X_X . It's an MMORPG with 50 pages of documentation. What do you expect? :P

I know! that's crazy! It's the reason I think I couldn't design an RPG. There's so much you need to put in. By all means I'm not lazy but I couldn't write 20 pages on all the enemies in the game.

That said, I am designing an action-adventure game at the moment and that is alot of content to write about. Wouldn't mind designing an action game to be honest, possibly a TPS based around the 3DS hardware (got a concept bouncing around at the moment) but my current project comes first. :)

My personal view is that if you have a design doc of 200 pages in size, or even 50 pages in size, then your design doc is full of detail that shouldn't be in there. It should be broken up into several docs. I would say that the design doc should contain only the stuff that is relevant to all your developers.

"The plot's narrative alone is currently around 20 pages (single-spaced)"

Take it out. You should be able to summarise the plot in half a page. You should be able to use the other half of the page to explain how the plot affects the game in design terms and (very broad) technical terms. The exact twists and turns aren't terribly relevant in implementational terms. Put all this in an appendix or separate doc.

"full descriptions of all main and supporting characters"

Again, take it out. Most of this is irrelevant to the coders and only partially relevant to most designers. It should go in an appendix or a separate document.

"I have a complete set of equipment such as armor, weapons, their "classes", descriptions, etc setup"

Appendix. This is data, not content. The main body of the doc should detail the combat system and how different classes of weapon might affect it but you don't need tables of all the items in there. Yes, it should be specified, but not inline with the rest of the doc.

"I also have plans on having an complete original soundtrack for this game."

Explain the styles you want with reference to composers and existing music. State how many pieces you need, how long they will be, and where they will be used. Note any technical concerns such as file sizes, requirements for looping, etc. - stuff that is relevant to developers and the musician.

"a variety of floor plans"

Not in the main body of the document. A list of the names and any gameplay implications, on the other hand, sure.

Note that although I am saying to take a load of stuff out, I'm not saying you should have an empty design doc. I am saying that your design doc should not in any circumstances be a big dump of data and lists of stuff. In my opinion it should be this:

- a brief overview of what the game is trying to achieve (synopsis, platform, target market, genre, presentation style, plot outline)
- describe game mechanics, the dynamics between the mechanics, and the aesthetic that these dynamics are there to create. (Google for the MDA framework.)
- these features ranked either Essential, Important, or Optional, so that development can be correctly prioritised and scheduled
- that's about it

I know everybody loves to go away and write up lists of monsters, lists of dialogue, draw up all the floor plans, etc. That's the fun part of design. But when you come to the actual development, you'll find that things change. You'll realise that it's taking 2 months per monster so you have to scale down from 20 monster types to 10. You work out that a certain scene is not all that enjoyable so a load of dialogue becomes irrelevant. Your combat system might turn out to be unwieldy so either you completely scrap a significant class of weapons or you rewrite much of the system.

Your game's going to evolve as you make it and you don't want to have wasted a lot of time on writing stuff that will never make it into the final design. I'd say it's better to concentrate on the abstracted core of the design and fill in those details later. Describe your game system, not the game content. The content will grow (or shrink) naturally in the hands of the skilled people you set to work on it. But the system is the important part that you need to nail down yourself, and your design document should be mostly dedicated to that.