Object model for chess GUI?

[Sven]

Beware that writing a GUI is between 10 and 100 times more work than writing an engine.

In XBoard the games is stored as an array of positions. I added variation trees only later, by shelving the game tail in a similar array operated as a stack, any time you replace it with a variation. So that you can revert easily to the main line/previous variation by popping it.

So in principle there should be 10 to 100 times more posts about chess GUI development.

No, 10 to 100 times less posts since the chess GUI developers have less time for posting.

[Henk]

Beware that writing a GUI is between 10 and 100 times more work than writing an engine.

In XBoard the games is stored as an array of positions. I added variation trees only later, by shelving the game tail in a similar array operated as a stack, any time you replace it with a variation. So that you can revert easily to the main line/previous variation by popping it.

So in principle there should be 10 to 100 times more posts about chess GUI development.

No, 10 to 100 times less posts since the chess GUI developers have less time for posting.

Perhaps mathematicians don't like GUI development. Also GUI has to look nice. And that's a matter of taste.

[gbtami]

Beware that writing a GUI is between 10 and 100 times more work than writing an engine.

In XBoard the games is stored as an array of positions. I added variation trees only later, by shelving the game tail in a similar array operated as a stack, any time you replace it with a variation. So that you can revert easily to the main line/previous variation by popping it.

So in principle there should be 10 to 100 times more posts about chess GUI development.

No, 10 to 100 times less posts since the chess GUI developers have less time for posting.

Perhaps mathematicians don't like GUI development. Also GUI has to look nice. And that's a matter of taste.

I'v started as physicist (1year) but finished as mathematician (5 year)

[Steve Maughan]

Hi H.G.

Yes - I can believe it. But I think it'll be fun,

- Steve

[Steve Maughan]

Thanks Sven,

That's helpful. I think the Arbitrator will only hold a basic representation of the position, along with clock times etc.

Thanks - Steve

[tpetzke]

Hi Steve,

just as a source of inspiartion I post the declaration of my TGame class from my shaker GUI. This class controls the game between two engines.

The engines are from a class TEngine which is an interface class to an external engine. Of course the class needs a board, where the moves are executed so it keeps track of the progress. Then there are a lot of helper classes needed, e.g. to write a PGN file or to control the clock etc...

Code: Select all

TGame = class(TThread)
    board        : TBoard;

    constructor Create(aEvent, aSite, aRound : String; aWhite, aBlack : TEngine; aClock : TChessClock; aAdjudicationRules : TAdjudicationRules; opPGN : TPGN; opMaxMoves : Integer);
    destructor  Free; virtual;

    procedure   StartGame;
    procedure   cancelGame;
    procedure   cancelGame(winFor : EColor);
    function    getGameStatus:EGAME_STATUS;
    function    createPGN:TPGN;
    procedure   savePGN(aFileName : string; format : EPGNMoveFormat);
    procedure   getIterations(side : EColor; var iterations : TIterationList);
  protected
    procedure Execute; override;
  private
    pgnCS        : TCriticalSection;

    debug        : Boolean;
    canceled     : Boolean;
    pgn          : TPGN;

    engines      : Array[WHITE..BLACK] of TEngine;
    gameStatus   : EGAME_STATUS;
    engineStatus : Array[WHITE..BLACK] of EENGINE_STATUS;

    event, site  : String;
    round        : String;
    clock        : TChessClock;
    adjudicationRules : TAdjudicationRules;
    openingMoves : TMoveList;

  end;

[Steve Maughan]

Thanks Thomas - this is also helpful.

Why does TGame need to be a separate thread? Is this just for engine communications?

Cheers - Steve

[tpetzke]

Why does TGame need to be a separate thread? Is this just for engine communications?

It doesn't have to, but for me it was the easiest way to keep the GUI responsive while a game is running eg. to allow the user to cancel it.

Thomas...

[hgm]

In any case, make as few assumptions on the game as possible, e.g. avoid hard-coding the number of board files and ranks when using them in tests and loops, and avoid assuming the board is square. It doesn't take any extra effort to keep it general, but it would b a hell of a job to change anything if it was not set up in a general way.

[kbhearn]

to me it'd make sense to have the 'game' object modeled to parallel the features of pgn since writing/reading pgn is something you'll want eventually (and is even a good first function to write of the gui possibly (after of course a visible board)). After that i'd want a navigation object for said game object that allows one to move around the game tree to query information about the current position of the game tree as well as adding/deleting moves/subvariations - probably the simplest structure for it is for it to have a board and a pointer/offset to the location in your game object that the position on that board represents. the arbiter can then simply use said navigation object as the interface to run the game from and after it's over your game object can dump it into a pgn file for you.