6 replies to this topic

[Sarrene]

Hello everyone!
I am not so new here, though this is the first time I have posted. On a good note, these forums have been very informative over the last few years, though I have not really had much I could contribute to. So please pardon my first post being nothing more then a few questions.

Let me introduce myself, I am Sarrene. I have worked on a few games, though I was primarily a contract artist and cell designer. I have been drawing and creating things since I was .. Oh, I got into trouble for the first time around 5 for drawing a mural on the back of the garage.. in oil pens. (not sure if anyone remembers those from the 60's.) Now in my defense, it was a very good picture! Anyways, since then I have always loved to draw and create anything I could.

Now, for my questions. I have just started up a game design company (Yes,I know.. another one!) We have been working hard in our research over the last year. Completed most of our business paperwork, (business proposals, business mission statements,...) have what we need or can get copyright on, have our business license, Completed (again) our Game Design Proposal... Okay, I wont bore you with the rest. I am sure you all know that drill already.

I am now at the end of our design documents, and I am wondering a few things.
1) How big is too big for a design document?
I am not completely finished bring all of our notes into the document, but to give you an idea, our table of contents is 26 pages long. That seems HUGE to me. I have read some GDD's that were very large, though I am unsure at this point what can be considered too much information and too large.

2) When I print out our GDD for presentations and for our developers (the few we have now and any that join us later on) should I print on both sides or only one?
I ask this one because it seems to be a bit of a debate depending on whom you are asking. I had one company that did it one way, and another that did it the other. Which do you recommend?

And for my last question...
3) What animation software do you all recommend for my artist and single animator?
I have dabbled in animation a little bit but have always ported in from 3dsm to the engine and done the tweaks there. However, even though I have a basic understanding of animation itself, I do most of my work with 3d models and textures and cell/world design.

I am sure that these questions have been asked a lot. I have browsed through the forums the last several days reading a LOT of posts. And well, I am just not sure yet. I was told by one old boss that hired me for two projects that the more detail you have in the GDD the better it is, and easier it is to make adjustments later on. To keep everything documentation. This I know is sound advice. Yet, I do worry I might be getting into too much detail.

Your thoughts? I recommend and welcome any and all advice, suggestions or even constructive criticism.

Thank you for your time,
Sarrene'

[imerso]

Hi,


Just to sum to other people opinions:

1) I would say that it is huge for a Tic Tac Toe like game, but may be not enough for a World Of Warcraft clone. You have to describe the game with enough details, and the number of pages will vary with the game complexity.

2) I generally print using the two paper's faces, because that is more ecologically correct.

3) I am basically a coder, but I like 3DSMAX and BLENDER very much.


=)

[Sarrene]

<nods> Makes a lot of sense there. I am still trudging away, and each time I think I am getting near I remember or get another revision. Sometimes it seems as if this is going to grow legs and get away from me. Okay, I will not worry about the size then and just finish up. I was/am going into great detail, including things like height scale, weight, colour wheels, concept art (or references to) and so on. I was just a bit too woried I might have been going into too much detail.

As far as printing out the GDD goes.. that makes sense as well. I have our contracts, nda's, business agreements and so on printed one side, though I know those are a bit different then the GDD.

Animation: We have 3ds man 2009, so that is not a bad choice then. I think what i was wondering about was the import/export of those animations from game part1 to game part2 (complicated or weird sounding I know). Okay, well I will let them at that then and continue unless someone else has a better idea or suggestion. Not that I am looking to spend more money! Between corporate editions and unlimited seat licenses and.. ugh! I am just on the first few steps yet, though the cost has already started. Yes, I know.. it is going to get even more expensive as we go.. and hopefully grow a bit.

Thank you for your reply. I will stop prattling on .. for now ;).
Have a great afternoon.

[TheNut]

1)

Sarrene said:

I was told by one old boss that hired me for two projects that the more detail you have in the GDD the better it is, and easier it is to make adjustments later on.

He's partially right. Proper documentation is good, but if you did it right then you should not be coming back later to make adjustments. That's very bad, especially if they're large changes. The whole point of documentation is to plan what you're going to do so you don't run into problems or guess work down the road.

There is no concrete page limit for design docs. In my field (engineering), you should cover everything, even at the lowest possible detail if time permits. If you skip out on detail and leave it up to the developer to fill in the gaps (fine in some trustworthy situations), you can run into what we call a "disconnected" moment where "he thought that", but "I thought this". It can turn into a ripple effect where all of a sudden QA will log bugs against what they think is expected behaviour and so on.

Lots of people hate docs and I admit it can be daunting staring at 100-200+ pages. Try to make it easy to read. Just because it's 100+ pages doesn't mean it has to be in paragraph format. Write in tables and point form. So long as it gets the message across clearly (in this case, much more clearly), the better.


2) We consider printing taboo. Computers are supposed to save trees, not condemn them. Give your developers two or more monitors. Give them comfortable, relaxing lighting and train them to dim the lighting on their monitors to a comfortable level. Reading off a PC, especially with search functionality, is vastly superior to printouts.


3) That's a bit of a tough question. Some companies let the artists use whatever they want, so long as their tool can export to a format supported by the programmer's tools to convert into their own game format. Others have strict codes that artists must know how to use Max or Maya and the developer will write an importer and exporter for it, though even in that situation a talented artist still gets around using other software in the mix. It's really up to you to decide how you want to approach this because it is a business decision.

[Kenneth Gorking]

3) I read an interresting article on Gamasutra yesterday, that deals with this very issue: http://www.gamasutra...eature_the_.php

[TehOwn]

1 & 2) Just to clarify, there are three types of document which are often referred to as the Games Design Document.

Firstly is the actual Games Design Document, which is an organised set of all of the design elements of the game. And I mean everything. For instance, in an RPG, this would cover the World Setting, General Areas, Themes, Weapon Types, Bonuses, Health System, Magic System, Leveling System, Monsters, Bosses, etc, etc. Everything EXCEPT specific implementations, which are left down to level designers and content developers.

This is written, usually, by the Lead Designer who is defines the original path of the game and ensures that people stick to it as much as possible.

Secondly, there is the Game Pitch Document. (for want of a better term) Which is a summary of the game structure, the reasons behind the concept, target audience, as well as some of the key selling points.

This document is designed to capture people's attention and make them want to know about the game. It is to convey the idea of what the final product would be like and why someone would want to buy it.

The third document, is the Technical Design Brief. This is to make sure that all of the technical elements come together, that the Engineers can provide all of the functionality that the designers need and that everyone understands the format that things need to be in. It is generally used by the Engineers to make sure everything gets done and meshes together nicely.

Lastly, while people get confused over terminology, you can sort that out by explaining your point in detail. Once anyone opens up a document, it is easy to tell what kind of document it is. Just don't send the wrong document to the wrong person, because using a GDD (or even worse, a technical brief!) for a pitch would be a fatal mistake...

P.s. It is perfectly fine to print out documents for pitches, but these should usually be no more than two dozen pages long and be very well written and have lots of pretty pictures and no spelling mistakes!

P.P.s. - I worked for a company where the GDD was literally copied-and-pasted into the Game Manual... I only found out after the Manual had already been sent to Localization... So I had to stay up all night working on a revised copy so that Localization could have it by morning... Nightmare!

[Sarrene]

In regards to the type of document.. Luckily I am not in charge of the Elevator Pitch. I am good at writing something technical, I am good at writing stories. I seem to have a difficulty with the middle ground.

Proper grammar and correct spelling IS an utmost MUST I would think in any document. Though I know mine is atrocious (And I did not even use spell check on that one) I do use spell check, and then run all documents through my business manager and my "proofer". They both can have some difficult times, I am sure. At least they are not reading my hand written documents!

The different documents we have currently are:
Business Proposal
(And all accompanying documents related to that)
Game Design Proposal
Game Design Document
Technical Hardware Design
Technical Software Design

Are there any that I am forgetting? Minus any on the actual business side of things, of course.

As far as the GDD goes, I am not printing this for each dev that is or maybe on our team.. that will be viewed via computer :D Saves printing time. The printed version is for any presentations, and all other fun business side of things.

However, I am not sure about the revisions itself. All GDD's I have experienced in work have been "Living documents". As things are not able to get done, find out they do not work, etc.. Parts of the document have changed. Changes have always been noted either in the head of the document or at the end in the Appendage. So I am not so sure I understand what you mean. Perhaps I am misunderstanding what you meant? That is, of course, very likely.

By the way... Thank you everyone for the help. This can be a daunting task for sure, but defenatly well worth it. I have always admired those I have worked with that do the coding and scripts and help tie everything together that the rest of us have done. Though I am seeing more of that now, as well as what the other lead designers have had to go through. So thank you very much for the help and advice.

Anything else you can think of that I might aught to consider, I always have my ears open to.

Peace, and have a great night,
Sarrene'