Re: Bag of Tricks: Choosing actions via the matching law

baylor wrote:

> On Mon, 03 Nov 2003, Eternal Vigilance <[EMAIL PROTECTED]> wrote:
> > >  Assumptions: Options are relatively equal
> > How many games these days have no additional modifiers that effect the
> > success/failure  (ie-whether is underwater,  or if char has his 'Hat
>
> Dear Nordic God,
>
> You are of course correct. All actions are context-sensitive. When
> shooting a basketball, two options are to go for the two-point or
> three-point shot. Other options include eating a sandwich (acceptable
> at lunch), taking off your clothes (acceptable when showering) and
> throwing up (acceptable when "partying"). But we don't and the player
> don't consider those options because they are not appropriate within
> the current context
>
> Something i want to stress and something i picked up over the last 4
> years of doing AI stuff - AI in academia traditionally focuses on a
> single one-size-fits-all general purpose algorithm that does
> everything. Be it rule-based expert systems or "neural" nets or
> genetic algorithms or Bayesian networks, it's all about a single
> technique used in a single straight forward way. Some decently good
> work has been done on hybrid systems, but not enough of it in my
> opinion and the work that was done is rarely if ever presented in AI
> text books or classrooms
>
> There is probably no parallel to AI's approach in the real world. When
> building a house, there are screws, nails, staples, glue and hexagonal
> sockets. Electrical, plumbing and framing are all handled with
> different tools and different techniques. Your brain is the same way.
> The eye has separate modules to find color, lines and depth. There's
> an object recognition module for faces and a separate one for
> everything else. You have more than a dozen different memory centers -
> working, procedural, short term, general declarative, self-referential
> declarative, exemplar situational, situational, emotional situational,
> etc. Lots and lots and LOTS of little specialized parts, just like in
> your car, computer, operating system, company, etc.
>
> The technique described here, the matching law, is like a nail or a
> hammer. It's good for certain, specific situations, situations that
> are common but hardly in the majority. If we were building a lego
> person, the matching law would be single lego. You'll need a whole lot
> of other stuff to make a human-like NPC
>
> i tried to come up with a short, easy to understand format/template
> that told all the important information up front. My buddy Darrin says
> it looks like the format used to describe design patterns. i listed it
> as a medium-level detail - not as low as information culling via
> habituation and not as high as goal-directed behavior. Under
> assumptions i listed that there needed to be a limited set of actions,
> all of which are of relatively equal value
>
> So what could i have done better? Under assumptions, i could have
> listed that the context needs to have already been determined and that
> the actions are relatively equal under the given situation. Or perhaps
> better, i could have shown a hierarchy of cognition and where this
> fits into it. Of course, then i'd have to actually know where it fits,
> and obviously i don't :)
>
> i'm not sure if i mentioned it originally, but when tracking the
> success and failure of a given action, it needs to be done in a given
> context. Shooting two-pointers in a game is easy because that's the
> only state/context they're ever in (well, OK, they need to be in the
> holdingBall state). In an FPS, the important context is a combination
> of spatial considerations (enemy is in a small room, far away, etc.)
> and whether you have friends there (or have friendly fire turned off).
> i made zippo detail on how to determine your current context. So
> either the designer has to hard code this or it can be keyed to the
> current state (i'm assuming the game has a state machine or two). Or
> even better, somebody else can write a trick for the bag of tricks so
> i don't have to do it :)
>
> If i ever stop being so damn busy and/or lazy, i'll add a form on my
> Web site so people can type in their little tips and tricks. That way
> you guys can do all the work and i'll like take all the credit ;-)
>
> -b

I looked at it and thought -- thats a good way to utilize a prepared
set of  'best' options  based on a simple set of numeric metrics
with a self correcting mechanism implied.  Having it deliver a non-linear
response that actually matches realworld thinking patterns as well...

Its easiest use would be in a scripted logic situation -- games where
the designer defines the options , but then gives the program some
ability to adapt their use.  We'll be stuck with games like that for
quite some time yet....

It can also be used as a core function (like you say - a 'screw') in a much
larger
(ugly) framework which will deliver appropriate options to plug into it.   I
still worry
how many boxes of screws we will need to get that entire framework to work
though.

Im still trying to come up with a way of evaluating  'effectiveness' of an
action
and reducing it to a single linear value (alot of context and relative
valuation of
cost/ payoff/ risk)  that could be plugged into a function.  Filtering the
situation
isnt the only complication...

BTW several of the game AI books talk about having a  'quick' default
solution being
available for when the more complex AI doesnt return in time.  Since your
algorythm
takes very little CPU and offers a reasonably flexible response, it can
still be used to
provide acceptable solution when the HAL9000's is still churning away when
the next
frame has to be drawn.