__________________Game Development Flow_____________________
Based on this, I created a Game Development roadmap for DeVry University to help students understand where they were in the whole game development process. It's nothing more than a combination of documentation, project management, and software design but presented in a way I at least have not seen. While the above is for a Waterfall approach, it is easy to modify it for iterative and sprial development models as well.

Thanks for this try to visualize the processes!

My concern is this "all ideas at once" before even starting to prototype etc. (Let's put it in words from an engineer's perspective: to realize an invention it is not possible to have all solutions in advance to integrate it in existing technic!)

What way do you go, if you are trying to develop something essentially new?

Or, think of your "Think big, start small" - Don't ya have to start small with the documentation, too?

I can't find the prototyping (cycles) in your picture while prototyping is essential within game production.

I think, one has to start with a conceptual minimal list and than cycle through the green part of your picture, while expanding it step by step, depending on the results of the process, and depending on the steps of the financing of the project).

EDIT:

An interesting thing to integrate in such a scheme is the learning curve of oneself and the collaborateurs, a most ignored factor in the discussions about development.

Given the market, hardware and software are permanently changing, one has to react to these changes, inform about them, control decisions, change decisions, learn new tools, decide wether change the tools etc.

Given this is a community of continuesly new starters with developing, it is a developing while getting into the functionallity of the tools etc.

Quote:

---

My concern is this "all ideas at once" before even starting to prototype etc.

---

You are on target. The document presents it like a Waterfall (do 1 before 2, 2 before 3, etc). I did this because Waterfall is the easiest process to understand and put into action even if it is in fact the least effective at development. But I also did it because I think I've found a minimal set from which we can build up any development cycle. I've long had this idea that while nobody in their right mind would use Waterfall in a professional environment, the building blocks of waterfall are actually present in EVERY software process.

Quote:

---

I can't find the prototyping (cycles) in your picture while prototyping is essential within game production. I think, one has to start with a conceptual minimal list and than cycle through the green part of your picture, while expanding it step by step, depending on the results of the process, and depending on the steps of the financing of the project).

---

And I think you are right! You see while I present it as Waterfall, the real significance of the diagram is that you can repeat any step and apply as much or a little time to each step. What you are suggesting is more like Iterative developmet and is infinitely better than Waterfall. And here is where the document becomes useful: in it's ability to adapt and project (hopefully) all software development cycles

Consider the prototype style of development (famously used by Will Wright): it is an iteratie but minimal application of the three steps... first document the prototype to the best of your abilities... then plan on making it within the time and resources you have (you may have to change the scope of the prototype to work within budget and time). Finally create the prototype (which is an Alpha) and document the results (Quality list). NOW repreat! Keep doing this until your Alpha is starting to look like a Deta. Keep doing the process on the Beta (document, plan, implement to beta) until the Beta looks like Gold.

Quote:

---

An interesting thing to integrate in such a scheme is the learning curve of oneself and the collaborateurs, a most ignored factor in the discussions about development.

---

Hmmmm... meta-learning (learning how we learn) is really hard to document. Do you have any suggestions as to how we can do this?
Not only is each persons learning curve different but I know of no way to "quantize" it. What I do in class is simply go through each of the blocks and do it... this is the only way I can think of saying "we have covered/learned this... we haven't covered/learned that". Hence if your adopted style is waterfall, you may say "We have completed 10 of the 22 deliverables" or if it's iterative you can say "We have copleted 10 of the 22 deliverables for cycle 1". This is more record keeping and not meta-learning.

Quote:

---

it is easy to modify it for iterative and spiral development models

---

Reading your answer and looking at your scheme again, I ask you: Is it easy, actually? At least, not in 2D...

A sort of 3D scheme comes to my my mind, on the lowest level a cycle of small boxes(lists and documents), above that a cycle of bigger boxes with parts of the smaller boxes in it etc.

Reworking the Flow through the document is all the is needed, hence my "simple" comment:

SPIRAL MODEL
http://en.wikipedia.org/wiki/Spiral_model




ITERATIVE MODEL
http://en.wikipedia.org/wiki/Iterative_development




Spiral doesn't redo requirements while Iterative does.

Could you show what you have in mind; I'm curious!

I've seen lot fo professionnal games doing iterations
Graphics was every time improved.

In fact they prototyped quickly a plyabale game with in progress graphics.

Another thing we could insits a lot is :
2D concept art and 2D level concept.

It's the main essence of a game , if you don't have precise idea of the models you want , textures, architecture and levels, style of game , precise
gameplay etc ...
you won't go very far

I think no need to modelise, texture etc ... before a fisrt big shot
of 2D art (documentation/storyline/game mechanics/progression).

Quote:

---

It's the main essence of a game , if you don't have precise idea of the models you want , textures, architecture and levels, style of game , precise
gameplay etc ...
you won't go very far

---

I don't agree. While an Art Bible is needed during production for consistancy, I don't see the essense of a game changing whether you know that your textures will be 512 squared vs. 256 squared... it changes the Quality of the game, but not it's essense. And I also don't see the game as being IN the Art Bible anymore than it's in the Narrative Design or the Sound Effects list. The essense of the game is not in any one asset but rather in the interplay between all assets.

But then again I'm biased: I've never felt that graphics make the game. Like Doom 3 proved, good graphics do not a good game make and like Darwinia proved, poor graphics do not a bad game break!

Quote:

---

I've seen lot fo professionnal games doing iterations
Graphics was every time improved.

In fact they prototyped quickly a plyabale game with in progress graphics.

---

I've never heard of a design team iterating for the sake of the graphics. Iterative design is more to help make sure your code does what it's meant to do and is fun. Since this is something you can't get right the first time, you iterate. Graphics just aren't an area that is needed to iterate at all. I can't imagine that the skin tone of a creature or the number of limbs will be significantly modified during the production process. But the actual dynamic interaction between creature and hero; that can change and thus the need to prototype and iterate. The graphics pipeline is just too well understood for specific iteration in this field to do much good.

You have given me an idea though and that is to separate out the Art Bible from the Game Design Document. It may be usefull to present it this way so that when you iterate, you have more options and a clearer view of what will and will not change.

Quote:

---

I think no need to modelise, texture etc ... before a fisrt big shot
of 2D art (documentation/storyline/game mechanics/progression

---

Here we agree. Proper up front design, whether waterfalled or iterative, is a key to success... much like having a road map is the key to getting where you want successfully.

I've been using Test Driven Development for my latest project and, honestly, I've never had more fun writing code.

Write a test. Run and fail. Write some code to make that test pass. Then check to see if you can improve things. Write the next test...

Each test tends to be really small but they add up quickly. Normally I can write a test and the code to make it pass in less than a minute. And if my "fix" breaks something, all the other tests catch it.

A company would be quite quick out of business if
it would have to rely on full iterations, and
really have to do the concept list again... without gaining cashflows inbetween

Doug: I've heard a lot of good things about test driven a lot recently. Sounds like a type of "prototype iteration" to me. The key is to define the right test then, right? Good test will lead to good code; bad test will lead to bad code, yes/no?

Damocles: I'd say there are many more games that went under because they did NOT revamp the original concept. Consider that the concept that you thought would be fun just isn't... do you forge ahead and build an ENTIRE game around a flawed concept or do you change the concept? The answer really depends on whether you are indie or mainstream: indie is more likely to do the latter; mainstream the former. This is because each shop has a different Inertia and can change easier. Hence you will see more "Waterfall" like development in Big Game Houses where you can't change midstream since it would mean 10's or 100's of peoplehours wasted but in a Small House you can since it's only 10 or 20 people intimitely working (and they would be the ones that find the change anyways!)