Re: [GD-General] Architecture Design

[David H. <da...@hu...>]

Good answers and I do have an open mind about all this and I suspect we do
under-design sometimes, however even at our current level of design I find
myself removing over-engineered bits that nobody uses months later. Eg. Our
scriptables all intercommunicate through message passing. All messages go
through a messaging hub that routes them. When I initially wrote the hub I
allowed for many hubs to be connected together the idea being that certain
script classes would naturally use Hub A and others would use Hub b - thus
all characters on the same hub get faster communication. However 6 months
later nobody used this feature so I took the technology out as it obfuscated
the design and we now have a single monolithic hub.
I suspect we're actually probably in the same ballpark in reality - your
methodology is a bit more formal than I prefer - I think with experience
writing stuff off the top of your head is nearly the same as working from a
design, given that complex tasks need discussion with other team members
regardless of design strategy and all tasks are ultimately derived from the
game design document.
I'm not totally convinced by your point about documentation exposing flaws
in the design - I think the worst design flaws are the ones that nobody
however carefully they've worked through it would have discovered until they
got down to coding it. But thats just my opinion.


David

I think at its worst lack of design is like the sculptor who sculpts by
chipping off all the bits that don't look like a head - hopefully none of us
do this.

> > 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
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general