lrozenblyum / chess Goto Github PK

Upgrade 4.10 -> 4.11

No sense to keep Java6 which is not supported by Oracle so far (no further updates are planned)

Make the winboard engine at least react on the actions

Sonar 3.3 has been released recently

Set up CI (to run unit-tests and Sonar analyzing on daily basis).
Hudson/Jenkins/...?

Select Pri0 features that must be implemented

When I move my pawn to promotion rank only queen is created, is it a bug in Winboard or need somehow control the possibility to select?

Use mockito. Creating mocks manually is rather expensive when often needed

Sonar/FindBugs/??
Something integrated with github would be perfect

It's nice search query (to build community/increase interest)

All the changes I see now in PawnMovement are related to 'so-called' statics - which moves are available.
However we need also dynamics:
which position will we reach after the one of the available moves being executed.
It's VERY important especially for en passant (and for promotion)

Finally it's time to introduce the King into the action!
However it could be a long-term task so it may be developed in parts...

Need to implement chess rules 3.8, 3.9.
They must be decomposed into sub-tasks

Implement rules for rook:
3.3 The rook may move to any square along the file or the rank on which it stands.
3.5 When making these moves the bishop, rook or queen may not move over any intervening pieces.

Castling is NOT covered by these changes.

Currently all tests are stable so far (however there were some tests that had utility methods 'for future' to cover something bigger).
Need to think if we need random/multi-parameterized tests at all

What is allowed by github?
Include license description into the project

Alllow further easier work with Maven and clear test separation in package way (I will TDD here ;)

Implement Bishop movement according to rules:
3.2 The bishop may move to any square along a diagonal on which it stands.
3.5 When making these moves the bishop, rook or queen may not move over any intervening pieces.

Check integrationally with pawns and knights

The castling is rather a complex topic, therefore I introduce a separate sub-issue of #65

(0) This is a move of the king and either rook of the same colour along the player’s first rank, counting as a single move of the king and executed as follows: the king is transferred from its original square two squares towards the rook on its original square, then that rook is transferred to the square the king has just crossed.

(1) The right to castle has been lost:
if the king has already moved, or
with a rook that has already moved.

(2) Castling is prevented temporarily:
if the square on which the king stands, or the square which it must cross, or the square which it is to occupy, is attacked by one or more of the opponent's pieces, or
if there is any piece between the king and the rook with which castling is to be effected.

Think about a player who can self-learn from game to game.

Suppose we import 1-10-100- million of games and make some sophisticating learning possibility? E.g. neuron network etc

Check migration guides and so on.

It's a world standard and will simplify import/export of games

http://portablegamenotation.com/Specification.html - down at the moment of checking on 2020-12-20
https://www.thechessdrum.net/PGN_Reference.txt
http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm

• Acceptance criteria

  • Normal moves
    • Prevent ambiguous moves like in 1. d4 d5 2. Nf3 Nf6 3. Nd2 the 3'd
    • promotion
    • castling
    • captures
  • special moves
  • output ('export') mode only? (is 'import' to be split?)
    • reduced export format?
    • seven tag roster
    • For PGN export format, a single blank line appears after the last of the tag
      pairs to conclude the tag pair section. This helps simple scanning programs to
      quickly determine the end of the tag pair section and the beginning of the
      movetext section.
  • service fields
  • non-standard fields
  • game outcome
  • tool for validation might be useful: https://www.cs.kent.ac.uk/people/staff/djb/pgn-extract/help.html#flag-summary

• Issue with PGN itself https://zuttobenkyou.wordpress.com/2012/01/27/problems-with-the-portable-game-notation-pgn-standard/

  • Pay attention to encoding...
  • Line separators
  • 4.2. Tab character prohibition
  • Event (the name of the tournament or match event)
    • Simple case
    • Customization
    • colons processing (?)
    • special characers (?)
  • Site (the location of the event)
    • simple case
    • customization
  • Date (the starting date of the game)
    • known date
    • missing parts (?)
    • missing full day
  • Round (the playing round ordinal of the game)
    • number of game played
    • question if unknown
    • hyphen if not appropriate
  • White (the player of the white pieces)
    • human
      • Last name
      • first name/first initial
      • 1/more middle initials
      • More than 1 person playing white pieces
    • computer program
      • name
      • version information
    • Question mark if unknown
  • Black (the player of the black pieces)
  • Result (the result of the game)
    • white wins
    • black wins
    • drawn game
    • game still in progress
    • game abandoned
    • result otherwise unknown
    • same as termination marker in movetext
  • movetext section
    • export format (?): justification + 80
    • export format: space at start/end prohibition
    • The movetext section is composed of chess moves, move number indications,
      optional annotations, and a single concluding game termination marker.
    • move number indication
    • SAN
    • illegal moves not permitted
      • illegal moves permitted in commentary section
    • 8.2: Movetext section

• Architectural challenge

  • Where to implement: custom player? Game level?

• Testing ways

  • Engine vs Engine
  • Engine vs Winboard
    • Compare with Winboard-generated?
  • Engine vs UCI (?)
  • Import the output to some chess software, check if it's reasonable
  • extract a new project with PGN support (?)
  • PGNGameRealPlayersTest is running too long

Integrate mutational testing into Sonar

Currently only first white move is Ok. Need to develop black-moving player as well (at least for usual 2 moves). This will allow adding more processing, .e..g. of resignment of its opponent.

(0) This is a move of the king and either rook of the same colour along the player’s first rank, counting as a single move of the king and executed as follows: the king is transferred from its original square two squares towards the rook on its original square, then that rook is transferred to the square the king has just crossed.

This is sub-task of #76

Rule 3.7a:
The pawn may move forward to the UNOCCUPIED square immediately in front of it on the same file, or

Rule 3.7b
on its first move the pawn may move as in 3.7.a or alternatively it may advance two squares along the same file provided both squares are UNOCCUPIED, or

Jenkins pulls all the repository branches (including non-master), so changes that were not in master were already put to Sonar. Think if it's nice??

Be able to run the engine on Android
http://www.aartbik.com/MISC/eng.html

It initializes too long (is our engine the cause? Java5-6-7? google etc)

Implement rule 3.6.
The knight may move to one of the squares nearest to that on which it stands but not on the same rank, file or diagonal.

• move possibilities
• move execution
• validate some integration with pawn movement.

But keep an eye on the mailing list, it looked like some guys had problems with this minor update.

Implement Queen movement.
3.4. The queen may move to any square along the file, the rank or a diagonal on which it stands.
3.5 When making these moves the bishop, rook or queen may not move over any intervening pieces.

Think about generalizing rook/bishop/queen movement. Look well at Direction/HorizontalDirection/VerticalDirection enums...

Think about whole GitHub repository backuping policy - internal/external/CI-controlled?..

Analyze; create user stories

Extend backlog below.
Create separate issues per item TODO

Winboard UI is as I see non-validating, it allows me doing illegal moves.
Need adding validation to our engine.

It's needed for IDE-independency, easier libraries management and #6

"The king is said to be 'in check' if it is attacked by one or more of the opponent's pieces, even if such pieces are constrained from moving to that square because they would then leave or place their own king in check. No piece can be moved that will either expose the king of the same colour to check or leave that king in check."

Practically need to limit amount of moves to only those ones which don't leave the king in check (not exposing the king to check looks like already implemented )

Formerly known as Sonar

It means that some configuration files must be added (minimally required) that will allow easy start-up on clean environment (without boring set up of classpath etc)

Define the fastest way to 'deploy' to the winboard.
Maybe integrate winboard inside IDE?

Now pawns and queens are stored separately - it's really hard-to-support.
Need to define a data model which will make the piece management easy

Our engine doesn't receive resign notification

Add the castling to list of allowed moves.
At this stage it's enough not to enable any validation on 1) & 2) cases from #76

Now the MainRunner definitely shows mix of Player's responsibilities - both thinking engine that plays AGAINST WinBoard player, and WinBoard player work himself.
It definitely must be split into 2 separate players (it would be very good to share common interface):

1. Winboard 'thin client' player - who will delegate the real play to Winboard's player (e.g. human or another engine), and encapsulate all low-level communication issues
2. Chess 'thick client' player - internal engine, real brains, it's opponent of 1)

Implementing them via common interface will help greatly for the next engines implementations, portability and flexibility