Daniel Shawul wrote:So to play in multi player mode the engine should always be in force mode when it gets a move, then explicitly told to 'go' afterwards after legality testing is done.
I don't see that. If there is a fixed order in which the players move, or it can be deduced from the moves who's turn it is next, it should still be possible to assign it a color, and have it play automatically when its color comes up.
If the players are red, green and blue, playing in that order, when all engines at startup by default think they are playing blue, you would have to tell some of them differently,of course. But that is not different in WB protocol for Chess, where both engines also start playing black, and the one you want to play white has to be told by a 'go' command. In this case you would start sending 'go' to the red player, then send the move it comes up with to green and blue, and then 'go' to green to have it produce its move. And from then on, only moves would suffice.
In any case, it would be nice if multi-leg moves could be entered by clicking on the intermediate squares only once. So for a e4c6, c6a4 capture, it would be nice just to click on e4c6a4.
I agree this would be nice, but it is also a bit of a problem. Because how is the GUI to know that the next leg will necessarily start with the same piece as the previous one? In Arimaa, for instance, this will not be the case. (And neither in Chess variants for non-standard castlings.)
This could be specified in a game specific variable. All draughts variants have this property.
Or better yet, just to click e4a4, and let the engine decide whether this is the only unique move. Or is this at odds with what is to be expected from an engine?
Well, this is a problem that led us to the complex multi-leg move entry in the first place. In general from- and to-square are not enough information to fully specify the move, in Draughts. There could be different paths between the same squares. Basically, what you ask is the equivalent of the /oneClickMove option in Chess, where a move is already done based on partial entry (either the from or the to square, if there is only a single legal move from or to it). In a general GUI completely devoid of game knowledge this might be asking a bit too much. Even in the very simpletwo-square case of Chess the usefulness of one-click moving is a controversial topic.
The CheckerBoard GUI http://www.fierz.ch/cbdeveloper.php is designed for 8x8 draughts, and as such knows the rules of the specific variant English/American checkers. However, to support other game rules that the GUI is unaware of, the engine can define a function
int WINAPI islegal(int board[8][8], int color, int from, int to, struct CBmove *move);
struct CBmove
{
int jumps; // number of jumps in this move
int newpiece; // moving piece after jump
int oldpiece; // moving piece before jump
struct coor from,to; // from,to squares of moving piece
struct coor path[12]; // intermediate squares to jump to
struct coor del[12]; // squares where men are removed
int delpiece[12]; // piece type which is removed
}
struct coor
{
int x;
int y;
}
If you combine this with a game specific flag that the game has multiple-leg captures (with the destination of the previous capture equal to the from square of the next one), then the user could simply click the capture sequence by single-crt-clicking the sequence. The GUI then simply has to marshall the click-sequence into the CBmove struct.
I read here in this forum just recently about a chess game being played by two different engines (of two different strength or style), playing a game against another engine. Would a (Rybka + Tscp) combo beat (Scorpio) ? This is multi-player games playing a normal chess. I can add other combinations and each time it will be different. This is the one I tested.
You can not depend on the order of play to make auto moves, so the engine should be in force mode and explicity told to go when the GUI says so.
In the real multi-player games like chineese checkers or three way chess, you pick one color and stick with it i.e RGB order you mentioned. In some multi player variants , one of the players can loose , at which point the game is stopped Or the other engines can fight it out to determine the winner. So the game will be reduced to two player etc.. So either we have to use the force mode, or update all engines to how many players are participating in the game currently.
P.S: where is the specification you mentioned in winboard forum
Here is a link to a new Nebiyu that I promised earlier. It is v1.4 and has many changes. The Alien version has experimental alien games such as crazyhouse which are not finished yet. I forgot what I have done since it has been some time.. Enjoy and let me know if the checkers input problem is fixed or not .
The CheckerBoard GUI http://www.fierz.ch/cbdeveloper.php is designed for 8x8 draughts, and as such knows the rules of the specific variant English/American checkers. However, to support other game rules that the GUI is unaware of, the engine can define a function
CheckerBoard and another old chess GUI written in OWL (forgot the name) was what motivated me to do chess.
I think checkerboard still has some problems in resolving multiple captures when i tried it recently. I setup a triple capture which can be made in two ways to two different squares and it just did one of them automatically.
Here is a link to a new Nebiyu that I promised earlier. It is v1.4 and has many changes. The Alien version has experimental alien games such as crazyhouse which are not finished yet. I forgot what I have done since it has been some time.. Enjoy and let me know if the checkers input problem is fixed or not .
Just tested it, but it still doesn't work! The exact same example and sequence I posted here earlies gives a crash of Nebiyu. This example was in Analysis Mode. During games against the engine, I had no problems entering captures (also not in the previous version).
The CheckerBoard GUI http://www.fierz.ch/cbdeveloper.php is designed for 8x8 draughts, and as such knows the rules of the specific variant English/American checkers. However, to support other game rules that the GUI is unaware of, the engine can define a function
CheckerBoard and another old chess GUI written in OWL (forgot the name) was what motivated me to do chess.
I think checkerboard still has some problems in resolving multiple captures when i tried it recently. I setup a triple capture which can be made in two ways to two different squares and it just did one of them automatically.
cheers
You are right! From http://www.fierz.ch/faq.php :
"CheckerBoard doesn't understand ambiguous captures and there is only one way out, which may not work though: Have the engine play your move for you - it will choose the better capture. Then continue to play normally."
Are you sure about that. I get correct behaviour here. First console mode
Winboard gui starts counting ranks from 0 so i input e5c7,c7a5 for console but in winboard it is e4c6,c6a4. My winboard version is 4.4.4.
I will test selection of the longest capture problem next.
Indeed the code for selecting the longest capture was effectively disabled while I was shuffling declartion of variables. Now it is fixed. In the following pos. it would have shown two captures before, but now only the longest capture is retained. thanks for the report.
I think I managed to transplant the alien branch onto the latest normal WinBoard version. The problem was that I have completely written the parser, and this had gone into the main branch much earlier than I thought it would, while I was developing the alien branch on the old parser. And the alien branch did require many changes in the parser. So I had to figure out which they were, and rewrite them in the context of the new parser.
But I think it works now. I have made a new branch, "aliennew", in my http://hgm.nubati.net XBoard repository. This also has a patch that should make it work (together with the new parser) for boards of more than 10 ranks. I also added the "single continuation click", by leaving the moved piece selected when Ctrl was pressed. I already had this for Amazons; I just removed an if-statement to apply it in all multi-move variants now.
I have no time to make a binary from it now, but if you are set up to compile WinBoard, you could try it from source. The XBoard version sort of worked. (Which is also new, because before the Ctrl key was not connected to the mouse driver.)
hgm wrote:I think I managed to transplant the alien branch onto the latest normal WinBoard version. The problem was that I have completely written the parser, and this had gone into the main branch much earlier than I thought it would, while I was developing the alien branch on the old parser. And the alien branch did require many changes in the parser. So I had to figure out which they were, and rewrite them in the context of the new parser.
But I think it works now. I have made a new branch, "aliennew", in my http://hgm.nubati.net XBoard repository. This also has a patch that should make it work (together with the new parser) for boards of more than 10 ranks. I also added the "single continuation click", by leaving the moved piece selected when Ctrl was pressed. I already had this for Amazons; I just removed an if-statement to apply it in all multi-move variants now.
I have no time to make a binary from it now, but if you are set up to compile WinBoard, you could try it from source. The XBoard version sort of worked. (Which is also new, because before the Ctrl key was not connected to the mouse driver.)
Hello H.G.,
This latest development actually addresses a question I had asked in the main forum about folding everything into the TM version so you know I am feeling as though I have a 0.00000000000001% stake in the creation of this all in one version.
Well, it is still not decided that the alien stuff should go into the next release. But the standard procedure is to keep such patches for future use in a fork of the development, and to keep it compatible with the current man line by sliding the forking point along the main line as the latter is extended. Problem here was that the alien side branch had got stuck, because it could not pass the introduction of the new parser in the main line. It had many changes and additions in code that did no longer exist in the main line (namely the parser.l file). So that code had to be re-written, and I was ust too busy with other stuff to do that upto now.
Some patches in the alien branch I will definitely incorporate into the main line, though, now that they are compatible again. This is the ability to do boards with more than 10 ranks (this was a very small patch, but so far completely untested), and the addition of variants Dark Chess and Grand Chess (because they are genuine Chess variants).
The Amazons, Checkers, Reversi, Go and Ultima stuff will probaby always be kept only as a fork, but this fork will incorporate any changes in the main line (such as in this case the tourney manager).
