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.


FUTUR-E-SCAPE: The Future Landscape of Education and Entertainment.