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