RE: [GD-General] Problem Breakdown

[Johnson, J. <Jam...@si...>]

One technique we use is what's called a sticky note meeting. Basically
it's a meeting of engineers (though may included other interested
parties) with the goal of breaking down features into high-level tasks.
Its called a sticky note meeting because we jot down the tasks on sticky
notes and paste them to a large wall. The process is informal, everyone
is encouraged to contribute, all ideas are recorded regardless of how
brilliant or dumb they may seem. The result of this meeting should be a
fairly good representation of the tasks and task boundaries required for
a feature. It will most likely not be complete, but should be good
enough such that a single engineer can fill in the remaining details
with some investigation.

Sticky note meetings work well when the group of engineers participating
understand the problem domain. They are also a good means of
distributing knowledge within an organization. If your organization has
multiple teams then chances are you've got more than 1 AI 'expert' to
help you break down the problem. If your organization is small then you
might be surprised how many engineers have dabbled in AI. These
engineers may give insight to your problem.=0D

Sticky note meetings are not meant to replace the low-level design. You
say "Rational Rose stuff" and UML are too high-level, but neither of
these assumes a levelness. UML is perfectly suitable to designing "Hello
World", a linked list, or a resource manager; just like a nuke is good
at killing things of all sizes, these tools work for all problem sizes.=0D

Sticky note meetings are not helpful when the problem is not well
understood. For this I prefer standard research tools, e.g. books,
prototypes, and examination similar pre-existing solutions (chances are
someone somewhere has already solved your problem). If a problem can
easily be prototyped I'll always do a prototype (or 2 or 3) to develop a
better understanding of the problem and potential solutions. The result
of prototyping often allows me to create a design that can encapsulate a
number of potential solutions should I run into some unforeseen
circumstance later in development. Its important for me to emphasize
that last sentence because that is how I manage risk in my own
development process.

No one looks at all the ways to solve a problem.

In summary:

1) high level task analysis done via group effort sticky note meeting. A
basic feature document must be pre-existing with a prioritized feature
set on a scale of 1-4 (1 won't ship without, 2 very important, 3 would
be nice, 4 can live without).
2) mid and low level task analysis done by a single engineer (research,
prototypes, pre-existing solutions). Result is the design, a design
worthy of being estimated and implemented
3) estimation
4) group review and sanity check
5) schedule created including milestones




James


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Brett Bibby
Sent: Monday, July 12, 2004 8:44 PM
To: Gam...@li...
Subject: [GD-General] Problem Breakdown

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.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
self defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557



----------------------------------------------------
Vivendi Universal Games- <<http://www.vugames.com>>:=0D
The information transmitted is intended only for the=0D
person or entity to which it is addressed and may=0D
contain confidential and/or privileged material of=0D
Vivendi Universal Games which is for the exclusive=0D
use of the individual designated above as the=0D
recipient. Any review, retransmission, dissemination=0D
or other use of, or taking of any action in reliance=0D
upon, this information by persons or entities other=0D
than the intended recipient is prohibited. If you=0D
received this in error, please contact immediately=0D
the sender by returning e-mail and delete the=0D
material from any computer. If you are not the=0D
specified recipient, you are hereby notified that=0D
all disclosure, reproduction, distribution or action
taken on the basis of this message is prohibited.