Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create the first iteration of the Opponent Profiler #21

Open
CarlSpencer-IBM opened this issue Jun 6, 2017 · 1 comment
Open

Create the first iteration of the Opponent Profiler #21

CarlSpencer-IBM opened this issue Jun 6, 2017 · 1 comment
Labels

Comments

@CarlSpencer-IBM
Copy link
Collaborator

The Opponent Profiler should aspire to consist of:

  • A data model for all the things we might want to know about a opponent and data store for active players in that model. These should be both chess-specific facts and profiled data plus as appropriate wider human pieces of information - as much as we may consider potentially useful in gaining an edge over them.
  • Interfaces which allow any elements of the player profile to be queried and pulled by other components of the system

To achieve this:

  • It is envisaged OP will have access to a main player database (need to define source of this - it might be problematic to nick Chessbase's!) for the retrieval of player static data (age, nationality, title, current rating perhaps ...)
    (NOT intended for first iteration, but these are the later goals)
  • Chronological data on the player - rating history, events played, achievements (titles, prizes, etc.)
  • Profiled data - mined from game data and elsewhere - worst opponents, best opponents; stats by opening, usage of time, inference of style e.g. - aggressive, positional, strong in endgames, etc.
  • Profiled data can be added to when K-9 plays the opponent because he gets direct, detailed information.
@marisvs
Copy link
Collaborator

marisvs commented Jun 9, 2017

A major component of the OP is the profiled game data (lets call it Opponents Game Profile = OGP). I see 2 options:

  1. Tree like structure to capture all played moves in the games and their results up to (but not including) midgame phase. Search is based on a hard key derived from the game position (FEN is default choice).
  2. Database of positions (again FEN based) but with a soft position/based key. I have seen some articles describing such a key. This possibly could support playing style based optimization.
    During the build-up of the OGP, we simply place played moves in the structure and add the game result to the leaves and path leading to the leave (in option 1). Of course, additional stats can be added. The main thing will be the rating difference with the opponent's opponent.

Either way, the OGP can be used during the opening phase of the game by selecting moves where the opponent has the lowest score ratio.

I suggest to start with option 1 because that is all doable, and, depending on resources, start doing some research around option 2 and combine both options in a later phase.

@marisvs marisvs closed this as completed Jun 9, 2017
@marisvs marisvs reopened this Jun 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants