If you had to create a workflow to manage your development process what steps/stages would you implement? Would you keep it small or make it as detailed as possible?

It seems to me that I need a process that starts with a user wish list and ends with a build in production.

Here are buckets I'm planing on using per feature

1. Register

2. Initial Requirements

3. Review ( Approve / Reject)

4. Detailed Requirements.

5. Approved for Development (enters the development backlog)

6. Development

7. Unit Testing

8. User / Play Testing (reject / approve)

9. Build & Release

Mine is very cyclic, incremental:

while not done:
    think_of_a_nice_next_feature();
    try:
        consider_feasibility();
        consider_implementation();
        refactor_for_implementation();
        add_new_feature();
    except FeasibilityError:
        add_learned_lesson_to_knowledge();
end

Mine is very cyclic, incremental:

while not done:
    think_of_a_nice_next_feature();
    try:
        consider_feasibility();
        consider_implementation();
        refactor_for_implementation();
        add_new_feature();
    except FeasibilityError:
        add_learned_lesson_to_knowledge();
end

Those are some very critical and important steps that are often overlooked.

string code;
while (null != (code = ReadCode()))
{
    Cry();
}

If you had to create a workflow to manage your development process what steps/stages would you implement? Would you keep it small or make it as detailed as possible?

It seems to me that I need a process that starts with a user wish list and ends with a build in production.

Here are buckets I'm planing on using per feature

1. Register
2. Initial Requirements
3. Review ( Approve / Reject)
4. Detailed Requirements.
5. Approved for Development (enters the development backlog)
6. Development
7. Unit Testing
8. User / Play Testing (reject / approve)
9. Build & Release

Having a vision for your game and a small amount of planning is definitely beneficial. You don't want to dive into a game project that is too large in scope and you want to have a rough idea of what you final game will be like but this waterfall approach has a major flaw. You cannot anticipate everything you game needs or even if it will be fun in the planning stages. If you lay out a detailed map of what your final game will be like you will find major problems with the gameplay partway through development. At this point you can scrap all the work you did in planning or just stick to the script and have your gameplay suffer because of it.

Alberth describes pretty well what I try to do. Build the game in small incremental steps. Try out the gameplay early with simple prototypes. Be willing to kill an idea that will either take more resources than it is worth or just isn't fun. Identify problems with gameplay and come up with solutions as you find them. Eventually you begin to converge on your final game, which may be quite different from your original idea.

I think that if the above waterfall method is used per feature it won't have such a flaw. I agree you can't anticipate everything.

• Initial design.
• Concept fleshed out
• Concept art / sketch / photos from the internetz
• Designs reviewed with modeling, animation, programming, audio, effects, QA, to ensure it fits budgets
• Designs reviewed with production and marketing to see how they fit longer-term plans
• Very simple prototypes built (time boxed to a few hours of work)
• Iterate (back to #2, sometimes many times)
• Initial approval, meeting with full team where we try to poke additional holes into the design. Far better to discover these flaws now rather than later.
• Slightly bigger prototypes. Basic box models and rigs created. Empty animation trees created. Everyone does a small amount of work to identify all the risks and the full details of what we are adding, and to identify the limits and what we are not adding. These take place over a week or so.
• Design approved, meeting with full team as the final design is presented and everyone presents their prototypes and concepts. Everyone should be comfortable with the design.
• Modeling usually starts first, a few days earlier than the other teams.
• Programming and animation enter main development, roughly 1-2 weeks for main development. Usually we show off each bit of functionality to designers and others as they walk past. Some minor iteration can happen if necessary.
• QA joins after the first week, more or less.
• Implementation review, we demo to the full team and give a final opportunity for changes
• Audio gets busy when animation nearing completion
• Text sent to localization
• Final process, lots of QA, lots of tests against various configurations
• Object packaged, prepped for marketing and deployment, and eventually deployed to store