gamedevlists-general — List for discussing general game development issues

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

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

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

[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

[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

Re: [GD-General] Publishers

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

> > Nice name. =)
> >
> > This is pretty difficult. There's some luck involved. We were very lucky
> to
> > meet our current publisher by merely coincidence. Also could you please
> > define a 'small game'?
> >
> > Erwin
>  I mean a game that usually sells for $10-$25... I'm sure Epic Megagames
> wouldn't be interested... :)

I'd say small publishers, and reasonably big ones could be interested in
your kickass game. The only problem is that some are really arrogant. I
havent negotiated with publishers myself (i'm just the tech guy), but i've
been involved pretty closely. I'm sure there are some guys that can help you
better. See below. I dont know if this is still working, but the new address
is Gam...@Mi....

GameDesign mailing list
Gam...@in...
Official Website http://gamedesign.incagold.com
http://www.incagoldusa.com/mailman/listinfo/gamedesign

Erwin

Re: [GD-General] Publishers (forwarded for Jeremy Gaffney)

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

Hi,  this got sent to me instead of the list because of the changes at =
Sourceforge (see Tom Hubina's post) so I've forwarded it. Its actually =
from:

From: "Jeremy Gaffney" <jga...@nc...>

One good group of folks to talk to are the guys over at GarageGames =
(www.garagegames.com) - they specialize in such things, usually using =
their own engine (which was the Tribes 2 engine).  If they can't help =
you directly, they probably know the other players well.

For subscription-based online games, NCSoft is =
funding/distributing/publishing third parties; if you're online, feel =
free to email me if you'd like as well, though we tend to be focused =
more on larger games.

-jg
  -----Original Message-----
  From: Death Hunter [mailto:dea...@ga...]
  Sent: Tuesday, October 02, 2001 3:19 PM
  To: gam...@li...
  Subject: [GD-General] Publishers


  Hello!

      This is not directly connected to the game development... however, =
when you make a game, you need to sell it, right? It's not a problem if =
you're big company, but what if you're just a small team of developers? =
I've been looking on google, but couldn't actually find a small game =
publisher. Where do you find a publisher for a small game? Any links?
  Thanks,
  DHunter

[GD-General] List Reply Issues

[Tom H. <to...@3d...>]

OK, I've gotten some information back from SourceForge. The change was part 
of a recent global policy change. We were not consulted before it happened, 
it was just made for us because they feel this is the way lists should be 
run. Needless to say I don't agree with them.

I've gotten the email address of the person we'll need to talk to in order 
to get this changed (all I want it the ability to specify it on a per-list 
basis .. which is what we used to have) but he is on vacation for the rest 
of the week. Unfortunately, I'll be gone on my honeymoon next week so I 
won't be able to talk to him until around the 16th. I'm gonna drop the guy 
an email now and leave him contact information for Brian. We'll take this 
one step at a time, but hopefully we'll get things changed back to normal soon.

Tom

RE: [GD-General] Publishers

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

One good group of folks to talk to are the guys over at GarageGames (
www.garagegames.com) - they specialize in such things, usually using
their own engine (which was the Tribes 2 engine).  If they can't help
you directly, they probably know the other players well.
=20
For subscription-based online games, NCSoft is
funding/distributing/publishing third parties; if you're online, feel
free to email me if you'd like as well, though we tend to be focused
more on larger games.
=20
-jg

-----Original Message-----
From: Death Hunter [mailto:dea...@ga...]
Sent: Tuesday, October 02, 2001 3:19 PM
To: gam...@li...
Subject: [GD-General] Publishers


Hello!
=20
    This is not directly connected to the game development... however,
when you make a game, you need to sell it, right? It's not a problem if
you're big company, but what if you're just a small team of developers?
I've been looking on google, but couldn't actually find a small game
publisher. Where do you find a publisher for a small game? Any links?
Thanks,
DHunter

Re: [GD-General] Publishers

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

Hey - good name,

If you're small enough and money isn't so important I'd personally start =
pushing it through the public domain and try and build a following - =
nothing a publisher likes more than an existing user base. We've picked =
up games like this before. It also cuts out the middle men <RANT ON> see =
Develop magazine (http://www.developmag.com/) from July - the cover read =
"He doesn't make games, play games or even like games...(and he can't =
make money either). So what is your publisher doing in the games =
business?. <RANT OFF> Doesn't apply to our publisher I should point =
out:-)
If your team is bigger try going straight to the publishers, our =
company's development is a set of satellite teams that found funding =
through the parent - we've also even bought game designs from people =
(one of whom is now working in my team) and had them developed in house =
(bit of a Nirvana that one though).
Try Gamasutra for publisher addresses and send stuff straight to them - =
unless they're gigantic they'll probably take you seriously.


David Hunt=20

----- Original Message -----=20
  From: Death Hunter=20
  To: gam...@li...=20
  Sent: Tuesday, October 02, 2001 9:18 PM
  Subject: [GD-General] Publishers


  Hello!

      This is not directly connected to the game development... however, =
when you make a game, you need to sell it, right? It's not a problem if =
you're big company, but what if you're just a small team of developers? =
I've been looking on google, but couldn't actually find a small game =
publisher. Where do you find a publisher for a small game? Any links?
  Thanks,
  DHunter

[GD-General] Publishers

[Death H. <dea...@ga...>]

Hello!

    This is not directly connected to the game development... however, =
when you make a game, you need to sell it, right? It's not a problem if =
you're big company, but what if you're just a small team of developers? =
I've been looking on google, but couldn't actually find a small game =
publisher. Where do you find a publisher for a small game? Any links?
Thanks,
DHunter