An opening database is an important feature of an engine.
This is because the opening has many possibilities and
there arent much pieces taken yet.
To quickly evaluate the position a database can be useful.
The first step for the database integration was now done by
a program to create and store pgn data in the db.
The next step is to add a way to use the data in the engine.
The tests where cluttering the src dir
so i moved them to a separate dir.
Same goes for the binaries so i changed the
outputdirectory for them and
added these to the new gitignore file
Castling was bugged in the previous version.
The pieces moved on the wrong squares due to W and E being set wrongly.
convertToFen didnt record empty squares if located
at the end of the fen string.
The en passant square is only important if it is
target of an enemy pawn.
If that is not the case it should not be set
and shouldn't appear in the fen string either.
Now it is checked if the en passant square is
the target of an enemy pawn
Repetitions can only occur if the pieces and castling
rights are exactly the same.
For memory sake the sequence of last boards
is now emptied if a capture occurs,
a pawn moves, or if the castle
rights change.
That directly makes the saving of the castling
rights obsolete.
Now there is a method to turn a chess
object into a fen-string.
Additionally the enPassant handling was
changed.
There can be only one enPassant field
at a time.
So a new attribute was added to the chess
object that stores the field for the
enPassant capture.
If there is no enPassant field it will be set to -1.
NegaMax is a simplified version of the MiniMax algorithm that
doesn't need different subroutines for the different colors.
The testcases were selected and extended.
Evaluation now has values for draws and wins.
If the threefold repitition check is called before enough moves
are saved in the previous board state it throws a nullpointer.
A simple null check solves the problem
Integrated the engine into the playable game.
Created a menu to choose between single player and hotseat.
Added a way to choose difficulty and color in single player.
I created an engine, that uses a basic version of the minimax algorithm
to evaluate a position.
It then evaluates all the possible next moves in a given position and picks
the one that has the best evaluation.
Basic test cases were also added.
Moved was a 10x12 1-d array, that stored bools.
It was only used for checking if a pawn moved (especially important for
the double move of the pawns) and if the other pieces moved (important
for checking if the player can castle or not).
The pawn moves are now checked by the starting position (pawns on the
second rank cant be already moved).
The castle rights of a game are expressed as CastleRights, a tuple with 4 bools.
This saves basically 116 boolean values.
Setters are not needed as all the assigning gets handled inside the file.
All Setters were removed.
The try-statements were used to excessively and were changed for manual checking
Due to the official nim documentation the snake_case was now swapped
for camelCase.
Tests for nearly any move were added.
A new procedure can initialize a game with a given 8x8 board with pieces and determines if
they have been moved already.
The most important movements and even en passant and castling are implemented.
A cli game is not done for now.
An engine is the goal of the project, but will be focussed at the end of the basic development.
TiynGER
marten