Maybe I am thinking ahead of myself. But what do you have to make sure to include into your design to make the work of a programmer easier? I know numbers and things like item attributes, damage ratios, etc. Also, how does one schedule when estimating the creation time for the project as to not overwork your programmers(less time means less quality), but not end up taking an excessive amount of years(more time means more money). Should I consult a programmer before finishing up the document(so I have an idea of what things I can and can not do within time)? or wait until I am completely finished with the design document and then ask(so I may end up having to edit my design and taking out features or shaving off of some).

(Most of my experience comes from building business apps but I think they can be treated the same mostly in this case and others will correct me)

I do not believe in sharing the design only when it has been finished for a couple of reasons:
1. How do you know whether you're done or not?
2. The last 20% of detailing takes too much time and is definitely not what the programmer needs to get started.
3. Expect the design to change, not just because you and the programmer change their minds or some things just can't be implemented, the customer will change his mind too at the most annoying moments.

There is something else that is a real pain: documents. Don't get me wrong, you need them but the step from translating them from a scrap of paper into code and assets can be very hard. So next to some documents (story lines, conceptual art) that will give the programmers some feeling for the atmosphere, please provide prototypes. Rough versions of characters, buildings, fonts, levels etc. As long as they are rough everybody will expect them to change or being replaced over time but it will greatly enable the programmers to quickly build a concept/prototype themselves to get back to the designers to gather more feedback.

Do not spend too much time on calculating specific attributes. Most of the time they are easy to adjust later on (and they should and will be after testing by real testers)

By repeating this cycle many, many times you will be able to stop when needed and still have something to show that is more than a design paper; you'll have an actual program.

A programmer needs to know your high level design. Plain and simple. I would leave it up to the programmer to decide the best implementation method for what you want. The two of you can work out the minute details together to ensure you're actually on the same page.

One thing I would specify is what exactly you want to be easily tuned (like damage ratios, etc.) since the programmer can implement the system such that you can play around with it without the bottleneck of a programmer later on. This is vital since no one gets everything (or anything really) right the first time.

As for scheduling, you'll need at least one experienced programmer to estimate the various (programming) tasks at the start, then you can give yourself some buffer room and re-evaluate how you're delivering to your schedule at various checkpoints (every month or two) along the way. This way you can catch when you're falling behind and more easily allocate more or fewer resources to deal with it, or simply change the scope of your project.

Don't go crazy with the details now. Like ernow said, things will change all the time, and the design at the end will vary a lot from what was originally put forward.

Although game design and coding will most likely change many times a good clear documentation can help a lot.

1. clear requirements:
What is your goal ? What are 'must haves', 'nice to haves' ? What should be avoided ? Use clear keywords like 'have to', 'don't have to'.

2. don't leave design decisions to the developer:
I often encounter 'unfinshed' design descriptions. One half has been described the other half seems to be logical, but 10 different people have 10 different 'logical' views of a problem solution. If you want to happen it this way, write it down, even if you think that it is logical !

3. Check feasability
If your game design needs features not commonly used in other games, try to check the feasability with an experienced developer.
If your game design purely relied on a endless, free roaming, completly destroyable world, you should really check it !

--
Ashaman

You might find it useful to have "checkpoints", which I've seen used to good effect.

"Checkpoint 0" which is a high-level meeting where everyone involved discusses the overview of what you are designing... no design actually exists at this point, it is just a discussion of what you are planning on designing at a very high level, and everyone involved gives input about technical challenges/considerations, VERY rough estimates for work involved, etc.

"Checkpoint 1" occurs after the rough design is in place. Everyone gives feedback, the design will undergo some changes, and a firm design is in place. Devs can give more accurate estimates, and start working on their implementation, since high-level details are agreed to.

"Checkpoint 2" would be after the design has undergone some changes as things have developed, and you are somewhat "code complete". At this point, everyone can look at the final product, and make sure that it is satisfactory.

Long story short, keep "everyone involved" involved every step of the way.

Quote:

Original post by ernow (Most of my experience comes from building business apps but I think they can be treated the same mostly in this case and others will correct me) I do not believe in sharing the design only when it has been finished for a couple of reasons: 1. How do you know whether you're done or not? 2. The last 20% of detailing takes too much time and is definitely not what the programmer needs to get started. 3. Expect the design to change, not just because you and the programmer change their minds or some things just can't be implemented, the customer will change his mind too at the most annoying moments.

Someone here is a fan of Agile development, huh? :) (me too)

Quote:

Original post by Tebriel Quote: Original post by ernow (Most of my experience comes from building business apps but I think they can be treated the same mostly in this case and others will correct me) I do not believe in sharing the design only when it has been finished for a couple of reasons: 1. How do you know whether you're done or not? 2. The last 20% of detailing takes too much time and is definitely not what the programmer needs to get started. 3. Expect the design to change, not just because you and the programmer change their minds or some things just can't be implemented, the customer will change his mind too at the most annoying moments. Someone here is a fan of Agile development, huh? :) (me too)

At the same time though it is important to try and enforce a time where the design is locked down. The development of features can run and run if you give people licence to constantly change things. Most of the time this can be achieved by making people aware of the total cost of changes (this isn't just coding time).

Quote:

Original post by Dasha Maybe I am thinking ahead of myself. But what do you have to make sure to include into your design to make the work of a programmer easier? I know numbers and things like item attributes, damage ratios, etc.

It's not just 'numbers', it's about ranges and typical usages. Can the numbers be negative? How far positive can they go - what's the maximum score for a stat? What about with various contextual modifiers - can they push the stat further? If so, how far? How many types of monster/weapon/terrain/skill/spell will there be in the game? How many is a typical player going to see? What's the most a player could see at any one time?

Representation is important too. (Some of this strays into artist territory though.) How do you want something presented to the player? A quick mockup is very helpful but not enough. Do you want invalid buttons to be disabled or removed entirely? If the text is too long to fit in the label, should it be abbreviated or should it wrap, maybe with a scrollbar? Does the cursor change when you move the mouse over something, in which case, to what? Do you have an exhaustive list of such cursors? Is there a consistent GUI style you need? If so, describe that independently of individual panel descriptions so that the necessary components can be done first. What typefaces are you using? What camera angle are you using, and is there a requirement to be able to change it?

Processes are important - if the player goes through a process where they have to make choices, then you absolutely must think about what happens for each choice. Otherwise what happens is that the programmer will develop the critical path the way you want it but you'll find that the alternatives do something that seems wrong. eg. You have a drag and drop inventory. Don't just specify what happens when a player drags an item to or from it successfully - specify what happens when they drag something in that doesn't fit, when they drag something to the wrong place, when they drag something out of the game window entirely, when they try to drag something that is not allowed to be picked up or moved, etc.

Quote:

Also, how does one schedule when estimating the creation time for the project as to not overwork your programmers(less time means less quality), but not end up taking an excessive amount of years(more time means more money). Should I consult a programmer before finishing up the document(so I have an idea of what things I can and can not do within time)? or wait until I am completely finished with the design document and then ask(so I may end up having to edit my design and taking out features or shaving off of some).

Finish a rough top-level document. Consult a programmer to get an estimate of times for each feature. Add more detail to the document, bearing in mind the time estimates. Rinse and repeat a couple of times. Unless you're a programmer or an experience designer then unfortunately you won't have a good idea of which parts of the design are most important to the programmer in scheduling terms. Once you and the programmer(s) are agreed on the design and the timescales then there should be no changing of it without going through this same consultation process. Stuff will change, but it's inexcusable for you to keep making creeping changes to the design that moves the goalposts for the programmers.

Finally, you should write your document so that features can be labelled with priorities (eg. as mandatory, important, or optional). The idea there is that programmers can start dropping the lower priority tasks if time is short. Virtually no game will go out of the door with everything on the wish-list intact. The designer's job is to distinguish between core gameplay features and elements of polish that ultimately can be discarded if necessary.

Read this: How To Write Great Design Documents (Powerpoint slides).

Quote:

Original post by Dave Quote: Original post by Tebriel Quote: Original post by ernow (Most of my experience comes from building business apps but I think they can be treated the same mostly in this case and others will correct me) I do not believe in sharing the design only when it has been finished for a couple of reasons: 1. How do you know whether you're done or not? 2. The last 20% of detailing takes too much time and is definitely not what the programmer needs to get started. 3. Expect the design to change, not just because you and the programmer change their minds or some things just can't be implemented, the customer will change his mind too at the most annoying moments. Someone here is a fan of Agile development, huh? :) (me too) At the same time though it is important to try and enforce a time where the design is locked down. The development of features can run and run if you give people licence to constantly change things. Most of the time this can be achieved by making people aware of the total cost of changes (this isn't just coding time).

I admit I like being agile but unfortunately many people understand agile as 'everything can change'. Well, I don't like that. I timebox all the time and when the architecture has been set, I do not accept big changes unless provided with enough time or other resource to counter the changes. You see, and that is my actual point, changes cost money. So whenever something changes you have to find funds for it. Good planning tries to foresee some changes and set some funds aside for them but when a major change comes up you need to count the pennies and ask for more.