gamedevlists-general

[GD-General] Problem Breakdown

[Brett B. <res...@ga...>]

I've noticed that with the increased complexity next-generation games that
my old ways of breaking down gameplay features and turning that into a
technical design seem to be lacking, or at least far more difficult than it
used to be.  When searching, most of the results are perhaps too low-level
in recommending various C++ "patterns", general OOP principles, etc. or too
high-level like Rational Rose stuff, UML use-case diagrams etc.

My question is, given a problem (or feature to be implemented) what
methodolgies or techniques have proven useful to break down the problem and
detemine how to technically solve it?

The best example I have at the moment is implementing the AI for our current
game.  The are so many ways to look at the problem: I could break it down
into state machines, messaging, use-case, etc.  But each one while excelling
at some portion of the solution, also has a number of problems.  Also, it
involves an awful lot of people with different skill sets: who will do the
level AI markup? Path generation? Behavior specification? Rules? Animation
control? AI debugging method? Scripting integration?

So you have a problem that slices across the company in terms of
departments/pipeline (horizontal), and also one is multi-layered (vertical)
in terms of features like goal determination, planning, path-finding,
steering, animation state, etc. that could be split up by members within a
team.

Is it common to look at _all_ ways to solve a complicated problem before
determining a solution?  Or do most people just pick a solution that gets
them going and refactor later? Or?

Thanks.

Re: [GD-General] Problem Breakdown

[Kent Q. <ken...@co...>]

At 11:43 PM 7/12/2004, Brett Bibby wrote:
>I've noticed that with the increased complexity next-generation games that
>my old ways of breaking down gameplay features and turning that into a
>technical design seem to be lacking, or at least far more difficult than it
>used to be.



>My question is, given a problem (or feature to be implemented) what
>methodolgies or techniques have proven useful to break down the problem and
>detemine how to technically solve it?


>Is it common to look at _all_ ways to solve a complicated problem before
>determining a solution?  Or do most people just pick a solution that gets
>them going and refactor later? Or?

I consider myself a pretty good "big systems" guy. I worry about the 
architecture at the macro scale, and try to hire people who are better than 
I am at getting the details right.

I'm a huge fan of Implement, Refactor, Refine. I think there's so much 
learning that goes on during the course of a project. Not just learning new 
techniques or the way you're doing scripting, but learning about what 
really matters in your gameplay, and deciding that you can get a lot of 
mileage from a new UI paradigm you just invented. Consequently, I think 
it's counterproductive to try to sit down and design out a whole product in 
advance. You're cutting off huge swaths of what you might be able to learn.

The eXtreme Programming folks are fond of the acronym "YAGNI" -- you ain't 
gonna need it. Their concept is that you implement The Simplest Thing That 
Could Possibly Work and then improve it only if you need to. I don't go 
quite that far. A good dose of experience and/or common sense should help 
you figure out a reasonable guess as to how much is likely to be enough. 
Why build the wrong data structure if you know it'll be wrong?

The key, though, is understanding when you've underimplemented and taking 
the time to FIX it, not just patch it. That's a strategy that's hard for 
some managers to take. "What did you do today?" "I deleted 300 lines from 
the codebase and left it doing the exact same job!" "So you're saying 
you're wasting time?"

In fact, this whole strategy also sort of depends on my ability to convince 
people that the project is under control. Or being the one in charge in the 
first place.

So...do I look at all ways of solving a complicated problem? Well...I would 
say I probably consider MANY ways of solving a complicated problem, but 
most of them are rejected quite early. Sometimes I'll do experiments to 
test feasibility.

Another phrase that applies, though, is "The best is the enemy of the 
good." Far better to have a suboptimal solution that ships than an optimal 
one in the lab. Unless, of course, the suboptimal one hurts the product.

One of the reasons I like the game industry is that you have to get it 
*all* to beyond "good enough". You can't create a functional tool with a 
bad UI that people buy anyway because there's nothing better. It's 
entertainment. They only buy it if they like it, so you'd better make sure 
they like it.

In the end, it's all about managing risk. You spend your design time on the 
areas that are highest risk, and take shortcuts on areas where you know or 
can guess the right answer. And then polish, polish, polish.

         Kent








----
Kent Quirk
CTO, CogniToy

Re: [GD-General] Problem Breakdown

[Mike <mi...@ge...>]

> At 11:43 PM 7/12/2004, Brett Bibby wrote:
>> Is it common to look at _all_ ways to solve a complicated problem before
>> determining a solution?  Or do most people just pick a solution that gets
>> them going and refactor later? Or?

my 2 bits on the topic, i'm starting the process of doing a 'version 2' 
of our game engine, and have been going through these same types of 
questions myself.

i don't think you can necessarily think of ALL of the ways to implement 
a particular system or attack a particular problem, and even if you 
could, you run dangerously close to the 'research' side of software 
development, and research is necessarily open-ended, and does not fit 
nicely into releaseable software and game schedules.

you do need to consider reusability, if the engine in particular is 
being designed to last multiple projects (which i would assume most 
engines are these days).  This is probably becoming more of an issue as 
we move forward, since the time to rewrite an entire technology tree 
from the ground up is becoming so much more involved.

with our engine, every feature that is added to the engine must be 
considered from the aspect of reuseability - if it's something that 
changes the basic player movement system, then make it so that we can 
disable it just as easily.  it doesn't take much extra effort to provide 
this kind of customizability up-front, but from the sheer number of 
options that you provide the designer, documentation becomes a major 
issue (which we are constantly battling).

however, the engine in question is specifically a multi-genre game 
creation 'system' more than an engine for a specific game tailored from 
ground up for only that one game.

refactoring is inevitable we've found over the years of assembling the 
engine.  often a feature appears first as a simple entity with a few 
options to manipulate, and then if it evolves further, may get moved 
into the scripting api or config files, usually to make it easier for 
the designer to edit & reuse throughout a game.

from the programmers perspective, you will never think of all the 
possible ways that the designers are going to try and use the features 
that you give to them - they will undoubtedly come up with new and crazy 
ways to combine different elements in ways that you would never have 
thought up.  in situations like these, refactoring may well be required. 
  it's not a bad thing, but make sure that the changes you are making 
help expand the reusability of the engine, not reduce it.

-- 
Mike Wuetherick
Gekido Design Group Inc
www.gekidodesigns.com