Newsgroups: comp.ai.games
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!newsfeed.pitt.edu!gatech!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!fnnews.fnal.gov!gw2.att.com!nntpa!not-for-mail
From: nak@gwe486.cb.att.com ()
Subject: Re: Message to All AI programmers
Message-ID: <D67w00.BEA@nntpa.cb.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: gwe486.cb.att.com
Organization: AT&T GBCS/Bell Labs
References: <3k2pj7$gib@ccshst05.cs.uoguelph.ca> <3kcbe7$f0f@uuneo.neosoft.com> <D5v1DL.EpJ@nntpa.cb.att.com> <dwalker-2403951228200001@sam-ppp-l1.neosoft.com>
Date: Wed, 29 Mar 1995 19:40:48 GMT
Lines: 131

In article <dwalker-2403951228200001@sam-ppp-l1.neosoft.com>,
Doug Walker <dwalker@atomic.com> wrote:
>In article <D5v1DL.EpJ@nntpa.cb.att.com>, nak@gwe486.cb.att.com () wrote:
>
>> In article <3kcbe7$f0f@uuneo.neosoft.com>,
>> Doug Walker <dwalker@panzer.atomic.com> wrote:

[major snip, we are talking AI for games] 

Quoting: >> is me.  > is Doug.

>But for a complex game, such as the W@W games that I work on, a
>"well-programmed AI, would take severazl hours (if not several days) to
>calculate even a truly sub-optimal set of moves.  It's not that it CAN'T
>be done, just that it's infeasable in a realistic sense.

I beg to differ.  Unfortunately, I can't offer "proof by counter example"
but instead will put forth some arguments to be considered.

>> What I think most folks here find is that the average AI has real trouble
>> against the average player.  This I agree with.  Many people also despise
>> when the machine cheats.  I'm not fond of that either.
>
>based on your statements below, we are talking apples and oranges.

The specifics do differ.  The techniques I used to write the AI for auto
ARE directly transferable to a higher level.  The difficulty is in
synthesis and analysis.  

>> I wrote a tank-like multi-player game roughly comparable to Star Fleet
>> Battles (the game) suffers head on collision with Red Storm Rising (the
>> book).  In addition to the human-commanded ground and air units, I wrote an
>> AI for computer run ground units.
>
>well, see, this is a SMALL game, with a very limited number of similar units.

At first blush this is a reasonable (and expected) concern to raise.  It is
not small in terms of game space.  But you don't manage a regiment the way
you manage a squad.  You don't even try.  You don't write the AI using the
same criteria.  

I would write it the same WAY, using DIFFERENT criteria.

>In the W@W Operation Crusader campaign game, for instance, the  map is 200
>x 200 hexes, and there are upwards of 400 units per side.  And, typically,
>each unit is a bit different from any other unit.  A unit can undergo
>changes as well, as it takes losses.
>
>So, I guess what I am saying is:  In theory, I agree that a really good AI
>for a large complex game is possible, but in practice, given the current
>state of the art, no, it isnt possible.

I strongly disagree with your last paragraph here.  I'd like to restate it
as, "It may not be practical for a commercial game writer to write a really
good AI because it takes far longer than the time needed to write an
ordinary one."  I don't know enough about the market to say how many more
sales or how much longer the product's life span would be if it had great
AI.



I suggest "Enemy Mine" from last year's CGDC Proceedings.  I can't remember
the author off hand, but the document has a lot of good stuff in it.  It
was about AI and in particular it was about multi-level AI.  I want to
expand on that some.  My own 1991 paper was posted here recently.

The game I wrote for was tactical, small unit combat.  It had a wealth of
details and did is text-based best to "put you in the turret."  It was
designed and optimized for that level of play.  One player per tank.  

IF, and it's a big if, a large scale game, such as one that does say
Operation Barbosa, uses a level of detail that is found in Squad Leader,
then you will get great low level realism, but it will play at best in real
time - five years for a complete WWII game :-)  (God what a terrible
sentence that is, sorry.)

BUT:  Most campaign games DO NOT use such a high level of detail.  And hexes
makes your terrain far, far more tractable than arbitrary realspace.  I've
worked with 100x100 hex maps, 200 x 200 is doable.

The questions come down to:  What level of detail is tracked per unit?  How
many options does each unit have?  I suggest that the total amount of
detail *is* manageable.  I am relatively sure of this for a heuristic
reason:  The game needs a certain level of detail to provide a rich
experience.  Not enough is too simplified:  "Roll one die, if the result is
5 or 6 Barbosa works.  On 1-4 it fails."  Too much is a drag:  "Please input
the order for private Fritz.  (59,999 more to go) Please input the orders
for private Hans. (59,998 more to go)..."  

So, if the game is fun, I claim the level of detail is, in total, 
manageable.  Coming up with clever ways to manage is a pain.

I'd design the AI in stages.  Mimic the command structure of your army - it
will tend to give you realistic behaviors.  Do the bottom first.  I've done
a "tank manager" and doing it gave me the skills needed to write a "platoon
manager".  I was halfway there when I stopped work on it.  Be sure to note
when optimizations for a given level will run counter to the goals of the
higher level.  Use the analyze, synthesize, test loop (see my paper).

Once you have the units operating in something that slightly resembles an
effective manner, add in the hooks for the next higher level control.  Test
and tune the multi-level structure until the top level seems to be getting
its job done (or trying hard).  Add another level and turn the crank.

The problems I had with the method are:

    I can't get better behaviors out of my AI than my test group exhibits
themselves.  I use what they do as inspiration.  The more analytical
everyone in the play-test group is, the better it works.

    I can't do it rapidly.  The intense play-test that is required to shake
the bugs out of the behaviors (and one or two that might crop up in the
code) takes real-time.   Sometimes changes were a week or a month apart.  We
tested everyday at lunch provided I wasn't changing the code.  Often I'd
need an AHA! experience to come up with a way to quantify the right things
to allow me to write code to implement behavior changes.

Luckily:

    I got behaviors that used the best of what skilled people did.  I had a
play-test group that had a wonderful variety of types of players. Autos
ate novices for lunch.

   The process is regenerative.  Each time you analyze and synthesize, you
are becoming more skilled at translating behaviors to values in variables.
Little fixes make it possible to see how to do big fixes.

---
Neil Kirby	DoD# 0783	nak@babel.cb.att.com
AT&T Bell Labs  Columbus OH     USA (614) 860-5304
President Internet BMW Riders
