Looking for C developper

[Greg Strong]

I'm going to explore some unexplored chess variants

I hope you're serious

I've found working on "universal" chess engines to be a lot of fun, although focusing on a particular obscure variant would also be interesting but in a very different way...

[Greg Strong]

What I'd really like to see is an engine for Marseillais Chess. Basically, after white's first move, each player makes two turns in a row. He can move the same piece twice or two different pieces. This makes a fast, exciting game and nicely eliminates white's first-move advantage. How exactly to do a quiescent search in this game, if at all, is an interesting question... As far as I know, the only program that can play it is Zillions-of-Games.

Other nuances:

- if you place the opponent's king in check with your first move, you don't get a second
- if in check you must move out with your first move. you can't move into check ever, not even moving in with your first move and out again with your second.
- if your opponent moved a pawn two spaces with either his first or second move, you can only take it en passant with your first. an exception is if he made two two-space pawn moves; then you can take both en passant with your two moves

[Sven]

What I'd really like to see is an engine for Marseillais Chess.
...
- if your opponent moved a pawn two spaces with either his first or second move, you can only take it en passant with your first.

Found this on chessvariants.org:

According to Pritchard's Popular Chess Variants, 'The en passant rule has seen change. Modern players allow it only when the Pawn advance formed the second move of a turn.'. This helps to eliminate some ambiguity discussed in the comments. (What if a player advanced a Pawn by two squares, then occupied the intermediate square with a piece?)

So the exact en passant rules should be settled prior to writing a Marseillais Chess engine.

Sven

[hgm]

What I'd really like to see is an engine for Marseillais Chess. Basically, after white's first move, each player makes two turns in a row. He can move the same piece twice or two different pieces. This makes a fast, exciting game and nicely eliminates white's first-move advantage. How exactly to do a quiescent search in this game, if at all, is an interesting question... As far as I know, the only program that can play it is Zillions-of-Games.

Other nuances:

- if you place the opponent's king in check with your first move, you don't get a second
- if in check you must move out with your first move. you can't move into check ever, not even moving in with your first move and out again with your second.
- if your opponent moved a pawn two spaces with either his first or second move, you can only take it en passant with your first. an exception is if he made two two-space pawn moves; then you can take both en passant with your two moves

I wonder if it would be sufficient to use a normal search for this with the small modification that stm would cycle through 4 stages.

Some time ago I have been thinking a bit about how I could implement two moves per turn in Fairy-Max, mainly because I would like it to be able to handle the Chu-Shogi Lion. But in a sense Marseillaise Chess is simpler, as there aren't any restrictions on the second move (while with a Lion you would only be allowed to do a second step with that same Lion). I guess the checking rules of Marseillaise Chess can be implement in a relatively straightforward search. A first step would be illegal if the null move in the second step would be illegal (so immediately return -INF if the null move returns -INF). And King capture during the second step should return -INF rather than +INF (as it would in the first step). That is basically all. With Sven's e.p. rule this would work automatically. (Or perhaps it would need to surpress e.p. capture in a second step, to prevent it from e.p. capturing its own Pawns.)

The main problem is in the root: somehow you would also have to print and execute the move chosen at ply 2.

[Greg Strong]

What I'd really like to see is an engine for Marseillais Chess. Basically, after white's first move, each player makes two turns in a row. He can move the same piece twice or two different pieces. This makes a fast, exciting game and nicely eliminates white's first-move advantage. How exactly to do a quiescent search in this game, if at all, is an interesting question... As far as I know, the only program that can play it is Zillions-of-Games.

Other nuances:

- if you place the opponent's king in check with your first move, you don't get a second
- if in check you must move out with your first move. you can't move into check ever, not even moving in with your first move and out again with your second.
- if your opponent moved a pawn two spaces with either his first or second move, you can only take it en passant with your first. an exception is if he made two two-space pawn moves; then you can take both en passant with your two moves

I wonder if it would be sufficient to use a normal search for this with the small modification that stm would cycle through 4 stages.

Some time ago I have been thinking a bit about how I could implement two moves per turn in Fairy-Max, mainly because I would like it to be able to handle the Chu-Shogi Lion. But in a sense Marseillaise Chess is simpler, as there aren't any restrictions on the second move (while with a Lion you would only be allowed to do a second step with that same Lion). I guess the checking rules of Marseillaise Chess can be implement in a relatively straightforward search. A first step would be illegal if the null move in the second step would be illegal (so immediately return -INF if the null move returns -INF). And King capture during the second step should return -INF rather than +INF (as it would in the first step). That is basically all. With Sven's e.p. rule this would work automatically. (Or perhaps it would need to surpress e.p. capture in a second step, to prevent it from e.p. capturing its own Pawns.)

The main problem is in the root: somehow you would also have to print and execute the move chosen at ply 2.

Interesting... I'm not sure simply having a King capture in the second step return -INF will do it. What if the player's only legal move puts the opponent in check? Or the only move that isn't really, really bad? Putting the opponent in check on the first move shouldn't be considered so bad it's "game over" bad. And it has to be doable, in which case the player's second move is skipped. So I don't think it's a simple as side-to-move stepping through a simple 4-stage cycle. That said, what you propose, although not perfect, would still probably work pretty well... (I don't know what you mean by Sven's ep rule, but it seems there would be some special-casing here too.)

[carldaman]

I'm starting to be bored of developing DiscoCheck:

• As with any advanced program, I only use my brain only 1% of the time, and the remaining 99% I use time and electricity...

I share the sentiment, nowadays development (although responsible for hundreds of elo) is boring indeed.

An alternative is the old (romantic) approach, to improve via hundreds of selected positions your engine performs weak (usually because of missing eval knowledge). Using the strategic testset from Swamithan would be a good starting point.

But it will cost you elo points.

Maybe losing Elo points isn't the worst possible thing. We need more developers primarily interested in an engine's style. Elo can be secondary.

The strategic test set is a great idea. Or run the program on ICC against strong humans, instead of a gazillion engine-engine games. Quality over quantity, mind over matter...

Cheers,
CL

[carldaman]

There is still a lot to do with standard chess, at least from a chess player's point of view. Better handling of closed positions f.i., of course by gaining, not by losing ELO. Engines that are able to teach chess on a high level, engines that are able to explain why a particular move or plan is the best one, in a way a human master is able to understand and learn from the machine. Highly optimized engines like SF still make stupid errors. The gap between playing extremely strong in most and playing extremely stupid in a few positions is still there and it's annoying because it means chess engines are not yet reliable references despite being extremely strong in practical play against human that do not know how to exploit their weaknesses.

Whether Elo is gained or lost by improving play in closed positions depends on who the opposition is, doesn't it?

Only human players will care about and benefit from improved play in closed positions. Such an engine may well score better against humans than ever before. Losing Elo against other engines can be largely irrelevant in this context (although I'd agree that no Elo loss would still be preferred), as long as the human end users get a more well-rounded and realistic analysis and sparring partner.

To a sensible human, having a 2800-rated program that plays well in nearly all positions is at least as good as, if not preferable to, having a 3200-rated engine that struggles in closed positions.

It is a trade-off worth having. If I want the highest engine-engine Elo, I can always switch on the latest Stockfish...

Regards,
CL


PS. Of late, SF has been playing better in closed positions as well

[carldaman]

The reason I started an open source project, is to build something bigger than myself. Something that will outlive me in the sense that other people will continue to develop it when I am bored of chess programming. So far, I have not seen anyone show interest in DiscoCheck's source code (apart from a few trolls looking for something there to wage a clone war). No one has ever forked my project on github or sent me a pull request. Basically no one cares about DiscoCheck, except myself, and those people (chess fans) I least want involved.

Discocheck is not a failure at all. I certainly have waded through your commits looking for ideas to try myself ...

Jerry

Even from a non-programmer point of view, a 2900+ single-core engine shouldn't ever be considered a failure (not even in 2014...)

Well done, Lucas! Thanks for sharing Disco with us!

Regards,
CL

[hgm]

Interesting... I'm not sure simply having a King capture in the second step return -INF will do it.

You are right. King capture in the second half-turn should not return -INF, but the null-move score.

The question, however, is how to reduce the null move. After a null move in the first half-turn you would certainly want to reduce the second half-turn away, i.e. increase the turn variable by 2. It is coneivable that you are facing a threat that would make this null-move fail low, but which you could solve in your first half-turn. Null-moving in your second step then might still deserve a reduction, but probably a lower one than on a null move that failed high in the first half-turn. When the first half-turn would check (i.e. King capture in the second half-turn) the null move you are forced to play in that second half-turn should not be reduced at all.

A ply is really a quarter-move in this game, and it seems reasonable to iterate, extend and reduce the depth in pairs of ply. A scheme where you would reduce the null move on the first half-turn by 4 ply (in addition to consuming your own two ply), but not reduce a null move in the second half-turn (so you could return its score when you discover King-capture later) might be workable.

[Evert]

Whether Elo is gained or lost by improving play in closed positions depends on who the opposition is, doesn't it?

Only human players will care about and benefit from improved play in closed positions. Such an engine may well score better against humans than ever before. Losing Elo against other engines can be largely irrelevant in this context (although I'd agree that no Elo loss would still be preferred), as long as the human end users get a more well-rounded and realistic analysis and sparring partner.

If you manage to write an engine that can avoid anti-computer chess when playing against a human, it can probably exploit it against another computer.

That would be an interesting project. Difficult, but interesting.