It's ramble time!

Hmm. The complete design process is very long (at least, if you do it the "proper" way for general software). Here's a doc I wrote a while ago for someone else (some bits may be missing because it was done from memory): http://www.alistairkeys.co.uk/design_process.htm.

If you follow the design process carefully, it's possible to get very good results. In particular, the requirements spec, the candidate class list, the class diagram and the state transition diagram can result in some pretty unexpected, but good, design decisions.

Of course, it takes a lot of discipline to see through the "proper" way. I've had a couple of good results so far (for a Monopoly game written in VC++ 6/MFC --spit spit spit!, and for a 3d game in Java3D).

I'm of the opinion just now, though, that a lot of the stages are reasonably generic and can be re-used through different projects. Many of the candidate class list items were pretty repeatable for various projects (e.g. "screen", "image", "file", "input", and so on, crop up all the time). I think that it's probably possible to create a reasonably generic framework, and to use that through most projects. If you use the state design pattern then a lot of the state transition diagram becomes generic - you'll end up with roughly the same flow through your system game-to-game (e.g. intro->main-menu branching off to demo, high score table, story, options, etc).

In other words, at the moment I'm doing bottom-up "design" (writing any code that comes to mind as handy :roll and slowly forming it into a generic game framework. This is pretty satisfying, although it's definitely not the most productive thing in the world. Nonetheless... sometimes you need to do the monkey work to appreciate the design stages .

I heard some good advice a few days ago somewhere: aim to do a very small game that will take you a week. You'll probably get it finished in a few months, but you *will* end up finishing it. I'm not sure how long Traveller's balloon popping game took, but look at what's happening now: he has a product at the end, and has been getting a lot of feedback. This seems like a good approach -- it's much simper to embelish a simple game from user feedback than to fit it all in at the start. Once it gets too large and messy, just finish it and start on version 2.0 .

I've tried the proper design stages before and had a couple of reasonably good results. Now, it's time to convert *everything* and see what pops out at the end! In defence of this, it is a recognised design pattern .

However, using the proper design process does *not necessarily* guarantee a proper solution. For my Honours project (the Java3D crap) I did some design, then piled in to the coding (since I neglected it for all but the last two weeks of the allowed time . I put in over 48 hours without sleep in the last few days). I retrospectively wrote up some of the UML, "hacking" the candidate class to get the desired classes popping out the other side for the class diagram (and stripping out approximately 19 pages worth of functional requirements from the rqeuirements spec). It turns out that my initial thoughts on the system were pretty much a good fit with the "design process recommended" stuff - I had an idea of the wanted design, implemented it, and when I went back, I found no major surprises from doing it the proper way. This argues for or against doing the design process; I do keep in mind that my other project (a team project doing Monopoly) resulted in some "interesting" design decisions that would almost certainly not have been made, and I do think that it helped.

I remain utterly unconvinced about the worth of Use Cases, though. They're handy for acceptance testing, but as a part of the process by themselves... they simply lack any relevance whatsoever, IMHO.

The big question in my mind: does the design process produce good results in and of itself? I think that it doesn't really; I think that it's simply a product of having a formalised system that lets many people look on a set of ideas. It provides a system that can focus a team's attention, and I think that it's simply the prolonged discussion that is the major benefit. Hmm.

About your game BojZ: I tried to download it but there was a server error. I'll try some time later on.