You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+53-1Lines changed: 53 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -50,7 +50,7 @@ game = Chess.loadFrom(r'file')
50
50
*```Test_Chess.py``` is for use in the command line. It could load up a .save file and provide an interactive console from an instance of the game and gives control for testing.
51
51
* The assets folder contain sample games for the test to load and also images of pieces for the game to use.
52
52
53
-
## Documentation
53
+
## History
54
54
55
55
I began the project with the intention of implementing Regressive Learning on the Chess board.
56
56
@@ -64,3 +64,55 @@ I began the project with the intention of implementing Regressive Learning on th
64
64
UI code controlled the game menus and the controls to the game.
65
65
66
66
> This I later realized to be a bad practice as Game Logic and UI logic seemed to mix throughout the code and seperate concerns got entangled together.
67
+
* I had architected the game in such a way that control started from the UI.
68
+
The UI code controlled UI logic, instantiated the player and game object classes. The UI code was responsible for displaying the game state and handling User Interaction and also delegating the choices made by the players to the game.
69
+
* A lot of effort was already spent on UI and architecture design, maybe that must be the aftermath of poor project planning and a lack of personal consistency.
70
+
I decided to focus more of my efforts on implementing Player classes and tapping into Intelligence part of the project.
71
+
72
+
## The rise of Intelligence
73
+
74
+
Here I record the journey to developing better performing Chess players.
75
+
The observations and improvements made are also summarized.
76
+
77
+
* Random and Greedy Players
78
+
I had already started out with a `PlayerRandom` and a `GreedyPlayer` to start off with.
79
+
As the name suggests, the random player makes random moves out of the available moves and the greedy player additionally tries to take pieces in a greedy fashion if there are pieces to take.
80
+
This helped test out scenarios involving non-human players.
81
+
This didn't serve any intelligence as such and the satisfaction waned away really fast.
82
+
* Minimax Players
83
+
Here is [the Minimax algorithm from Wikipedia](https://en.wikipedia.org/wiki/Minimax)
84
+
The idea is to choose a move, but for each possible move, we also calculate the move that the oponent will take, so and and so forth until N levels of depth are reached on the search tree.
85
+
86
+
```txt
87
+
(X) minplayer
88
+
move 1 / \ move 2
89
+
(Y) (Z) maxplayer
90
+
/ \ / \
91
+
(A) (B) (C) (D)
92
+
-5 9 2 1
93
+
94
+
(X) minplayer
95
+
/ \
96
+
(Y) (Z) maxplayer chooses move with max value
97
+
9 2
98
+
99
+
(X) takes move with minimum value
100
+
2
101
+
```
102
+
103
+
Without a limit on the depth, the algorithm might end up finding all possible moves in the game. This is not a practical choice for a game like Chess which has too many possibilities to evaluate. So on the last depth level, an estimate value of the game is used.
104
+
105
+
Implementing the Minimax algorithm improved gameplay but there were edge cases, partly due to errors in my implementation and partly due to the value estimation I had set up.
106
+
*`MinimaxPlayer_00` only has a value function that maximized the "opportunity" of taking pieces by counting the number of pieces that were available for take on a game position.
107
+
It only estimated a single move and didn't really perform a Minimax search.
108
+
*`MinimaxPlayer_01`, `MinimaxPlayer_02` and `MinimaxPlayer_03` experimented with minor improvements that helped setup the minimax algorithm.
109
+
Evaluating just 3 successions of game positions started to take more than a minute to complete.
110
+
Another noteable issue was the UI blocking during this time when the player was making its calculations.
111
+
**Threads** helped to solve this issue by parallelizing the player process.
112
+
113
+
The value function still optimized only the "possibility" of a take.
114
+
To no surprise, it didn't prioritize takes but only the opportunity.
115
+
The player played the game moving pieces into good positions but it didn't attack.
116
+
o___0
117
+
*`MinimaxPlayer_04` solved the long calculation times taken by the older versions by implementing **alpha-beta pruning** on the search tree.
118
+
the alpha-beta pruning maintains two values alpha and beta across the search algorithm.
0 commit comments