RE: [GD-General] Architecture Design

[Philip H. <ph...@me...>]

> As far as code re-use goes - who really honestly ever gets to the end of a
> project with an engine clean enough that they want to re-use it in its
> entirety - little bits maybe but not a whole engine.

Perhaps if it was designed up front... :)

> Just out of interest Philip when you said "Invariably the code is then
> revised and expanded as the project's needs are really understood." - does
> large scale formal design mitigate this at all? Do you find that a proper
> formal design makes things revision-proof?

No I don't think it does make things revision-*proof*, you can't do that.
Your Donkey example is a change in the requirements and no matter how good
the design it's still possible to change the requirements sufficiently to
break it. However, I have found that by designing code up front you get code
which survives changes in requirements much better than code just hacked
together and even if things change a lot you can reuse much larger portions
of systems in the new project.

The main benefit though is that you refine the ideas in the design without
spending time coding it up and testing it. The understanding process takes
place before coding rather than during. I've found that three things
regularly happen when a design is documented:

	1) You realise that everyone had a slightly different view of the design.

	2) You find some holes, something that seemed like a good idea but once
it's written down it doesn't seem so good or just isn't required.

	3) You see a much cleaner way of organising things.

Chances are you would have seen them as you coded your original idea but by
then of course you've already written all that code :(

The argument that games change too quickly to do design just doesn't hold
any water as far as I'm concerned, a well designed piece of code will
survive changes far better than something written off the top of your head.

I'd certainly not call what we do formal though, UML is only used as a
standardised notation so that everyone understands the squiggles on the
board. Designing the networking system for the RTS I worked on took a couple
of days. A few hours discussing it, an afternoon writing up a description of
the system plus another day circulating the doc and revising it. More
importantly, it worked but only because we threw out the design we'd all be
assuming we were going to use. When we were discussing the design it became
obvious that it wasn't going to work so we changed it. Had I gone away and
coded the initial design I'd have wasted a lot of time finding out it wasn't
good enough.

Two points.

Firstly, I'm not claiming it's a silver bullet. You still have to throw
systems away sometimes because the game has changed too much but the time
'lost' to design is paid back many many times in the systems that don't have
to be thrown away and that work more reliably and can accomodate changes in
the requirements.

Secondly, you still have to be a good programmer, just designing the code
doesn't work, you have to create a good design. A key factor in this is
knowing when to stop, it's very easy to carried away designing a no holds
barred all singing all dancing system when it isn't what you need. It's a
classic schoolboy error.

> As a little anecdote.
> C++ versions  - except this time it took them 6 months. Most of them moved
> out of the games industry soon after that. Now perhaps they were

I would have thought that says more about their abilities as C++ programmers
than anything about design in general. :)

Philip Harris