In the last few commits the problem occured
that absolute paths are needed for correct
and unambiguous locations for binary files
or the database.
For the compiler arguments the problem is now
solved with an automatic script, that creates
the absolute paths automatically for different
systems.
The database path is now specified by calling
a new function, that finds the root of the
project followed by a relative path.
Due to the path for the db being relative it came
to problems when importing the openingBook.nim file
in other modules (especially in ).
To change this i added a variable, that needs to point to the
root directory of the project.
Additionally i set some coding guidelines and enforced them
into the current codebase.
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.
TiynGER
marten