RE: Problem Breakdown

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.

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.

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: [email protected]
[mailto:[email protected]] On Behalf Of
Brett Bibby
Sent: Monday, July 12, 2004 8:44 PM
To: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557



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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7