Chess960 move validation code?

[johnstewart]

Hi there. I'm working on a Chess960 multiplayer app for iOS (iPhone, iPad...).

My plan is to just do multiplayer (no computer opponent), though I may add that later.

I'm trying to find some code that can validate moves that the humans make to ensure they're valid Chess960 moves. Ideally, the code would be something I can easily drop into Objective-C, so any C or C++ code should work fine.

This seems like something that is likely to have been done (and redone) many times over, but I'm so far not having much luck finding anything.

If anyone can point me to some I could use, I'd much appreciate it.

[johnstewart]

It seems like I could use a Chess960 engine of some sort, if I can just call a method to validate a move.

Thinking about that option, can anyone recommend an engine that is written in C? I don't care about the playing strength in the least.

[Jeremy Bernstein]

It seems like I could use a Chess960 engine of some sort, if I can just call a method to validate a move.

Thinking about that option, can anyone recommend an engine that is written in C? I don't care about the playing strength in the least.

Valid Chess960 moves are no different than valid chess moves, except for the castling rules. The algorithms for simple move validation are pretty simple, too: http://weblogs.asp.net/justin_rogers/ar ... 42699.aspx, http://www.chessbin.com/post/Chess-Piec ... Moves.aspx are a couple of places to get some tips. Chess960 castling is reasonably straightforward, so adapting these algorithms for 960 shouldn't be too hard.

I was writing a UCI host in C a while back and thought about using an engine for this, too -- however, many engines simply crash given invalid input -- you need to validate the input before giving it to the engine, so you've got a chicken/egg problem. I ended up writing my own rudimentary move validation for normal chess and got good results. It'll take you an evening.

Jeremy

[johnstewart]

Roger; thanks. Ya, it's probably not rocket science, just trying not to re-invent the wheel.

As far as Chess960 versus regular chess, given the standard start position (SP518 - http://www.mark-weeks.com/cfaa/chess960/c960strt.htm) - I think the rules are exactly the same, right? Castling in SP518 would be identical to classic chess?

thanks!

[Jeremy Bernstein]

Roger; thanks. Ya, it's probably not rocket science, just trying not to re-invent the wheel.

As far as Chess960 versus regular chess, given the standard start position (SP518 - http://www.mark-weeks.com/cfaa/chess960/c960strt.htm) - I think the rules are exactly the same, right? Castling in SP518 would be identical to classic chess?

thanks!

Look here: http://en.wikipedia.org/wiki/Chess960#R ... r_castling. The post-castling positions are exactly the same as in standard chess. The only thing you need to be concerned about is the heuristic

if (!KingMoved && !RookOnTheSideICareAboutMoved && !AnyPiecesBetweenTheKingAndRook && !KingIsInCheck && !SquaresBetweenTheKingAndRookAreAttacked)

jb

[johnstewart]

Right; thanks!

And likewise, a couple of things which can only be known with the previous move(s)... like en passant, as edge cases.

[Jeremy Bernstein]

Right; thanks!

And likewise, a couple of things which can only be known with the previous move(s)... like en passant, as edge cases.

Exactly.

If (PawnMoved) { if (PawnMoved2Spaces) EnPassantSquare = NewPawnSquare; else EnPassantSquare = 0; }
...
if (PawnMoveIsCapture && (CaptureSquareContainsEnemyPiece || (EnPassantSquare && SquareInFrontOfCaptureSquare == EnPassantSquare))) PerformCapture(); else Error("invalid move");

Or something like that.

[johnstewart]

Aye.

Well, doesn't sound too terribly hard, no. Will be nice to have code I understand, too. =)

[2097]

!SquaresBetweenTheKingAndRookAreAttacked

This is incorrect.
It’s the squares between the king and the king’s target square that must be unattacked. Not all the squares between the king and the rook.

So check for these three things:

The king and rook involved can’t have moved.

There can’t be any pieces between them.

And the king can’t start on, travel through or end up on an attacked square. (The rook can!)

With 960 rules (I prefer these), the king will end up on C or G.
With the “480” rules variant, the rook moves up to the king and the king jumps over the rook (but in practice the king moves first, or move both pieces together, to avoid making it look like a regular rook move).

Either version will, when seeded with the 518 position, become “regular” chess.
I think the 480 variant is much easier to explain and understand, but the 960 rules make for the better game and is worth the extra effort.

[Jeremy Bernstein]

Yeah, sorry. I was just pseudo-coding and not worrying about accuracy.

jb

!SquaresBetweenTheKingAndRookAreAttacked

This is incorrect.
It’s the squares between the king and the king’s target square that must be unattacked. Not all the squares between the king and the rook.

So check for these three things:

The king and rook involved can’t have moved.

There can’t be any pieces between them.

And the king can’t start on, travel through or end up on an attacked square. (The rook can!)

With 960 rules (I prefer these), the king will end up on C or G.
With the “480” rules variant, the rook moves up to the king and the king jumps over the rook (but in practice the king moves first, or move both pieces together, to avoid making it look like a regular rook move).

Either version will, when seeded with the 518 position, become “regular” chess.
I think the 480 variant is much easier to explain and understand, but the 960 rules make for the better game and is worth the extra effort.