Required custom viewer functionality?

[paulmelis]

Hi, first of all, thanks for such a great package! With the recent changes to get it running on Linux it's quite a good way to play Hive against an AI.

I was pondering making a custom viewer application, but it seems it would need to keep track of quite a few things that I so far had assumed would be available from the engine. In particular it seems a viewer ...

• needs to implicitly keep track of the board state, as it can't be requested from the engine, including piece positions and available pieces left to place for both sides
• suggesting legal move placement/destinations when selecting a piece in the viewer is done by filtering the results of validmoves, i.e. there's no command to get valid moves for a particular piece

Am I correct in these assumptions? They're not biggies to implement, but if they are available from the engine would save some coding.

Also, is there a canonical destination string to use when moving a piece in case it is moved next to multiple existing pieces? Or will any of the available ones work? For example, if moving a white piece to the left of a black queen that's above a black ant and the white pieces ending up touching both black pieces would both b/Q and b\A1 work as destinations?

[jonthysell]

Using the UHP, the viewer doesn't need to know how to play the game, only how to parse the game and move strings. After every command that changes the board state, (starting a new game, playing a move, undoing a move) the engine returns the current state of the game as a GameString. Yes, this means the Viewer needs to be able to parse this information and figure out what to display. A piece's position is relative to other pieces on an infinite board, so rather than assign absolute positions (and require all engines to adhere to the same coordinate system), and since the viewer also needs to know the move history anyway, it's more compact and less restrictive on engine designers to just return the move history with each relative move string.

A viewer will also need to know, based on the game type, what pieces are still in each players hands. As for moves, again the viewer asks the engine for the list of moves, and is then responsible for knowing what those moves would look like display-wise.

There is no canonical destination string as the BoardSpace notation is based on relative positions. An engine should be capable of accepting a given move string even if it's not a string match with what it said was the valid move.

[paulmelis]

After every command that changes the board state, (starting a new game, playing a move, undoing a move) the engine returns the current state of the game as a GameString.

Just to verify, it's not the actual game state being returned, but the sequence of moves so far in the game, right?