Recently I was reading through a thread referring to games, and it reminded me of the story I had read about the gentleman whom invented the Connect Four gaming machine.
It seems that when he tried to solve the game going forwards, playing move by move, and attempting to compute all possible moves, it became a staggering task which defied computational resources available to gaming machines. This sprung to mind reading tilly's comment regarding doing something similar with Go or Othello:
Be warned. While you might build a prototype in Perl, you will not have any possibility of succeeding in your eventual goal without rewriting in a different language. Perl is just too wasteful on memory to be great at this task.I quite agree.
So... Keeping that in mind, the resolution to the connect four problem was reached by computing the problem backwards.
What I was considering was to start with computing the factorial variations which define the set of winning board states. This would consist, for example of greater than 50% of the board consisting of a single color when completely filled. This limits the computational space so that every potential state need not be explored.
Work backwards from these to define potential paths to attain them. This is a one time operation which will require vast amounts of storage and a long time to run. (This is where it gets fun...or completely breaks down)
The results are then subject to statistical analysis, which is once again a one-time operation.
By thereafter resolving which board-states are most common and which paths are shortest to a winning resolution you create a string of potential board state targets to try to attain at every move. In this case a move is defined as a search space related to the number of empty spaces left on the board.
My limited understanding of this subject leads me to believe that this would lead to more of a pattern matching problem added to playing the game.
This has something to do with human thinking also, since our brains are better at pattern recognition than repetitious computation.
The question then becomes how to filter out the 'line noise' of the competetor, whom will naturally not take the optimal path for his/her competetor to win. That is where I see the traditional min-max tree approach taking hold to try to return the state of the board to one which leads to a winning combination.
Something to play with anyway...
Wait! This isn't a Parachute, this is a Backpack!
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Looking backwards to GO forwards
by dragonchild (Archbishop) on Sep 05, 2001 at 16:45 UTC | |
by Johnny Golden (Scribe) on Sep 06, 2001 at 17:32 UTC | |
by gregor42 (Parson) on Sep 06, 2001 at 18:24 UTC | |
by tilly (Archbishop) on Sep 07, 2001 at 01:39 UTC | |
by dragonchild (Archbishop) on Sep 07, 2001 at 17:02 UTC | |
by dragonchild (Archbishop) on Sep 06, 2001 at 18:36 UTC | |
Re: Looking backwards to GO forwards
by Hofmator (Curate) on Sep 05, 2001 at 13:49 UTC |