Re: [GD-General] Architecture Design

[Drew, A. <ri...@ho...>]

I seem to come from a slightly different perspective.

I'm currently in the process of writing my first game with a group of
friends. I've seen other groups attempt this task and fail and in the cases
I have seen it has always failed due to lack of good communication.

We have spent a great deal of time ensuring that each member of our group
has a clear understanding of the task we're trying to undertake. This has
been done at all levels, from high-level conceptual and gameplay levels down
to subsystem and even class interaction diagrams (primarily written
informally in UML). This information represents the core of our game, both
conceptually and technically and while it may change as time goes on, we
can't afford to loose focus of it.

There are, and will continue to be, holes in our design up until the time
we've finished implementing everything. We are still learning a great deal
and running into snags that I'm sure nearly all of you have hit before. But
I see the design documentation we have as an integral ingredient in our
success.

This might not be exactly the case for those with prior experience in this
field. I can understand how someone could go out and code an entire
rendering system without any formal documentation if:
    a. They have done it before; or
    b. They have had prior experience with similar systems before.
Technical subsystems such as these can be largely defined through feature
sets and other specs that don't need excessive documentation.

Please fire back at will. I enjoy different perspectives on topics such as
this.

Regards,
Aaron

----- Original Message -----
From: "David Hunt" <da...@hu...>
To: <gam...@li...>
Sent: Tuesday, October 09, 2001 3:56 AM
Subject: Re: [GD-General] Architecture Design


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