Could someone make me a Chess game with no AI if I paid them?

Oh, this must be a bad bug in WinBoard. I noticed this once too, but could not reproduce it then. I will work on it.

p2p is a bit experimental, and the relay server even more. It was intended exactly for purposes like this, playing games for which no servers existed. (I was interested in the large Shogi variants.)

But it seems to work, and the new configurability of WB 4.8 makes it very easy to define your own game, as you have seen.

Anyway, got to quit now, because I still have lots of things to to today. Everything seems to work now, so try to get your friend to install the stuff (just zip what you have, and send it to him). If any problems crop up, let me know. I am sure that thorough testing will reveal things that could be improved.

[Edit] I did not get any messages, but as soon as the text on your button changes, it becomes hopeless. I pushed my King's Pawn 3 squares as black, but never saw a reply move to that.

See you tomorrow!

Thanks a lot. I need to get myself to bed. Curious what is the bug you are referring to? Me seeing you move once or you not getting my messages?

I did give one of my friends the game two days ago. I just need to update his P2P from 3.0 to 5.0(or is it 0.5) On that note I checked a web page you had up for P2P. It still has the a older version on it.

http://hgm.nubati.net/p2p.html

http://www.chess2u.com/t7415-peer-to-peer-chess-engines

EDIT: yeah I move anouther pawn.

See you tomorrow. Enjoy your day!

By the way, last night as I was thinking about all this, I thought of two more relatively easy ways for people to play on mutually visible boards over the Internet without the need for client/server, p2p, or databases. Again, please keep me in mind if you want to do enhancements or alternative approaches.

Well, without a dedicated client that has to be downloaded you would have to use the internet browser as client. I tried to develop a system for that too, but it was more intended to be turn-based than live. An example that actially has been used for Seirawan Chess is at http://hgm.nubati.net/schess/play.html.

It is based on a JavaScript-driven html page, which uploads moves to a CGI program at the same server that hosts the page. The CGI program keeps a list of registered persons, and a list of games, and the actual game files, and sends those to the browser client on the proper request, where the JavaScript then displays it (or starts auto-stepping sthrough the moves, if you requested a game). The CGI program also mediated a chat.

It is not working now, because they upgraded the server to 64-bit, and the CGI program is a 32-bit binary. So I should recompile it, but I forgot where I have the source. (It is not on the server machine.)

The problem with this design is that you have to create a new html page, and supply new piece graphics, if you want to use it for a game with another board format, and other unorthodox pieces. And it was also requested that the page would have rule-awareness and would indicate moves of the clicked piece, so you would have to add that functionality to the JavaScript. And as this is likely to be a lot of game-specific code, you would want to base the move generation on some table-driven algorithm, like WinBoard's Betza interpreter, so that it ca be easily adapted to new variants.

Even better, of course, would be when the user could enter the game rules himself, and the html board would be redesigned by the JavaScript based on those rules. Just have text entries where you can enter board height and width, a FEN for the initial position, and a list of Betza-encoded piece moves, press a button, and up pops a window with a GUI to play the game!

But I am still very far from realizing that dream...

The last paragraph sounds really nice Muller. I hope you get to that goal someday. That would be so user friendly. You could most likely sell it. More importantly, it would most likely sell.  If you remake a winboard substitute. Ether way you would make a lot a variant lovers very happy!

I have actually longed for such a program that if you defined parameters, using ordinary writing, then it would code you such a program to perform the defined actions. Of course I doubt most computer programmers would have any vested interest in writing such a contraption, since it would all but, put them out of a job...

From what I understand (of what I admittedly only briefly read) about the problems the OP was having with moving pieces, one basic problem is that piece movement can be arbitrarily complicated, especially if there are promotion, en passant type captures, castling, initial 2-square jumps, etc. In chess the basic piece movements fall into simple categories: sliding and jumping, but with more pieces there is a chance of really weird piece motions, like leaping followed by sliding. It sounds like WinBoard's language deals with that in a passable way for chess by a sequence of letters that defines which elementary action follows which elementary action, but even that general capability fell somewhat short for the OP's game. I'd love to design and program such things but I just don't have the time to do it for free. Maybe somebody already has written such a program, but I just don't know about it.

I am interested in either a few data compiling programs or one bigger one to completely automate a series of processes. Everytime I mention to any programmer I run into, either they get quiet or it isn't their area of expertise...

My area of expertise is artificial intelligence, so I suspect I could do it. Maybe you could start another thread on your idea. Just last night I came up with another great idea for an online program for practicing chess visualization, but I'm not sure I want to give out my ideas in case there is money in them. But if somebody wants to pay me for it so they can post it online for free, that's OK with me. Maybe I can describe it in general terms in a different thread, but it wouldn't be nearly as interesting without mentioning some of the details of my ideas of how to measure visualization ability, and how I broke that down into different attributes.

For chess like games. Winboard is a very powrful editor it would seem.

Muller winboard does some odd stuff to the lion icon if used. No matter if I use the odd basic KGH code or the more complex one I made. So I think it is linked to the icon itself(took me a bit of testing to find the cause). It would seem that the lion can not be taken if he is more then a King move away. As well as he must be guarded by at least one piece. If those conditions apply then he can not be captured by the piece trying too. It sometimes doesn't seem to apply always, just most of the time. It only happens if the lion icon is used. It always happens vs two lions.

Do you know what might cause this? It can be game wreaking if I don't know the true cause. If I add it to the rules. It's fine. I just need to know why it happens, for sure. I kind of like it. To be honest. I just don't get it.

Lastly if you can find the cause. Will the code that makes him untakeable. While he would normally would be takeable. Be able to be used, on my star, to give it the same properties? Just more the way I wanted them.

I noticed the lion bug a while back. Just I couldn't find a cause. Till I made it move differently.

I have a similar set of reservations about my own ideas. I am concerned about it being stolen and used by individuals, be it programmers, website owners, cheaters,etc.

I darned sure don't want to make anyone else, rich(er) unless it is me.

 The parts of the compilation are analyzing chess games with an engine and GUI, so that the results are automated, with the numbers compiled into stats and metrics. It isn't simply determining the computer evaluation of the moves. The evaluations are put into an algorithm, to determine the difficulty of each position. I call it move difficulty metrics.

 The system deals with two sets of intergers, one starting at zero, potentially fluctuating back and forth until reaching a particular value and then changing to a different set that was starting at a value and working back to zero, while also potentially fluctuating back and forth. I had to figure out how to make the values from each set, reflect a seperately derived, consistant value , calculated from them, when one set was changing to the other, perhaps even back and forth, during the calcuations of the process. I realize that it might not make much sense at the moment but, for me it is like a trade secret.

EX. 0,1,2,3,X changing from X-3,2,1,0....potentially varying in value within a set and going back and forth from set to set....

The purpose of them is an alternative to current cheat detection methods. The beauty of it is that there are a set of other benefits too. One being the system will determine the inherent, absolute and static value, of the difficulty of chess positions, whether in games or puzzles. It would put an end to many of the Tactic Trainer nightmares. It also can be used to show a mind numbing number of different player and game stats, that currently aren't offered. This could really help to shed light on your tactical strengths and weaknesses, far better than the current trainer.

Also, the system can be used to give an intrinsic rating to your play. Current rating systems are an estimate and also use further estimates to try to give greater accuracy, to the validity of them !?!? Imagine being rated more for you good play instead of one mistake that costs you a game. Are you really as bad as your worst blunder, or more closely to the ELO of your average moves ?

One part of me would like to sell it, another part of me would simply like to see it implimented, so that all chess players can enjoy the closest thing to completely fair play that one could get, online. I don't really want to see some diluted version of my idea passed of as, what I had in mind and I certainly wouldn't want cheats sitting around trying to figure out how to best combat my ideas, for how to better catch them. The intention of it was originally to catch the subtle cheaters that intentionally, using various methods, seek to foil current detection methods.

WinBoard uses a method of encoding Chess moves known as "Betza's funny notation", with a simple extension to indicate multi-leg moves. There are more elaborate extensions of this notation (in particular Betza 2.0, designed by myself) that are immensely powerful. When fully implemented, they would allow description of the weirdest moves and capture modes (e.g. as in Ultima, where you can capture by approaching a piece or moving radially away from it, or sandwiching it between two pieces like in Tafl games) and moves with other side effects (e.g. 'Magnetic pieces') or conditional moves (such as in Knight-Relay Chess, where pieces protected by a Knight acquire a Knight move, or Chameleon pieces that capture like the piece they capture).

This is done by describing the moves as multi-leg moves that visit all squares that the move affects, and having general 'operators' for changing the occupation of the squares they visit (like removing an enemy piece, or hopping over a friendly one, or picking something up to carry it along and unload it later). Normally these operators would only distinguish pieces by color (e.g. to capture it it must be an enemy), but Betza 2.0 defines the general concept of 'limiters', which are sets of pieces that can be suffixed to any operator to restrict its applicability. So c{K,Q} prefixed to a move step would indicate that move can only capture King or Queen. Which is the sort of thing that we could not do now for the originally proposed variant.

Of course there will always be things that you cannot do, but for now the main problem is that WinBoard has not yet implemented the complete Betza 2.0 system. In fact the Betza decoder it has now was just piggybacked on an existing system, where it is used to replace WinBoard's native move generator used for legality testing, for re-defined pieces. But it doesn't affect WinBoard's internal move encoding yet, or the part of the code that executes these internally coded moves. So you are still limited to specifying moves that can be handled by the original system, even if the Betza notation could specify more complex stuff. I suppose that WinBoard's internal handling of moves will eventually be re-written so that it can also handle more complex moves (like triple capture, or moves that displace other pieces). Very few Chess variants need such complicated moves, however.

I am not too far away from a system that could be completely configured by Betza notation. The default AI plugin for WinBoard, the Fairy-Max engine, currently has to be configured by writing lists of (boardStep, moveRights) combinations for each individual direction it can move in. I am thinking of equipping it with a 'Betza compiler', to generate this list internally from the Betza encoding of the moves in the configuration file. The latter already contains the Betza encodings now, for sending them to the GUI without knowing what they mean, but then this would be the only thing it had to contain, and the combersome current move specifications could be completely removed.

This could be a remnant of some hardcoded exception rules. The Lion was added for Chu Shogi (and its stripped-down derivative Mighty Lion Chess), which has the special rule that a Lion cannot capture a protected Lion from a distance, and that you cannot capture a Lion in the turn following one where a Lion was captured by another piece. (Basically forbidding Lion-for-Lion trades.)

I guess the only way to avoid it is not use the Lion. As it is not possible to specify such a complex anti-trading rule in the Betza notation, it seems good to keep it hardcoded on one of WinBoard pieces, even when its moves would be customized by the user. This makes it possible to use this rule in other variants, for pieces that move differently. (This is especially useful in variants that are FIDE + one exotic piece, such as Mighty Lion, to prevent those frm quickly degenerating into an ordinary FIDE game by trading the single exo-Piece. FIDE with anti-Queen-trading rules would in itself already be a very interesting variant.)

So I think it is a good design that WinBoard has some pieces that have hard-coded intrinsic special properties (such as Pawns & Lances that promote and create e.p. rights, Kings that cannot be left in check, and Lions that cannot be traded). If you need a piece with those properties, you can then pick those WInBoard symbols to represent them. If not, just pick another one. There are enough others to pick from.

So piece assignments should primarily be made on the basis of what properties you want the piece to have, not on how it looks. How the pieces look can be tailored independently, by specifying piece bitmaps in the View -> Board Themes dialog, (or a piece font to get scalable pieces). This would be especially easy if you just want pieces to look like other, already existing WinBoard pieces. E.g. if you want the piece WinBoard considers an Elephant to look like the WinBoard Lion, you could just take the bitmaps from the WinBoard source code distribution, and rename the Lion image ln49o.bmp to q49o.bmp, etc., and then specify that folder as piece-image directory.

"and that you cannot capture a Lion in the turn following one where a Lion was captured by another piece."

What do you mean by that Muller? I don't understand. Can you word that differently. I get the lion vs lion. I don't get why it affects other pieces.  Trying to attack the lion, sometimes. Even when both lions are on the board. Also the lions can seem to attack each other up close always. I'd have to test again to make sure. I like the feature. I just need to understand it better.

The Betza 2.0 you talk about. Sounds sweet. It could make my star work how I want. Wish the current winboard could handle it. On that note, I thought they were made just for winboard. Like the P2P you made. (I assume that is too). Was it just made in hope that winboard would be updated to handle it.

Just curious, how much work would it be to make the winboard handle the new Betza notations?

http://play.chessvariants.org/pbm/play.php?submit=Edit

Apparently this site gives the ability to create your own chess variants...

Suppose white attacks the black Lion with a Rook. In reply, black counter-attacks the white Lion with a Bishop. Now white captures R x Ln. Then black is NOT allowed to capture B x Ln. The capture R x Ln by white has made its own Lion unassailable for one turn. So it is not possible to trade Lions by making a counter attack; threatening the white Lion with the Bishop really doesn't attack the Lion at all when white plays R x Ln. (Which he of course will.) If he would play any other move, not capturing the black Lion, then the Bishop could play B x Ln (and it would be white that could not retaliate with R x Ln).

As to Betza 2.0: some aspects would be relatively easy to add. The current Betza parser was added in a hurry, because I wanted it to be in the release of XBoard 4.8.0, for which we faced a deadline to get it in the next Debian release (which again will decide if it gets into the next Ubuntu Linux distro). In any case I wanted 4.8.0 to get into the next Debian release, because it is the only XBoard that supports Chu Shogi, and my Chu Shogi engine HaChu, which would already go into that Debian release, would not have an interface to use it without XBoard 4.8.

So I had very little time left to implement the Betza move generator in WinBoard after the idea occurred to me to do something like that. So I only implemented the minimum requirements needed to make all Fairy-Max' variants work that XBoard didn't completely support already. (These were Cylinder Chess, Berolina Chess, Great Shatranj, the Cambodian and Ai-Wok variants of Makruk, and all the flavors of Chess with Different Armies.) These already required some of the more specialized Betza modifiers, such as 'o' for cylinder moves, non-standard e.p. capture for the Berolina Pawns, and non-standard castling for some CwDA flavors.

I was also working on a new version of Fairy-Max to go into the next Debian, and one of the new features there was that it could handle moves of pieces that would split their moves just before they hit an obstacle, going past it at 45-degree angle, and I had used that in a variant 'Bifurcator Chess', where the Rooks and Bishops move that way. And then I conceived Team-Mate Chess because I had found a trick that would make Fair-Max able to perform KBNK-like checkmates, and this contained sliders that would turn a corner. To specify such moves to WinBoard I needed it to understand the Betza 'a' operator.

That was about all I had time for. The 'limiters' of Betza 2.0 would not be difficult to implement. It would be something in the move generator, used for testing if entered moves are legal, and highlighting all the legal moves on the board. Implementing general side effects, however, would require a much larger overhaul of WinBoard's code. Moves were originally stored as a from- and to-square, plus a promotion suffix. I already extended that (for the Lion hit-and-run captures of Chu Shogi) to allow one extra 'kill-square', a promotion suffix ';' indicating that one will follow. So a Lion move e4xe5-d6 would internally be stored as e4d6;e5 , indicating e5 should be cleared out as a side effect. This could be extended to multiple side-effect captures, allowing more squares to follow after the semicolon. But that would not yet enable moves with side effects that displace other pieces. I would have to design another format to encode these internally, and rewrite the code that updates the board with a given move to pay attention to that. I could for instance switch to a comma-separated list of moves, like e1g1,h1f1 do encode O-O, where the later moves possibly could displace opponent pieces. Unlike the limiters, this would take a lot of re-designing.

Interestingly, "difficulty metrics" are somewhat what my new idea of measuring visualizaton is about, also. For example, the presence of captures changes the difficulty of visualizing a position. I created a vector that lists the various attributes of difficulty I decided exist during visualization, and the user would be able to set these attributes before launching the practice tests. Changing any of those component values of level of difficulty be like changing the strength level of a computer chess program, except much more detailed and therefore much more flexible. Using linear regression, a player could evaluate his/her relative strengths, then work on the weakest values, if desired.

Your cheater detection idea sounds useful and good. Positional evaluation is very difficult for chess programs, although objective analysis of a position based on say average fanout of possibilities would be helpful for evaluating the difficulty of a position. I like your idea of using multivalue ratings. I should have thought of that, since my visualization metrics are essentially doing that. One insight I had, though, is that chess visualization is a different problem, a subproblem, of chess tactical evaluation: the latter requires storing nodes of a search tree where each node is the result of visualization of a single line, the former requires merely visualizing those single lines. In that way I tried to separate memory from visualization.

You can e-mail me or create a new thread if you want to discuss any of these ideas further. Another idea I had might have already been done: I would like to write a program that notes important or interesting attributes of a stored game, such as presence of tripled pawns, presence of underpromotion, presence of an early queen exchange at Q1 that forces the king to capture, etc., so that someone looking for examples of games with such attributes could do a search (as in a database) for all matches of a given attribute. You could just feed say PGN files into the program and generate a summary output for each game, stored in either a text file or database as output. The trick there would be that some attributes (such as a strong attack that backfired) are too subtle for programs to detect. AI just isn't there, yet.