Article View: rec.games.programmer
Article #1176Re: Help building a game?
From: Greg Bonney
Date: Thu, 12 Nov 1992 22:23
Date: Thu, 12 Nov 1992 22:23
59 lines
3485 bytes
3485 bytes
In <1992Nov12.183048.1308@schunix.uucp> sonix@schunix.uucp (Duane Morin) writes: >Often at work the senior engineer and myself discuss AI and such topics as >computer game strategy. He proposed a game that he suggests I attempt to >code an "optimal" strategy for. What I'd like to ask the net is some >suggestions on whether or not I'm taking the right approach, and if so how >to go about getting something concrete written. >The game: Many people will know this game, usually played on a piece of >paper with a few pencils. A grid of 5x5 dots is drawn on the paper. The >players (usually 2) take turns connecting lines either horizontally >or vertically. If a player succeeds in creating a box (i.e. four connected >lines) he gets to move again. The player with the most boxes at the end >of the game wins. (I've pointed out to him that a 5x5 grid creates 4x4 >squares, thus allowing for the possibility of a tie). >Problem: There are certain layouts that the board can fall into where one >player, given the chance, can chain together enough moves to cover the >board (or, at least, get the maximum number of squares). Thus, a computer >strategy would have to see this possibility and guard against it. >Strategy: Here's my initial thoughts: Look at the grid as a 4x4 array >of boxes. Each box can be described in 4 bits, representing the status >of its 4 walls. Any line that can be placed on the grid will effect >either one or two boxes (only one if its on an edge). A box's value can >be weighed something like this: > See the possibility of making 4, take it. > Don't make any 3's. Your opponent can turn them into 4's. > Conversely, make lot's of 2's. > Except early on in the game, avoid 1's. >This weighting strategy is simple, and might work. Unfortunately, it has >no lookahead or any capacity for learning. What I'd like to try is >something that learns from it's mistakes...for example, let it play >against itself again and again and develop it's own strategy. Anybody >got an idea of how I'd do that? I really can't see doing anything where >I have to represent all the states of the board (40 lines on the grid, >on or off, yields 2^40 states, correct?) >Or perhaps, something with lookahead? At any given time, there are 40 or >less moves that the computer can make. Temporarily make each one >(recursing if necessary, if the move yields a 4), and then for each one >weigh the possible moves that the other player could make. I don't know >how far down I could do this, though...maybe some sort of minimaxing? >As you can probably tell, I'm somewhat familiar with the theory behind writing >such a game strategy. However, having never actually coded it, I'm in a >bit of a bind as to how to approach the problem. Any help would be >wonderfully appreciated. >Thank you, > Duane Morin > sonix@schunix.uucp > I remember from an AI class learning something about alpha-beta testing. A lot of AI books talk about it. Using this will give your game the ability to "think ahead".
Technical Details
Message-ID:
<1992Nov12.222348.22047@esds.mdc.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!destroyer!gumby!wupost!esds!bonneyReferences:
<1992Nov12.183048.1308@schunix.uucp>Show Full Headers
Complete Article Headers
Newsgroups: rec.games.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!destroyer!gumby!wupost!esds!bonney From: bonney@esds.mdc.com (Greg Bonney) Subject: Re: Help building a game? Message-ID: <1992Nov12.222348.22047@esds.mdc.com> Organization: Visual Simulation Systems References: <1992Nov12.183048.1308@schunix.uucp> Distribution: usa Date: Thu, 12 Nov 1992 22:23:48 GMT Lines: 59