Bored with orthodox Chess?

[Daniel Shawul]

That would be great! It will be a great visual support for those who don't want to write a GUI for yet another board game. Only problem I see with the "alien" variant is it can not judge when the two engines disagree on the state of the board and one of the engines is buggy.
For checkers pieces and Go stones I use the usual pawn with Pp in FEN, so it should be understandable as it is infact. I guess you have also a way to change board size to anything you want from your experience with chess variants. I really don't see other reasons why this "neutral" mode can't work, and it will be of great support at least for development purposes.
Thanks

[Daniel Shawul]

Examples of FENs I have for different games shown below. Castling, status indicators are not used other than chess. And the other games don't seem to need additional information. The Go 'ko' square can be directly substituted with the enpassant square of chess..

#if defined CHESS
#define BOARDX 8
#define BOARDY 8
#define BOARDER 3
#define MAX_PIECE_TYPES 16
const int BOARDW = (2 * BOARDX);
const int BOARDWY = (BOARDW * BOARDY);
const int BOARD_OFFSET = (BOARDER * BOARDW);
const int BOARD_SIZE = (BOARDWY + 2 * BOARD_OFFSET);
const int MAX_CHAIN = 1;
//const char start_fen[] = "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1";
const char start_fen[] = "LGkCCkWL/HHHHHHHH/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1";
#elif defined CHECKERS
#define BOARDX 8
#define BOARDY 8
#define BOARDER 2
#define MAX_PIECE_TYPES 6
const int BOARDW = (BOARDX + 4);
const int BOARDWY = (BOARDW * BOARDY);
const int BOARD_OFFSET = (BOARDER * BOARDW);
const int BOARD_SIZE = (BOARDWY + 2 * BOARD_OFFSET);
const int MAX_CHAIN = 12;
const char start_fen[] = "1p1p1p1p/p1p1p1p1/1p1p1p1p/8/8/P1P1P1P1/1P1P1P1P/P1P1P1P1 b - - 0 1";
#elif defined OTHELLO
#define BOARDX 8
#define BOARDY 8
#define BOARDER 1
#define MAX_PIECE_TYPES 4
const int BOARDW = (BOARDX + 2);
const int BOARDWY = (BOARDW * BOARDY);
const int BOARD_OFFSET = (BOARDER * BOARDW);
const int BOARD_SIZE = (BOARDWY + 2 * BOARD_OFFSET);
const int MAX_CHAIN = (8 * (BOARDX - 3));
const char start_fen[] = "8/8/8/3Pp3/3pP3/8/8/8 b - - 0 1";
#elif defined GO
#define BOARDX 9
#define BOARDY 9
#define BOARDER 1
#define MAX_PIECE_TYPES 4
const int BOARDW = (BOARDX + 2);
const int BOARDWY = (BOARDW * BOARDY);
const int BOARD_OFFSET = (BOARDER * BOARDW);
const int BOARD_SIZE = (BOARDWY + 2 * BOARD_OFFSET);
const int MAX_CHAIN = (BOARDWY);
const char start_fen[] = "9/9/9/9/9/9/9/9/9 w - - 0 1";
#endif

const char piece_name[] = ".*PHKkQWRGBLNC";
//const char piece_name[] = ".*PpKkQqRrBbNn";
const char col_name[] = "WwBb";
const char cas_name[] = "KQkq";

enum colors {
white,black,neutral
};
enum occupancy {
empty,sink,
wpawn,bpawn,
wking,bking,
wqueen,bqueen,
wrook,brook,
wbishop,bbishop,
wknight,bknight,
};

[hgm]

Well, try the new http://hgm.nubati.net/WinBoard-4.5.beta.zip then!

This supports -variant alien (only as command-line argument; no menu entry yet), and will obey setup commands from the engine at any time, when not in ICS mode. (Untested!) The syntax is

setup (PIECETOCHARTABLE) FEN

or

setup FEN

where PIECETOCHARTABLE has the format of the (string) argument of the WB /pieceToCharTable option, and FEN is any FEN. Only the board part of the FEN is interpreted.

The arguments -boardWidth and -boardHeight can be used to specify a board size. (This can be done from the New Variant menu dialog.) But sizes larger than 14x10 will require a recompile.

[Daniel Shawul]

Wow,thanks a lot! I haven't even implemented Winboard protocol for Nebiyu yet Guess it is time to rush into that now!
People watch out! Winboard has said "This is Sparta!!" already and now went to alien land ...

[hgm]

ChessV seems significantly improved. It scored 46% against Oberon now, previous version only 26%. There was only one game where it lost on time, but it was due to an illegal move of Oberon, that promoted to a third King. (I have not installed the WB version that tests for this on that computer yet.)

[Daniel Shawul]

HG, please find Nebiyu beta in your inbox. Finally managed to have a working version before my birthday (1/11/11) is over

[hgm]

Well, double congratulations, then! I will have a look at it.

Btw, I realized tonight that checkers will not work: the move there is not uniquely specified by from and to square. In multple captures you can have ambiguity about the trajectory. E.g. a triple capture with a Queen:

[d]Q7/1p3p2/8/5p2/6p1/8/8/8 w

a8-e8 (or should we write Qxxxe8? ) Will f5 or g4 disappear? More than just updating the display is required; the opponent must get this information as part of the move.

I guess we would have to cater for variants with multiple moves per turn. That would also solve the Amazons problem. Perhaps allow a 'continuation character' at the end of a move if there is more to follow, which suppresses changing stm.

[Daniel Shawul]

For checkers, the ambiguity is resolved by including an intermediate square in the move notation for.eg. a8xe4Xe7 . But we don't have to do that. The GUI accepts a FEN from the engines. The engine also accepts a FEN from the GUI. No moves are sent and received. If that is possible in winboard, it should allow for any kind of board game to be played

[hgm]

True, but it is a lot different from how WinBoard works now. And is hard to 'upgrade' to a fully supported variant.

I am leaning to the following idea: why not build some general multi-move capability into WinBoard, where each side can do multiple moves per turn. Some Chess variants have that. So I am thinking of adding a continuation suffix (the hyphen '-') to the move syntax. (For now only to long algebraic.) This suffix would suppress incrementing the move counter (and the side to move, which in WB is implied by it being odd or even), but otherwise the move would be applied normally to the board being built. The move parts of such partial moves would all be appended, and be sent as a single move to the opponent once the last part (without continuation suffix) gets in.

So in our checkers example, the engine would send:

move a8e4-
move e4g6-
move g6e8

at which point WB would send to the opponent:

move a8e4-e4g6-g6e8

This would transfer the essential information between engines, which would also have to be transferred if the GUI had been fully aware of the rules. Everything else sent by the engine (e.g. in setup commands) would be optional display information, that would never be tranmitted to the opponent. With legality testing on, the GUI would simply ignore it. The engine might even refrain from sending such stuff if the GUI had told it to play variant checkers, and reserve it for when playing variant alien with some engine-defined option set to "checkers". So there is an easy natural evolution from one method to the other.

Once we have that general mechanism, making the WB MakeMove "lightly aware" of the rules of some non-Chess games would not be such a big deal. It would be similar to the way MakeMove implements castling now: any sideway King move of 2 squares or more (except one edge file to the other) would swing the edge piece in the direction of which the King is moving around it. Whatever piece type it is, and no matter on which rank you are. That captures a lot of different Chess variants and castling types, without vriant-specific programming. (Not Chess960, though, which needs the KxR kludge.)

So what I could do, for instance, is add variants checkers, reversi, go, which really would be super-variants for checkers-like games, go-like games, etc. In these variants the characteristic side effects ofthe (partial) moves would automatically be applied. Just like in variant atomic the side effects of captures are performed:

checkers: the ray between from and to-square would be cleared
reversi: in the 4 orthogonal directions pieces between the to-square and the first piece of the stm would be color-flipped
go: any chain suffocated by the piece on the to-square would be removed

(I do't think the go part is very tough. A very simple recursive routine could do it.)

[Daniel Shawul]

If you have the time to do it, ofcourse it is best to make winboard aware
of the rules of the game being played somehow. As you said also , these games could be
super variants to many many variants of their own f.i checkers variants played on
differnt board sizes and differnt piece movements.

GO and reversi is also easy. My job was difficult because I was trying to incrementally
update the Go groups with much less effort as possible, and all of them in one linked list. If I had scanned the board everytime at the leaves
it would be very easy. There is no reason for the GUI to do it that way.
All it has to do is scan board and remove stones with no liberties.
So I agree it is indeed doable. Just let me know the modifications once you decide upon a workable
idea that is extensible. I will test it with Nebiyu whenever it is ready.
The FEN-switching-scheme was a lazy way out which wouldn't allow further modifications
as it is complitely ignorant of the rules.