Anonymous user
Morpion solitaire/Unicon: Difference between revisions
description
m (text clarification) |
(description) |
||
Line 1:
This example goes beyond the task goal of playing a random game of Morpion solitaire. The program was designed as a first cut/test bed more for understanding and
* Playing single games or running multigame simulations to find and capture the best games
* Producing re-loadable game records and the ability to replay a saved game from a given position forward
* The ability to reproduce purely random games from the random number seed
* Limiting the initial random moves to 1 of 4 cases (inside corners (1 type) x 8, outside corners (2 types) x 8, outside valley (1 type x 4)) not 1 of 28. In the case of this program these are all in the North East quadrant.
* Plugable modules for functions including applying player strategy, position evaluation (fitness/heuristics)to facilitate quick experimentation
* The version of the game played is a 'touching' (5T) game, although the validation procedure is easily parametrized.
Line 9:
Using random play in many summary runs, the highest (5T) score achieved was 90. While it was fairly easy to push random games into the low 80's running simulations of as little as a few hundred games, going beyond the highest score without adding some smarts will require some very long runs and is unlikely to result in any significant progress. Observing multigame runs show that play advances fairly quickly before a progress grinds to a virtual halt. Many runs peak in the first few hundred or thousand games.
The ability to replay recorded games provides a way to study the behaviour of the problem. Selecting successful random games, truncating them and running multigame simulations using a successful base shows that the seeds of success are sown early. It was possible to better the results of good random game scores (mid 80s) pushing the new scores up into the mid 90s. Unfortunately this technique when applied to Chris Rosin's 177 move record game did not produce any new records :(. Surprisingly however, it was possible to produce games in the high 160's! using random play with a truncated (approx 60%) version of this game.
The observation that a game becomes bad or good fairly early suggests that finding an intelligent forward looking position fitness evaluator is going to be a challenge to say the least.
Line 15:
It's also possible to capture bad games. This might provide some kind of comparison against good games when considering fitness evaluators. Or not.
Internally, the grid is automatically expanded as needed whenever a cell is played on an outer edge. When this happens only the affected side is expanded. As a side effect the grid numbering will seem unusual. The game log shows all row/col coordinates relative to the 1,1 origin located at the intersection of the lines containing top and left most edges of the cross. A fixed grid might be more efficient. With the ability to detect an off page condition and save and replay the game later this could be easier to deal with. The issue of grid origin comes up all the time when working with the code and debugging output.
For an example of a loadable and re-playable game see [[Morpion_solitaire/Rosin177|Chris Rosin's 177 move 5T previous record holder]].
| |||