Backgammon, Part 12


The point to starting this series was to talk about making an AI for a backgammon RPG. With the yahoo game, the AI makes some boneheaded mistakes, such as unaccountably leaving blots in White’s home field in the mid-game, occasionally avoiding Red’s blots in order to play it safe for the running game, and to switch to a running game too early. Then again, yahoo game’s “dice” aren’t really random, with double 6’s, and 6-5, 1-3 combinations coming up way too frequently in the first one or two turns of the game for White. This means that White almost always has the advantage at the beginning, and you the player need to stick to a back game. As I said, I can beat the yahoo game 80% of the time, sometimes with a gammon, and a backgammon maybe once every 20 games. (A gammon is when one side wins when the other hasn’t started bearing off; a backgammon is when one side wins and the other side either still has one stone in their back field, or on the bar. A gammon is worth x2, and backgammon is worth x3. A human player will almost NEVER allow themselves to be backgammoned.)

It is possible to hardcode the first 2-3 turns using a table of dice rolls and the standard opening moves. The alternative, though, is to assign weights to certain outcomes, which lets me create NPCs for the game that can have varying tolerances for different kinds of risks.

A safe play is to move a stone to an existing block, making new blocks when possible and only leaving blots at the lowest numbered points (1-5 for White, 20-24 for Red) when unavoidable. Desire to initiate a running game would encourage the AI to move its stones out of its back field as early as possible, while the opposite would cause the AI to move the stones in the middle of the board (those on point 12 for White, 13 for Red) to maximize the number of blocks in the home field. An increased risk tolerance plus high “patience” would result in blots mid-board in the first 2-3 turns, and a possibility of blots being sent to the bar.

A patient game would tolerate being sent to the bar once or twice. A running game would want to check how many pieces would be sent to the bar to end up in its home field to mess up the game (ref. – hitting too many blots = bad). All games would check whether the running game has been initiated and then focus on bearing off the maximum number of stones per turn. They should also check whether one of their stones is on the bar when the opponent has the entire home field blocked (no point in rolling the dice if there’s 0% chance of getting on the board). Finally, a strategic game would distribute an extra one or two stones on blocks to make construction of long walls (4 or 6 blocks in a row) more likely.

Possible algorithm:

Set up board, set doubling cube to 1
Check who starts
(Roll one die each for high)
Starting player assigned as current
While no winner
current player rolls two dice
check if on bar
(if on bar, check if can move to board
if yes, check risks and opportunities and move to open point

if no, change current player
if yes and on board and can keep playing, keep playing)

For all points with player’s stones:
If not running game:
For all dice combinations:
Assign risk factor to each point that stone can land on
Assign opportunity factor to each point that stone can land on (includes bear off)
Identify opponent’s blot within reach of that stone and assign damage factor

If opponent can be sent to bar:
calculate number of opponent stones going into home field
Assign risk value to player’s home field blots
Check difficulty of returning to board if Opponent’s bar stone hits home field blot
Check length of opponent’s wall, if any
Compare calculated risk to NPC’s risk tolerance
Compare calculated opportunity (wall size, extra stones on point, etc.)
Compare blot hit count to NPC’s bloodthirst level
Compare opponent wall length and location to stupidity level
Move stones based on best-match pattern
Check all stone locations for initiation of running game
(If running game, set flag)

If running game:
Calculate maximum stone bear-off for each die combination
Compare bear-off count to NPC stupidity level
Move stones based on best-match pattern
Check for end of game

(If one side has 0 stones left:
assign winner
calculate value of game (score)
set end of game flag
Show Play Again? screen

Calculating risk:
Identify points that will have blots after a given move
For each blot, calculate percentage chance of being hit by ANY opponent stone
Calculate chance of having 3 or more opponent’s stones in your home field.

Calculating damage:
For each blot, get rough count of turns to return to current location if sent to the bar
If any blot goes to the bar, calculate chances of returning to the board
Divide lost turns by chances of returning to the board (check for divide by 0)

Calculating benefits:
Part A:
For all points with stones, identify which ones can hit an opponent’s blots
For hit-blots, get rough count of turns to return to current location
Calculate odds of hit-blot returning to the board
Divide inflicted lost turns by chances of returning to the board (check for divide by 0)

Part B:
Calculate number of points making up a wall, check wall length
Assign weights to new points based on closeness to the tray
Add benefit of making a longer wall closer to the tray
Assign weights to making points in the wall with only 3 stones on them

Part C:
Identify points that block the opponent from making a running escape when rolling 6’s.

There are probably some other niceties to include in the algorithm, but until I start writing the game, they can wait until later.

Fin

Advertisements
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: