Newsgroups: comp.ai.games
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!CTCnet!news.math.psu.edu!chi-news.cic.net!cs.utexas.edu!howland.reston.ans.net!surfnet.nl!sun4nl!phcoms4.seri.philips.nl!newssvr!vdhaar
From: vdhaar@natlab.research.philips.com (Haar vd P.)
Subject: Re: Writing Othello game, please advise.
Sender: news@natlab.research.philips.com (USENET News System)
Message-ID: <DnsFM4.3n6@natlab.research.philips.com>
Date: Tue, 5 Mar 1996 09:27:39 GMT
References: <4hfcei$mtt@wolfe.wimsey.com>
Organization: Philips Research Laboratories Eindhoven, Netherlands
X-Newsreader: TIN [version 1.2 PL2]
Lines: 88

William Robert Night (wnight@vanbc.wimsey.com) wrote:
: I have written an othello game capable of recursively analysing boards 
: based on a pruned tree (only the best trees get searched). The problem 
: with it is that the only things it uses to decide the worth of a board, 
: is the weight of the positions pieces are in.
:  
: There are weights assigned to each square and it totals up the weight of 
: all squares it occupies, subtracts the value of the opponents squares, 
: and returns this value. The main routine then picks the from a list of 
: routines that tie for best.
:  
: What sort of rules should I take into account?
:  
: Obviously the weight of the squares surrounding the corner which is 
: negative in the beginning to keep the program from giving away a corner 
: should become positive if you already own that corner... What other ones 
: are there, and how do I code these without thousands of special cases?
:  
: BTW: Anyone have a good weighting for the squares?

Great to see an Othello enthousiast here! I've also been tinkering
with an Othello program (called mine Reversi though).
It operates along the same lines, alfa-beta pruning, and weighted
positions.

What I now use are the following fixed weights;

int strength[INDEXHI+1][INDEXHI+1] =
{{ 1024,    2,  256,   16,   16,  256,    2, 1024},
 {    2,    1,    8,    4,    4,    8,    1,    2},
 {  256,    8,  128,   32,   32,  128,    8,  256},
 {   16,    4,   32,  128,  128,   32,    4,   16},
 {   16,    4,   32,  128,  128,   32,    4,   16},
 {  256,    8,  128,   32,   32,  128,    8,  256},
 {    2,    1,    8,    4,    4,    8,    1,    2},
 { 1024,    2,  256,   16,   16,  256,    2, 1024}};

However, when the end of the game comes within the event horizon
(about 8 plies deep for a 5 minute response on a HP-UX unix system),
all positions in this array get value 1. Which goes to say it just
counts stones from that point onward.

I've not yet inserted further strenght modifications like you suggested
for the corner stones, but I do see it's benefits. If one decides to
do so, it is necessary to pass the strength array along with the
board during the min-max algorithm. There are two reasons for this,
one being that the process is dynamic: strengths may toggle each ply
deeper. The second is that you don't want to find out that a
location next to a corner stone increases in value after you have
played the corner, but rather beforehand.

With regard to strategies I can think of, here's a top 3 of
strategic issues you might want to consider on top of the
corner and border modifications you suggested:

1. Book of known openings (e.g. diagonal v.v. parallel)
   - Faster response in early game
   - Avoid spending time on common symmetric situations in initial game
     like  XO
          XXX
          OX
   - Avoids board situations which have proven to be
     disadvantageous for either white or black later on,
     or conversly trick the opponent into one.
2. Maximise the number of posible moves, while minimising
   those of opponent (mobility)
3. Main diagonal control in end game to avoid being forced
   to play b2, b7, g2, g7

I'm sure I'm able to come up with much more, but I guess it's a
fine start.

I'd be very interested to hear what others might have contributed
for ideas...

Greetings, Peter van de Haar
--
 ___ _ _________ _____ _ _ _ _______ _ _ 
|  _| |_ ___ _ _|  ___| | | |_   ___| | |
| |_   _|   | |___|_   _| |_  |_|  ___| |
|___|_|_____|_______|_|_____|___|_|_____|
 _______________________________________
|           Peter van de Haar           |
|  vdhaar@natlab.research.philips.com   |
|_______________________________________|
|  Standard disclaimer:  All opinions   |
|  expressed are  mine,  mine,  mine!!  |
|_______________________________________|
