[gameprogrammer] Re: Design resources

> On Thu, 2004-06-10 at 01:09, Dominic McDonnell wrote:
> > Thanks, I'll look into making design docs.
> > I looked at UML, but it doesn't fit my purposes. I don't think that
> > learning a new language is necessary, english does fine.
> > I was wondering what other techniques for planning programs were used.
> > Dominic McDonnell

One company I worked at had the problem of designing the implementation
details of their new game.  They wanted to make a modular, reusable design.
So they wrote a messaging system that was shared by modules and by the
scripts.  When you wanted to perform an action in the game, such as having a
character walk to X, you would encode a message (almost like a network
packet) and send that to the manager.  The manager would then route the
message over to the designated system (such as the player).

However, once the game became more complex than what they saw from the high
level view on paper the system became too inflexible and hard to use.  As a
result, we had to write design workarounds.  Formerly independent 'modules'
started to use pointers to other modules to bypass the messaging system.
Messages would be hacked and send directly to another system rather than
through the manager.  And so on.  Taken together, the design became
increasingly complex and difficult to use - especially as each programmer
wrote their own work-arounds that nobody else knew about.  Six months, the
programmers that wrote the system stated to me "Well the system isn't that
good - we shouldn't have wrote it.  But it's too ingrained to take out now"

The lesson to be learned here is that the human mind can't comprehend the
scope of an entire project from conception.  Trying to guess at what you
might need usually only results in the scenario I just presented - you are
stuck with an old system that you hold onto longer than you should have
because you don't want to admit you wasted all that time.

I learned from their mistakes - as well as mistakes I made myself writing
various games.  I put these lessons on my personal website (www.rakkar.org).
Two that I think apply to the start of a new project are

1. It takes a lot longer to recode than it does rethink a problem so time
spent thinking about a problem is far more productive than time spent coding
a problem. However, planning for future design possibilities that you don't
understand usually only results in a bloated design that doesn't fit the
problem. The best approach is to think through a problem as much as you
reasonably can and code that exact solution.

4. Refactor your code as soon as you fully understand a problem that you
didn't properly account for. Putting off refactoring encourages further
sloppy design and is more difficult to do when you no longer fully remember
or understand the solution.



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: