TalkChess.com

I'm toying with the idea of writing a chess GUI. Does anyone have any suggestions for the object model / structure for a chess GUI? Are there any links wether this has been discussed?

Thanks, Steve

Steve Maughan wrote:I'm toying with the idea of writing a chess GUI. Does anyone have any suggestions for the object model / structure for a chess GUI? Are there any links wether this has been discussed?

Thanks, Steve

What language ? C or C++ ? Or maybe a high level language like Python ?
Which GUI Toolkit will you use ? Qt ? GTK ? other ?

Hi Lucas,

I'd write it in Delphi / Object Pascal, and use the VCL as the GUI framework.

After giving it a little thought it's not obvious as to what is the best way to construct the underlying structure.

I assume there would be a TGame object. This would hold the starting position and a list of moves (and variations) - or would a list off positions be better? I'm thinking you'd then have a TChessPlayer which can either be white, black or a kiblitzer. After each move the TGame object would relay the move to the TChessPlayers and TKiblitzers. That's about all the thinking I've done so far. It strikes me a being a little messy but doable. I just wondered if there were any better approaches, or any links which could clarify the details.

Thanks - Steve

Steve Maughan wrote:Hi Lucas,

I'd write it in Delphi / Object Pascal, and use the VCL as the GUI framework.

After giving it a little thought it's not obvious as to what is the best way to construct the underlying structure.

I assume there would be a TGame object. This would hold the starting position and a list of moves (and variations) - or would a list off positions be better? I'm thinking you'd then have a TChessPlayer which can either be white, black or a kiblitzer. After each move the TGame object would relay the move to the TChessPlayers and TKiblitzers. That's about all the thinking I've done so far. It strikes me a being a little messy but doable. I just wondered if there were any better approaches, or any links which could clarify the details.

Thanks - Steve

I think a chess GUI is much more than just a game object. It is more like an arbiter for a chess game between two players that allows various modes of game playing:
- engine vs. engine (with or without graphical display of the progressing game),
- engine vs. human,
- engine vs. remote player,
- human vs. remote player,
- human vs. human.
Time control is an integral part of a chess game.
Another mode is analysis with an engine, here the arbiter is almost silent, and there is only one player and no time control.
The arbiter needs the game object to follow the game itself. It reacts on events from the player(s) and sends messages to them.
Good luck with your project, as well as with your decision about the supported protocol(s): UCI, WB?

Hi Sven,

What you describe I'd call modes. For example, analysis mode has the board as both black and white, with an engine as a kiblitzer.

I'll implement UCI (which is my favorite), possibly winboard but only if its easy.

Steve

Perhaps start with dragging a piece. I still have problems with that for I use HTML5 dragging and I better use JavaScript. But that's about websites.

Mouse event handling might not be easy.

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.

hgm wrote: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.

Steve Maughan wrote:What you describe I'd call modes. For example, analysis mode has the board as both black and white, with an engine as a kiblitzer.

Well, how did I call it?

Since you asked about object modelling, I think it is important to make a difference between the "arbiter" and the two players (or only one in case of analysis). These have very different roles. For a chess GUI the players are "external" entities but nevertheless you need to represent them somehow since you maintain two independent connections to them for exchanging messages. Also a clean distinction between the "internal" objects and the (graphical) user interface is crucial.

As to modelling of the game itself, I think it does not matter much how you choose to represent the game internally: starting position + moves or list of positions or anything else. Most important is what needs to be done with a game object. Define its interface, e.g.:
- set up an arbitrary position by FEN,
- make a move,
- unmake the previous move,
- check a given move for legality,
- retrieve FEN of current position,
- ...
That is also independent of the playing mode.

Also I would define the interface of the chess clock object and of the arbiter object.

That is a totally unsound conclusion.