ID:79065
 
Keywords: bgc, chess, development
Focus shifted from presentation elements to the king's involvement in gameplay today. It goes without saying that the entire focus of a chess game is the royal piece (the king in orthodox chess), but that also makes it a royal pain in the wazoo.

I created a tile-based "threat" system that was ostensibly detached from the actual pieces' movements; while the pieces contain a list of the turfs they're able to move to legally, each turf contains a list of pieces that would threaten a royal piece at its' location. This ends up working slightly slightly better than the last iteration, where each individual piece held a list of its' legal movements and of the tiles it threatened, so ascertaining the threats to a royal piece involved a loop through every enemy piece on the board. This time, the turf holds a list of threats, and can easily be consulted at the time of the king's movement collections.

Here, we have a black king minding his own business with his full legal movement set.


Oh noes! An evil white queen appears!


And the king loses a lot of his movement squares.

Now somehow, between inevitable bugs and setbacks, this seemingly simple system took most of the day to concoct, test, refine, and deploy. Keep in mind that the only part of the entire display that actually resides on the map are the white and black squares, though I'm not entirely pleased that I spent a whole day on this. Tomorrow I'll have to get to work on imposition and pinning, and beyond that, I don't see too much more that has to be done. I think after the royal considerations are finished, all that's lacking is the process of generating and exporting game movement logs to the Tibbius server.

Day five starting from a blank DM window and I'm almost finished. Scary and sad at the same time.
What are your intentions for castling, pawn promotions, and en passant?
I already got him to fix those in the first rendition of his Chess game. It was extremely buggy back then. ;)
Vermolius wrote:
What are your intentions for castling, pawn promotions, and en passant?

Those are all things residing in the current incarnation of the game, and they will return to this version. Apparently most people don't even expect a chess game to have considerations for castling or en passant, judging by surprised responses I received when making the previous version.

Pawn promotions should be fairly easy; once it reaches the proper rank (eighth for white, first for black) prompt for a piece to promote it to. Since chess rules state you have to choose a piece before the next turn starts, I could just hang up the entire game with an input(). En passant is a little trickier to manage, but I believe I could just drop a var on the pawn that states how many tiles it moved on its' last turn. If a pawn has an enemy pawn beside it that just moved two squares, then the en passant move is available.

Castling is a little more fickle, considering all I did last time was locate() the rooks on the same rank if the king was not moved, then made the rook's position available as a movement if it was not moved either. The process is a little more strung out in some respects and streamlined in others, but it most certainly will be a move available this time around, as well.

Honestly I had forgotten about some of these items, as I don't have any formal to-do list and I just move on to any segment of the program that happens to catch my fancy at the time. I may just go for these before I get back to imposition, since it's a trade I never mastered on the last version and am not looking forward to attempting again.
Ahh, but castling is a little more complex. There can't be any pieces in between the king and rook, nor may any of the tiles be under attack by opposing pieces. That and neither the king nor the rook may have moved during the game (not just the king).
Vermolius wrote:
Ahh, but castling is a little more complex. There can't be any pieces in between the king and rook, nor may any of the tiles be under attack by opposing pieces. That and neither the king nor the rook may have moved during the game (not just the king).

There's more to it, as well. The king is not allowed to result in a position that he would be in check (which is obvious), but he can also not move across a space that he would be in check at. The king can also not be in check when starting the move.
Vermolius wrote:
Ahh, but castling is a little more complex. There can't be any pieces in between the king and rook, nor may any of the tiles be under attack by opposing pieces. That and neither the king nor the rook may have moved during the game (not just the king).

The only part about that I had actually forgotten was not being in check to make the castling move. For some reason I remember things as I do them, and as I progressed through making the castling move, it started coming back about how the king can't move through threatened squares, and the rooks can't have moved, and so on. After forgetting the king cannot be in check to make the castling move, I checked the Wikipedia entry to make sure I didn't forget anything else.
Also remember that the rook must be in the same rank as the king (second paragraph). :P
Popisfizzy wrote:
Also remember that the rook must be in the same rank as the king (second paragraph). :P

That pretty much fell into place with the code I was using; if the king hadn't moved, I used its' rank to locate the outermost squares containing the rooks. The use of the same-file castling was human creativity anyways, and it takes specific consideration by a programmer to allow that now-illegal castling move.