article1085.asp.htm

电脑游戏中的人工智能制作（含源代码）

  Anybody who does any type of strategic or tactical stuff should
read at least the Art of War, very good stuff indeed.

==============================================================================

William Uther ([e-mail]) wrote:

<<<SNIP>>>

: There is also one other interesting piece of info we've come across.  It
:

: most people would say that the 'Y' in the following diagram is not between
: the 'X's:

: X          X


:   Y

However Y is definately infulencing the connection between the X's.  The 
right X should be able to support the left, however it is possible that 
the reverse is impossible.  Of course terrain could modify this.

: Whereas, they would say the the Y is between these two X's:

: X          X
:    Y

Here I would consider Y to have interdicted the link, or the X's are 
still neighbours but they have outflanked/maybe even overrun, Y.

: The definition we found for 'between' or 'blocking' and hence allows you
: get neighbour (nothing is between) is as follows.
:   i) draw a circle between the two items such that the items sit on either
: end of a diameter of the circle.
:   ii) If there is anything inside that circle it is between the two items
: otherwise it's not.

An alternitive(I havn't played bolo so I don't know if it's appropriate) 
would be to draw a circle radius Y's maximum EFFECTIVE range (you decide 
what that is) and if it cuts a line drawn between the two X's the link is 
cut.

: We thought of defining front as that section 'between' the two centers. 
: This doesn't really handle multiple fronts, but then the game only really
: has two moving pieces which makes multiple fronts difficult anyway.

Andrae.
==============================================================================

Will Uther ([e-mail]) wrote:
: In article <3onpj8$[e-mail]>,

: A friend here ([e-mail]) I was discussing it with actually came
: up with a different solution.  (based on two tanks on a board moving
: pieces about - the game Bolo
: http://www.cs.su.oz.au/~will/bolo/brains.html)

: you define your 'center', their 'center' and the board 'center'.  Anything
: closer to your center than theirs is yours and can be taken.  If they take
: it back then it takes you less time to re-take than it takes them - if
: they bother to take it they lose more time than you.

:   The idea is to 
:  i) move your center towards the center of the board
: then ii) move your center towards their center, always keeping it between
: their center and the center of the board.  This should push them off the
: board.

:   the defintion of 'center' is tricky.  It's more a 'focus' than a
: center.  At the moment we have a couple we're looking at:

:    - The modal position of all your pieces.  (mean would be horrible if
: you get split in two somehow)
:    - The average position of your tank

: There is also one other interesting piece of info we've come across.  It
: involves finding neighbours.

: most people would say that the 'Y' in the following diagram is not between
: the 'X's:

: X          X


:   Y

: Whereas, they would say the the Y is between these two X's:

: X          X
:    Y

: The definition we found for 'between' or 'blocking' and hence allows you
: get neighbour (nothing is between) is as follows.
:   i) draw a circle between the two items such that the items sit on either
: end of a diameter of the circle.
:   ii) If there is anything inside that circle it is between the two items
: otherwise it's not.

: We thought of defining front as that section 'between' the two centers. 
: This doesn't really handle multiple fronts, but then the game only really
: has two moving pieces which makes multiple fronts difficult anyway.

: Looking forward to comments,

: \x/ill      :-}


   Hmmm...this does have some merit to it.  I like the idea of the 'center'
being arrived at via this circle-method; it has an elegance to it that also
is somewhat intuitive.

   The only potential problem I can see with this approach is that it will
tend towards great massive brute force engagements by migrating the bulk
of both forces towards a common 'center'.  This is fine in the case of
two combatants (i.e., two Bolo tanks) but not so good for two armies.

   I think we could solve the multiple front problem if we generalized the 
problem to find SEVERAL 'localized centers', thus allowing for multiple axes 
of advance along a somewhat more fluid 'front'.  In the case of two armies, 
you might get something like this:


           x                     x                      x 

             y1               y2    y3                    y4

           x                     x                      x 

    In this case, each of the x-x pairs make INDEPENDENT determinations
of what lies 'between' them.  Then, based on the relative combat strengths
and other factors, you could issue separate orders for each section of
the battlefield.  This effectively sets up a variety of 'mini-centers'
(using our terminology from above) and more realistically (IMHO) emulates
realworld operations (i.e., lots of mini-objectives, the possibility for
overlapping objectives, etc.).

     Opinions?  Comments?


Steven

==============================================================================

>"Satrapa / Alexander Marc (ISE)" <[e-mail]> wrote:
>
> On Wed, 10 May 1995, Will Uther wrote:
> [bigsnip]
> > you define your 'center', their 'center' and the board 'center'.  Anything
> > closer to your center than theirs is yours and can be taken.  If they take
> [snip]
> >   The idea is to 
> >  i) move your center towards the center of the board
> > then ii) move your center towards their center, always keeping it between
> > their center and the center of the board.  This should push them off the
> > board.
> 
> One problem - any enemy who knows this strategy may use it against you 
> (and therefore both sides end up fighting over the center while the edge 
> of the board is unused), or may act like water and flow - so you get 
> through to their centre, but find that the edges of the board have 
> suddenly caved in on you. So their center is your center, but their 
> distribution is wider than yours... while you're attacking them over 
> here, they're stealing your bases/terrain over there.

In the type of combat I was thinking of, you each have only one active
piece that moves around the board moving the other 'static' pieces.  If
Player A surrounds Player B, but Player B has supplies 'inside', then
player B has the
advantage.  e.g.

  1                  2


          3    4

          Supplies

          5    6


   7                 8


  Assume that 1,2,7 and 8 are owned by A and effectively 'surround' B who
owns 3, 4, 5 and 6 (and some supplies that mean he never has to leave his
fort).  B can attack 1.  when A moves there to defend, B can break off and
attack 8.  A has a long way to go to get to 8 (A has to go right around
whereas B can go through the centre) and so will probably lose that
piece.  Being more spead-out than the opposition can be a big problem.

  I agree that this is probably not the type of combat you were thinking
about.  For an example of this type of combat look at the mac game Bolo.

\x/ill      :-}

P.S. as a side note, Sun Tzu (sp?) in his 'Art of War' recommends against
sieges which is effectively the situation you have above.

William Uther                   [e-mail]

==============================================================================

Steve Woodcock <[e-mail]> wrote:
>
>   Hmmm...this does have some merit to it.  I like the idea of the 'center'
>being arrived at via this circle-method; it has an elegance to it that also
>is somewhat intuitive.
>
>   The only potential problem I can see with this approach is that it will
>tend towards great massive brute force engagements by migrating the bulk
>of both forces towards a common 'center'.  This is fine in the case of
>two combatants (i.e., two Bolo tanks) but not so good for two armies.

  Actually, Bolo can be played by as many as 16 players, with as many
as 16 different sides. But most people play against bots only when
they cannot get any human competition, and so play against only one.

>   I think we could solve the multiple front problem if we generalized the 
>problem to find SEVERAL 'localized centers', thus allowing for multiple axes 
>of advance along a somewhat more fluid 'front'.  In the case of two armies, 
>you might get something like this:
>
>
>           x                     x                      x 
>
>             y1               y2    y3                    y4
>
>           x                     x                      x 
>
>    In this case, each of the x-x pairs make INDEPENDENT determinations
>of what lies 'between' them.  Then, based on the relative combat strengths
>and other factors, you could issue separate orders for each section of
>the battlefield.  This effectively sets up a variety of 'mini-centers'
>(using our terminology from above) and more realistically (IMHO) emulates
>realworld operations (i.e., lots of mini-objectives, the possibility for
>overlapping objectives, etc.).

  Hmmm...

  I assume that this assumes a single master strategist giving orders
to the units. I would think that the master should group neighboring
units as one, in order to save time when calculating the following:
calculate a center between every piece and every other. When his is
all done, choose the minimum amount of centers which take care of the
maximum amount of enemies. This should allow certain interesting
effects over varying terrain, if said terrain is taken into account as
it should be.

  Otherwise, it sounds pretty good. If I ever get my set of Bolo
brains working, I'll turn 'em loose and see what happens.

Robert Uhl

==============================================================================

   First off, let me just say that I think this is a *great* thread, easily
one of the more interesting I've seen in this newsgroup.  *This* is the kind
of brainstorming the Net was made for....



Andrae Muys ([e-mail]) wrote:

: Identifing the front first and then defining the rest w.r.t it would seem 
: to simplify the problem further.  I hadn't thought of that, it looks like 
: a good idea.  However one question to contimplate.  Where are the fronts 
: in the following position. {X - YOURS, Y - THEIRS}

:             YY      Now by any standards X is in a bad way.  It has been
:              Y      completely outflanked and his left flank is already
:      XXX     YY     overrun.  Intuitivly his front is now perpendicular
: XX XXX  XX   XY  Y  to Y's.  I think we may need a concept such as