gamedevlists-general

RE: [GD-General] Architecture Design

[Jamie F. <ja...@qu...>]

People design code? :)

Sorry, in my experience, there's some division of tasks (someone writes
renderer, physics, whatever), then it gets glued together. Very little
design work....

Jamie

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Parveen Kaler
Sent: 07 October 2001 23:10
To: gam...@li...
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

[Jamie F. <ja...@qu...>]

Maybe the leads should have an idea of how everything works. Haven't seen it
happen. Depending on what you mean by 'how everything works' :)

Code has to be discussed, yes. Communication is obviously vital.

I do think design should work, and should help. Just haven't experienced
it....

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Tom Nuydens
Sent: 08 October 2001 12:39
To: gam...@li...
Subject: RE: [GD-General] Architecture Design


Hi,

Even if you split up the work and just piece things together later on, I
think at least _some_ design work is necessary. At the very least,
shouldn't the project lead have an overview of how everything works?

We don't get excessively formal about the design process either, but we
do use UML class diagrams as a means of communication. I find the
diagrams to be very helpful when trying to explain ideas to other team
members (or the other way around). You _do_ occasionally discuss your
code with your fellow team members, don't you?

- Tom



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On
> Behalf Of Erwin de Vries
> Sent: Monday, October 08, 2001 12:50
> To: gam...@li...
> Subject: Re: [GD-General] Architecture Design
>
>
> I've never heard of this as well. I know the drill, but its
> simply not worth it in most cases. For some cases it might
> be, but generally there is no need for formal diagrams in
> those cases. (IMO)
>
> Erwin
>
> (ARGH! Damn reply issues!)
>
> ----- Original Message -----
> From: "Jamie Fowlston" <ja...@qu...>
> To: <gam...@li...>
> Sent: Monday, October 08, 2001 12:14
> Subject: RE: [GD-General] Architecture Design
>
>
> > People design code? :)
> >
> > Sorry, in my experience, there's some division of tasks (someone
> > writes renderer, physics, whatever), then it gets glued
> together. Very
> > little design work....
> >
> > Jamie
> >
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On
> Behalf Of
> > Parveen Kaler
> > Sent: 07 October 2001 23:10
> > To: gam...@li...
> > 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
> >
> >
> > _______________________________________________
> > 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
>


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Architecture Design

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

I appear to be in the minority so far but I do design code up front. I do=
n=92t
use any of the formal methods you mentioned but I have gotten =91hardcore=
=92 in
the past and done UML design for one subsystem, to see how it worked out.=
 In
my opinion the tools aren=92t really good enough yet but the principle is
good.

When we=92re approaching a new system we discuss the problem with anyone =
on
the programming team that=92s interested and come up with a preferred
solution, using UML for producing diagrams on the trusty whiteboard. Thes=
e
solutions are usually the combination of everyone=92s good ideas rather t=
han a
selection of good and bad ones from one person.

Whoever is implementing the system then documents the approach we=92re ta=
king.
This often includes documenting the actual classes although usually only =
the
public functions (as we=92re using C++). This documentation stage is
essential, it always throws up issues with the design and is the best tim=
e
to refine it. This also has the side effect of producing documents for
newcomers to look at and get up to speed and everyone on the team has at
least some idea of how all the systems work.

In my experience this approach is always quicker than just sitting down a=
nd
writing the code. Not to mention the fact the code will be more robust an=
d
need a lot less changes. In the past the code which causes problems has b=
een
that which was put together without being designed first. Invariably the
code is then revised and expanded as the project=92s needs are really
understood.

I could go on for a long time about this but in my opinion anyone who doe=
sn=92
t do at least some design work on code is very unwise. It=92s not easy to=
 get
right, you can very easily over design but with a bit of practice the
benefits are immense.

Philip Harris
BatFish Studios Ltd

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Jamie Fowlston
> Sent: 08 October 2001 12:52
> To: gam...@li...
> Subject: RE: [GD-General] Architecture Design
>
>
> Maybe the leads should have an idea of how everything works.
> Haven't seen it
> happen. Depending on what you mean by 'how everything works' :)
>
> Code has to be discussed, yes. Communication is obviously vital.
>
> I do think design should work, and should help. Just haven't experience=
d
> it....
>
> Jamie
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Tom Nuydens
> Sent: 08 October 2001 12:39
> To: gam...@li...
> Subject: RE: [GD-General] Architecture Design
>
>
> Hi,
>
> Even if you split up the work and just piece things together later on, =
I
> think at least _some_ design work is necessary. At the very least,
> shouldn't the project lead have an overview of how everything works?
>
> We don't get excessively formal about the design process either, but we
> do use UML class diagrams as a means of communication. I find the
> diagrams to be very helpful when trying to explain ideas to other team
> members (or the other way around). You _do_ occasionally discuss your
> code with your fellow team members, don't you?
>
> - Tom
>
>
>
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...] On
> > Behalf Of Erwin de Vries
> > Sent: Monday, October 08, 2001 12:50
> > To: gam...@li...
> > Subject: Re: [GD-General] Architecture Design
> >
> >
> > I've never heard of this as well. I know the drill, but its
> > simply not worth it in most cases. For some cases it might
> > be, but generally there is no need for formal diagrams in
> > those cases. (IMO)
> >
> > Erwin
> >
> > (ARGH! Damn reply issues!)
> >
> > ----- Original Message -----
> > From: "Jamie Fowlston" <ja...@qu...>
> > To: <gam...@li...>
> > Sent: Monday, October 08, 2001 12:14
> > Subject: RE: [GD-General] Architecture Design
> >
> >
> > > People design code? :)
> > >
> > > Sorry, in my experience, there's some division of tasks (someone
> > > writes renderer, physics, whatever), then it gets glued
> > together. Very
> > > little design work....
> > >
> > > Jamie
> > >
> > > -----Original Message-----
> > > From: gam...@li...
> > > [mailto:gam...@li...]On
> > Behalf Of
> > > Parveen Kaler
> > > Sent: 07 October 2001 23:10
> > > To: gam...@li...
> > > 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
> > >
> > >
> > > _______________________________________________
> > > 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
> >
>
>
> _______________________________________________
> 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
>

RE: [GD-General] Architecture Design

[Warrick B. <War...@po...>]

There always seems to have been two factions in the programming world: those
who understand intimately what they are doing and can write almost what they
want off the mark, and those who need to sit down and think about it a lot
longer before they can write even a comment.

I'm currently suffering in a situation caused by the former and at my last
job suffered from the latter (And ones before that suffered from people not
having a clue ;).  It seems no one has ever managed to find the happy medium
for any project - it's either over designed or no design.  It's particularly
interesting when the two factions meet in heated debate as one side sees the
other as idiots because they can't visualise code in their head and the
other side sees imbeciles who obviously can't write software.

I admit that I verge on the under designed side of things - partly because I
know things will have to be changed with respect to any initial design -
especially when a team of people is involved.  Ideally I'd love to have
design documents that would be used as guidelines rather than bibles.
Currently I tend to have one none formal overview of the 'current'
architecture with a summary of how it's intended to work that's always handy
for meetings - other documentation and design will generally be produced
anyway by people as it is needed for their own benefit or as recognised by
the team (These notes can later be consolidated into 'official'
documentation).  It's all too easy for some people to spend all their time
'designing' rather than writing code!

Of course when a projects finished it's definitely worth documenting more
thoroughly (Generally during the final testing phases) in case you ever want
to reuse(!) your project!

Wow that was longer than intended!  I'm just glad no one got me started on
hungarian notation and people who comment every line of code....

My 2 pennies worth anyway ;)

Warrick.


-----Original Message-----
From: Erwin de Vries [mailto:er...@vo...]
Sent: 08 October 2001 11:50
To: gam...@li...
Subject: Re: [GD-General] Architecture Design


I've never heard of this as well. I know the drill, but its simply not worth
it in most cases. For some cases it might be, but generally there is no need
for formal diagrams in those cases. (IMO)

Erwin

(ARGH! Damn reply issues!)

----- Original Message -----
From: "Jamie Fowlston" <ja...@qu...>
To: <gam...@li...>
Sent: Monday, October 08, 2001 12:14
Subject: RE: [GD-General] Architecture Design


> People design code? :)
>
> Sorry, in my experience, there's some division of tasks (someone writes
> renderer, physics, whatever), then it gets glued together. Very little
> design work....
>
> Jamie
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Parveen Kaler
> Sent: 07 October 2001 23:10
> To: gam...@li...
> 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
>
>
> _______________________________________________
> 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

RE: [GD-General] Architecture Design

[Tom F. <to...@mu...>]

Hmmm.... these words - "design technique" - what do they mean? :-)

I hate to break this to you, but generally we just open up a text editor and
start coding.

Obviously we do design stuff. And we redesign stuff that was a cheap hack
into decent solid systems. But so far I have never seen anyone ever document
anything in a game except script languages - and that's just because we let
outsiders write scripts. And the docs were _docs_ and written after the code
was, not _specs_ and written before.

We just find that games change so fast that any design is instantly out of
date by the time you write to code. You find the code needs to do something
different, needs to be adapted, needs to be quicker/cheaper, or needs to be
better and more robust. "Code rot" is a huge poblem anyway - adding the
"design" process would just make it even slower. And no, design wouldn't
help the code rot - these are _games_, not spreadsheets. At least 50% of
that is just coding something to see if it works and plays well.

IIRC, for StarTopia we had five different AI navigation systems (whittled
down to one), six different cameras (of which we only finally used three,
and two of those in very specific circumstances), several different method
of building/laying out things, loads of different UI panels and so on. We
_did_ have game design documents, but so much stuff that looks good on paper
ends up being wrong when put in a game. We will still do gameplay design
though, simply because it makes sure we're all signing from the same
songsheet. But we all know it will change massively through the project.

In these debates, there seem to be three sorts of people:

-People who have coded actual games.
-People who listen to people who have coded games.
-People who believe in design documents for games.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Parveen Kaler [mailto:pk...@sf...]
> Sent: 07 October 2001 23:10
> To: gam...@li...
> 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

RE: [GD-General] Architecture Design

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

> In these debates, there seem to be three sorts of people:
>
> -People who have coded actual games.
> -People who listen to people who have coded games.
> -People who believe in design documents for games.

You'd have to add a fourth to cover me...

-People who have coded actual games and as a result believe in design
documents.

And I'm not alone, although maybe on this list :)

Philip Harris

RE: [GD-General] Architecture Design

[Jeremy G. <jga...@nc...>]

We use both use-case analysis (UML) and XP methodologies, as odd a combo
as that
sounds.  Both work well in different situations - UML works especially
well
with C++ coding, since the barrier to change after you code is high,
even=20
with refactoring techniques - for instance, headers, constructors all
must be
rewritten, etc.  Extreme Programmming is great with easier-to-code
languages=20
like Python, since the cost of change is much smaller.  In all cases,
however,=20
some beforehand design saves a lot of future changes, and some ability
to be=20
flexible when the spec changes is quite useful too.

-jg


> -----Original Message-----
> From: Tom Nuydens [mailto:t.n...@vr...]
> Sent: Monday, October 08, 2001 6:39 AM
> To: gam...@li...
> Subject: RE: [GD-General] Architecture Design
>=20
>=20
> Hi,
>=20
> Even if you split up the work and just piece things together=20
> later on, I
> think at least _some_ design work is necessary. At the very least,
> shouldn't the project lead have an overview of how everything works?
>=20
> We don't get excessively formal about the design process=20
> either, but we
> do use UML class diagrams as a means of communication. I find the
> diagrams to be very helpful when trying to explain ideas to other team
> members (or the other way around). You _do_ occasionally discuss your
> code with your fellow team members, don't you?
>=20
> - Tom
>=20
>=20

Re: [GD-General] Architecture Design

[Evil K. <evi...@ho...>]

fly by the seat of your pants is something I'm used to !

I try to design stuff logically, I think about what I would need to get a
base working, then I extend it to support stuff I want, say 3d, or 2d, then
I just add more and more until I have the system I want, it's evolutionary
design and it usually gives the best designs, it's the same technique the
russians used in designing their rockets in the race to the moon, it takes
longer to implement something than a clear cut, on paper design, but the
designs are usually (depending on the design team) better...

think about it this way, the russians were 20 years ahead of the americans
at designing rocket boosters, but their designs took longer to implement, so
whilst the americans went to the moon, the russians didnt, that was in
1970s, in the 1990 americans were entering russia and hearing about MK33
rockets and how amazing they were, by now a 20 year old design, guess what?
they outperformed american technology of the 1990's, even with the americans
improving their designs over the last 20 years and are now the base of many
rockets that were designed after their discovery by the americans :)

so, evolutionary design, if you can afford more time and dont mind flying by
the seat of your pants, this is what I would suggest

kosh

RE: [GD-General] Architecture Design

[neo b. <ne...@mw...>]

I divide it up into macro and micro design.

Macro design is the overall interaction of everything.

We will have 3D, we will have physics, we will have arguments ;>

Then I go off and code tons of test apps which implement/test ideas, etc
and give me an idea of what it is exactly I'm dealing with. Once I've hacked
it do death, played with it and broken it, I have a much clearer
understanding
of what it involves. Then it becomes a 'design' with specific interfaces and
capabilities, and I know sorta how to keep it open enough.

That's basically the middle way which brings together my inherent urge for
purity and simplicity stewed with real world ingredients.

And of course this is recursive.

Hack in slash in the backyard, then clean it up for inside the house...

layder
neo


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Evil Kosh
Sent: 08 October 2001 07:48
To: GameDev General ML
Subject: Re: [GD-General] Architecture Design


fly by the seat of your pants is something I'm used to !

I try to design stuff logically, I think about what I would need to get a
base working, then I extend it to support stuff I want, say 3d, or 2d, then
I just add more and more until I have the system I want, it's evolutionary
design and it usually gives the best designs, it's the same technique the
russians used in designing their rockets in the race to the moon, it takes
longer to implement something than a clear cut, on paper design, but the
designs are usually (depending on the design team) better...

think about it this way, the russians were 20 years ahead of the americans
at designing rocket boosters, but their designs took longer to implement, so
whilst the americans went to the moon, the russians didnt, that was in
1970s, in the 1990 americans were entering russia and hearing about MK33
rockets and how amazing they were, by now a 20 year old design, guess what?
they outperformed american technology of the 1990's, even with the americans
improving their designs over the last 20 years and are now the base of many
rockets that were designed after their discovery by the americans :)

so, evolutionary design, if you can afford more time and dont mind flying by
the seat of your pants, this is what I would suggest

kosh


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Architecture Design

[Brooks B. <br...@on...>]

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

In the Smithsonian there is a "cartoon" done by Michelangelo (I 
think...maybe it was Rafael?).  Cartoons are design sketches done by the 
artist prior to beginning an actual painting.  The sketch is worked over 
heavily - things are erased and moved around until the artist is happy 
with the final design.  The cartoon is very messy.

At that point the artist punches holes all along the outlines of the 
cartoon.  They then attach the cartoon to the final media (wall for a 
mural, canvas for a painting) and throw charcoal dust on it.   The 
charcoal goes through the holes and leaves a connect-the-dot framework 
that the artist then paints on.

Sooooo....  there is some level of framework design in paintings of the 
masters.  I was really suprised - I just thought they were so good they 
just winged it.  (Also, since the cartoons were destroyed usually, they 
are incredibly valuable today).

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

I call this the fractal code coastline problem.   You can keep breaking 
things down. But you can't see the total detail until you have broken it 
down to the atomic level of code.  

The worst thing about design work is that it is tempting (for management) 
to look at all those boxes and assign times to them to arrive at a final 
schedule.   But you can't tell how long the boxes take unless you break 
them all the way down to code again.  So you miss the fractal multiplier 
that should be applied. 

>think about it this way, the russians were 20 years ahead of the americans
>at designing rocket boosters, but their designs took longer to implement, so
>whilst the americans went to the moon, the russians didnt

One of the more interesting aspects of the American effort is that Von 
Braun and company skipped the detailed QA cycle.  They were so confident 
in their design, and time was so short, that they simply test fired the 
final completed Saturn rocket.  It worked. This saved a tremendous amount 
of time.  Had the rocket failed it would have been a huge setback.  

The Russian designs did not work out of the gate.  So in a way the speed 
of the US program is probably more a result of careful conservative 
design than of aggresive forward thinking design.  

Re: [GD-General] Architecture Design

[Erwin de V. <er...@vo...>]

I've never heard of this as well. I know the drill, but its simply not worth
it in most cases. For some cases it might be, but generally there is no need
for formal diagrams in those cases. (IMO)

Erwin

(ARGH! Damn reply issues!)

----- Original Message -----
From: "Jamie Fowlston" <ja...@qu...>
To: <gam...@li...>
Sent: Monday, October 08, 2001 12:14
Subject: RE: [GD-General] Architecture Design


> People design code? :)
>
> Sorry, in my experience, there's some division of tasks (someone writes
> renderer, physics, whatever), then it gets glued together. Very little
> design work....
>
> Jamie
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Parveen Kaler
> Sent: 07 October 2001 23:10
> To: gam...@li...
> 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
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>
>

RE: [GD-General] Architecture Design

[Tom N. <t.n...@vr...>]

Hi,

Even if you split up the work and just piece things together later on, I
think at least _some_ design work is necessary. At the very least,
shouldn't the project lead have an overview of how everything works?

We don't get excessively formal about the design process either, but we
do use UML class diagrams as a means of communication. I find the
diagrams to be very helpful when trying to explain ideas to other team
members (or the other way around). You _do_ occasionally discuss your
code with your fellow team members, don't you?

- Tom



> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Erwin de Vries
> Sent: Monday, October 08, 2001 12:50
> To: gam...@li...
> Subject: Re: [GD-General] Architecture Design
> 
> 
> I've never heard of this as well. I know the drill, but its 
> simply not worth it in most cases. For some cases it might 
> be, but generally there is no need for formal diagrams in 
> those cases. (IMO)
> 
> Erwin
> 
> (ARGH! Damn reply issues!)
> 
> ----- Original Message -----
> From: "Jamie Fowlston" <ja...@qu...>
> To: <gam...@li...>
> Sent: Monday, October 08, 2001 12:14
> Subject: RE: [GD-General] Architecture Design
> 
> 
> > People design code? :)
> >
> > Sorry, in my experience, there's some division of tasks (someone 
> > writes renderer, physics, whatever), then it gets glued 
> together. Very 
> > little design work....
> >
> > Jamie
> >
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On 
> Behalf Of 
> > Parveen Kaler
> > Sent: 07 October 2001 23:10
> > To: gam...@li...
> > 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
> >
> >
> > _______________________________________________
> > 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
>