gamedevlists-general

[GD-General] Architecture Design

[Parveen K. <pk...@sf...>]

Just a little bit of a survey.  After the gameplay and story of a game has 
been somewhat fleshed out, what kind of techniques do you guys use to 
design the code?  I'm assuming everyone uses diagrams such as ORDs, ERDs, 
and DFDs or some variant.  Is this true?  How detailed do you guys get?

Does anyone get hardcore and actually use UML and tools like Rational 
Rose?  Are there people out there who have worked on both game projects and 
common desktop applications?  How did the design techniques differ, if at all?

Parveen

[GD-General] Architecture Design

[George W. <ge...@ap...>]

on 10/8/01 5:28 AM, gam...@li... at
gam...@li... wrote:
> Just a little bit of a survey.  After the gameplay and story of a game has
> been somewhat fleshed out, what kind of techniques do you guys use to
> design the code?  I'm assuming everyone uses diagrams such as ORDs, ERDs,
> and DFDs or some variant.  Is this true?  How detailed do you guys get?
> 
> Does anyone get hardcore and actually use UML and tools like Rational
> Rose?  Are there people out there who have worked on both game projects and
> common desktop applications?  How did the design techniques differ, if at all?


LOL! ;-)


More times than not the core code is written as a "proof-of-concept" by the
design engineers and the engineers hired to "ship-it" just add code as
necessary to meet the final requirements. Very rairly have I seen any design
tools used to really "top-down" design from the get-go. This is on projects
ranging from 5 to 300 engineers.

OTOH, I have used several RAD tools to GUI => code quickly, one-off
"proof-of-concept" projects that later got used by the teams as a base to
add code to. One of my favorites was the Gooey editor & code generator
written by George R. Cossey. The Gooey editor was template based so if you
didn't like how his code worked you could edit his templates more to your
liking. I'd love to have this updated for CarbonEvents but I haven't heard
about updates or anything since it was updated for CodeWarrior 11 back in
'97. :(

There are still a few of these "framework generators" around. Probably one
of the most popular is AppMaker. Web crawl for more info. ;-)

Just remembered that this list isn't necessarily Macintosh. So just to show
that my opinion isn't Mac biased prior to coming to Apple I spent about 15
years on main frames and the experience was about the same. The designers
threw together a proof-of-concept that the developers would then be stuck
with adding code to for the additional features that the customer wanted.
;-)

-- 
Enjoy,
George Warner
Mixed Mode Magic Fragment Scientist
Apple Developer Technical Support (DTS)

Re: [GD-General] Architecture Design

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

Phew - I was beginning to think our studio was living in the stoneage - we
as it would seem do a lot of others do just cobble stuff together as we go
along, designing the component we're currently working enough so it works
and is tailored for its purpose.
I suspect a completely revision-proof design isn't possible within the games
industry. If I write a donkey simulator the chances are one of the artists
will come along a week later and ask me for a dancing donkey simulator. Now
designing a dancing donkey simulator in the first place wouldn't be even
close to efficient as the final game might never have needed it.
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.

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?

As a little anecdote.
About the same time as C++ became more commonplace (maybe 6 years ago) about
half the people I worked with went off and re-wrote stuff that had taken
them a couple of months to write the first time into very conceptually clean
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 on a voyage
of language discovery but I've personally always looked back on the
experience as the need for design winning out over the need for progress.
(PS. This is not a C against C++ tale - I am a perfectly competant C++
programmer)

It'll be interesting to see where this debate goes when the Americans get on
board;)


David Hunt

----- Original Message -----
From: "Parveen Kaler" <pk...@sf...>
To: <gam...@li...>
Sent: Sunday, October 07, 2001 11:09 PM
Subject: [GD-General] Architecture Design


> Just a little bit of a survey.  After the gameplay and story of a game has
> been somewhat fleshed out, what kind of techniques do you guys use to
> design the code?  I'm assuming everyone uses diagrams such as ORDs, ERDs,
> and DFDs or some variant.  Is this true?  How detailed do you guys get?
>
> Does anyone get hardcore and actually use UML and tools like Rational
> Rose?  Are there people out there who have worked on both game projects
and
> common desktop applications?  How did the design techniques differ, if at
all?
>
> Parveen
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Architecture Design

[Chris C. <cca...@io...>]

> It'll be interesting to see where this debate goes when the Americans get on
> board;)

:)

For the last project I worked on, we were pretty hardcore -- UML, CRC cards,
and we were trying to incorporate Refactoring and some of the XP philosophies
into our workflow.  Unfortunately, the company went under before we could 
really see if it paid off.  Take that for what you will. :)

Personally, I'm more of a fan of (1) doing some rough UML-esque diagramming
to see how internal components fit together and how external clients will 
access the system, (2) getting the relevant programmers together to hash 
out the general design and make sure everyone's on the same page, and (3)
get going writing clean code that we can adapt as we better understand the
requirements (or as the requirements change).

More than a couple days of design work on any one "section" of code is
overkill, IMO.  Though large systems can have hierarchies of sections,
so that the physics system as a whole can be a section, the collision
representation can be a section, player control can be a section, etc.

One thing I did want to point out from earlier in the thread is that I 
think that *game* design documents (as opposed to *code* design docs)
are very useful to have fleshed out early in the project.  I agree that
huge sections will be axed by the "reality police" (read: programmers),
but they can be invaluable for doing requirements analysis of game
systems.

-Chris

RE: [GD-General] Architecture Design

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

> More than a couple days of design work on any one "section" of code is
> overkill, IMO.

Agreed.

> One thing I did want to point out from earlier in the thread is that I
> think that *game* design documents (as opposed to *code* design docs)
> are very useful to have fleshed out early in the project.  I agree that
> huge sections will be axed by the "reality police" (read: programmers),
> but they can be invaluable for doing requirements analysis of game
> systems.

Does anyone else find it interesting that so many people are in favour in
documenting a game design to help communication, make sure everyone is
working towards the same goal and to show up possible technical problems but
very few people advocate technical documentation to help communication, make
sure everyone is working towards the same goal and to show up possible
technical problems?

Philip Harris

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

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

RE: [GD-General] Architecture Design

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

> 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.

The idea is to remove that sort of thing during the design process so you
didn't need to code it in the first place. That happens a lot once you get
into the habit of thinking things through.

> I think with experience writing stuff off the top of your head is nearly
the same as
> working from a design,

But writing stuff off the top of your head got you an over engineered
design... :)

Philip Harris

Re: [GD-General] Architecture Design

[Thatcher U. <tu...@tu...>]

On Mon, 8 Oct 2001, David Hunt wrote:

> 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.

You mean, like Michelangelo?  :)  (Isn't he the one who described his
process that way?)

Back on topic, the bad pitfall I've seen in detailed top-down engine
designs, is when you break things down into sensible pieces with sensible
interfaces, and some of the boxes implicitly contain things like "robust
rigid and soft body physics solver", "automatic all-purpose 3rd person
cinematic camera", "human-like real-time learning neural net AI".

Elegant designs have been fractured by much more technically tractable
problems than those, as well, such as details of the artist toolchain,
rendering chip peculiarties, wacky bullet-point marketing requirement, or
what have you.

-Thatcher

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
>
>