Newsgroups: comp.ai.games
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsfeed.cit.cornell.edu!newsstand.cit.cornell.edu!news.kei.com!wang!news
From: bruck@actcom.co.il (Uri Bruck)
Subject: Re: Cheating by AI in games
Reply-To: bruck@actcom.co.il
Organization: ACTCOM - Internet Services in Israel
Date: Thu, 9 Nov 1995 23:25:37 GMT
Message-ID: <DHsuJA.M3u@actcom.co.il>
References: <446muf$i0c@nyx.cs.du.edu> <448rul$asd@ixnews4.ix.netcom.com> <tgooding-2609951122550001@helser196.res.iastate.edu> <44bhsu$r2m@ixnews7.ix.netcom.com> <tgooding-2809950021420001@helser196.res.iastate.edu>  <DG3qDw.9q1@actcom.co.il> <458qk8$8un@ <46ta84$iq0@ixnews7.ix.netcom.com> <hNIGRUV.predictor@delphi.com> <35009.9775462963@localhost>
Sender: news@wang.com
Lines: 72

sshah@intranet.on.ca (Sunir Shah) wrote:


>Here's another suggestion that could be pretty darned slow, but offers a
>method of controlling each unit in a semi-fast way..

>Have different levels of control (hierachy).  Have the general up at top
>making strategic decisions.  Then, break up the army into divisions and
>have colonels implementing that strategy in a more refined sense.  Break
>the divisions up into platoons.  The platoon leaders would refine their
>orders even more.  Finally, the individual unit will have pretty
>specific orders and just have to follow them blindly.

>In conjunction with this top-down approach, there's also the bottom-up.
>Each level will relay information about its situation back up a level.
>Each level leader will generallize that information and send it back up
>until the general knows what's going on and then can decide on what to
>do.

>You'd run the unit actions every frame, the platoon leader every few
>frames (over the period of a a few frames), the division leader even
>broader and finally the general will take the longest to come up with
>decision (spread out over the most frames).

>Voila...

>BTW, I'm not going to take credit for that one.  I found an archived
>post from this ng on x2ftp that outlined that.  I forget who wrote it
>and I've lost the article since then.  At any rate, I thought it was an
>interesting approach.

I rather like that one, have been playing around that with this. And
may have written a post to that effect in a previous thread. 
This system also makes it relatively easy to plug in different AI's
for the same army. The lower levels remain the same, while the higher
level code can be altered and played around with.
The higher levels don;t need the same detail of description as the
lower levels. The General doesn't need to know the exact location and
ability of each unit in a certain division, whether hostile or
friendly. It is sufficient to know that a force of magnitude X, that
can move so fast, is currently at a certain region.
Design of data strcuture can also have an effect on speed.
There is the question of whether we maintain a map of units - i.e. an
array where each array position is empty for no unit, or some value
(corresponding to a unit's ID) if a unit is present - the array would
have a corresponding terrain array as well, which is the standard map
- or whether each unit will store each current position, and simply
change that as it advances.(I think it nees to do that anyway)
I opt for a compromise, where the map is divided into regions, each
region points to all the units in that region, proximity checks only
involves units in the same region. Regions don't need to be updated
continously. One can update some of them each cycle, a side effect of
which is the regions somewhat overlap.

Another additional information that can save processing time (and I am
addressing something Eric raised way back in the beginning of the
thread, he was skeptical about using abstract descriptions by the
General and Colonels, figuring they would be computationally
expensive, because of varying terrain types) - one should have a time
map as well as distance map, we need not have more than one for each
unit type, and depending upon the design of the army, perhaps even no
more than one for each unit class/category. Thus the time it would
take a unit to traverse any given path, would not have to be computed,
but simply looked-up.  On a fractal landscape one could use a
different value for each axis and employ a simple formula to figure it
for any angle - however I find that fractal landscapes make for slower
LineOfSight calculations.
I realize that of these are designd issues, but these things do have
an effect on execution speed, and therefore were appropriate to this
thread.
Uri

