Subject: my abalone evaluation function

From: [email-masked] (Michael P. Frank)
Date: Fri, 23 Apr 93 16:47:43 EDT

Since everyone seems to be talking about board evaluation functions, I
might as well throw mine out there...

For each pair of one of A's marbles and one of B's marbles, I measure
the length of the line segment from A *through B* to a wall.  I add up
this length for all the pairs.  The total measures how far player A is
from having B backed up against a wall.  The negative of this quantity
measures how close A is to having B backed up against a wall.

Then you do this the other way around (measure the lengths from B's
marbles through A's marbles to a wall) and then find the difference
between the two totals.  This measures how much better A's position is
compared to B's.

One nice thing about this quantity is that if the enemy backs up some
of your marbles against an edge, and there's no way for you to
immediately move away from the edge, this measure will make you kind
of squirt out sideways, because, although you aren't any farther from
the edge, you are farther from being pushed off the edge by the enemy,
if you see what I mean.

Currently I only use this positional quantity to distinguish between
states having the same number of marbles; so my program will sacrifice
any quality of position in order to push off an enemy.  This is
actually a pretty bad strategy; the positional quantity should have a
larger weight.

-Mike

---

From: [email-masked] (Michael P. Frank)
Date: Mon, 26 Apr 93 13:21:29 EDT

[email-masked] (Ulrich Mayring) writes:
> Well, let's see if I got this one right: Your evaluation function does in
> fact like it when you push your opponent against the edge of the board,
> but it doesn't distinguish if you do that with an equal number of 
> marbles, a lesser or a greater one? So, in fact you would score high, when
> you pushed three marbles of your opponent against the edge, while only
> having two to do the job? 

Yeah, it's true that having 2 marbles hovering over 3 enemy marbles
that are against the edge gives you about the same static score as
having 2 marbles hovering over 3, all else being equal.  But I think
that's ok; it's good to have lots of enemy marbles against the edge;
it means fewer in his main body.  Even if we don't have enough force
to push them off right away, having more of them there decreases the
chances that they'll all be able to escape before we can bring in more
marbles to push them off.

> I should think you would need some kind of sumito-evaluator, or do
> these discrepancies even out over the long run/tree?  Or does your
> function work like this: When you have three marbles against two you
> measure the distance three times for your side and only two times
> for your opponent's side, thus giving you a better score.

No, your earlier interpretation was correct.

> Still, from my experience of gaming (not a lot, actually) I think
> that a sumito-position in the early game, when the two
> marble-structures are still relatively intact, is much more
> important than any evaluation function I can think of is capable to
> compute.

The thing about checking for sumito opportunities in the evaluation
function is that it's basically like trying to stuff one extra level
of search into the positional evaluator.  It seemed to me like it
would be better to make the evaluator fast and simple and truly
positional, and do the look-ahead for good moves in the search
routine, where it belongs.

You should try it out---it's amazingly good for its simplicity.  The
main deficiencies in our program's play seem to be due to the fact
that it weighs pushing off enemy marbles so much more than positional
strength.  But this would be easy enough to adjust.

By the way, another advantage of this evaluation function is that's
it's easy to change it incrementally as we explore the game tree---so
we don't have to compute it from scratch on every position.

> Greetings, Ulrich

-Mike

---

From: [email-masked] (Ulrich Mayring)
Date: Wed, 28 Apr 93 21:55:14 MET DST

>From a private conversation with Mike Frank about his evaluation strategy:
> 

Well, what you are saying is, that if we already implemented a nice Minimax
strategy, why not use it? This is a valid statement, but do you know how many
plies commercial chess evaluators search? Methinks at most 7 (correct me here),
so search depth doesn't appear to be the one-all of board evaluation. Also, 
with your search strategy you may not find a good sumito position, because it
means giving up a center position. But if the two marble-structures meet in the
middle of the board, the one, who wants to attack must make a sumito move AWAY
from the center. If he will not do that, because of positional value, he may
well be playing very boring. Is that not a main problem of your automaton?
> we don't have to compute it from scratch on every position.
Ulrich.

---

From: [email-masked] (Michael P. Frank)
Date: Wed, 28 Apr 93 17:49:37 EDT

[email-masked] (Ulrich Mayring) writes:

> Well, what you are saying is, that if we already implemented a nice
> Minimax strategy, why not use it? This is a valid statement, but do
> you know how many plies commercial chess evaluators search? Methinks
> at most 7 (correct me here), so search depth doesn't appear to be
> the one-all of board evaluation. Also, with your search strategy you
> may not find a good sumito position, because it means giving up a
> center position. But if the two marble-structures meet in the middle
> of the board, the one, who wants to attack must make a sumito move
> AWAY from the center. If he will not do that, because of positional
> value, he may well be playing very boring. Is that not a main
> problem of your automaton?

Actually, in situations like you're describing, my evaluation function
often *does* rate the sumito move as being better than staying at the
center, because it pushes enemy marbles closer to the edge.  What I'm
saying is that my eval func doesn't do the *lookahead* to find the
sumito move; I just let the search take care of that.

-Mike