chess, writing, coding

So today I finally wrote a program I'd been kicking around--a chess puzzle solver. Basically you have X chess pieces on a board and you want to start at a given one and capture the others. It would help to solve a mini-puzzle in an online game.

Surprisingly, the weird-move pieces (pawn/kt) were easier than the more conventional ones (rook/bishop/queen.) They only had fixed squares, so I had all sorts of tests to make sure a rook can't hop over a piece in its way.

The code's surely horrendous for fans of compactness, but on the other hand, I see that now. While comp-sci types used to annoy me with OMG ITS CONVENIENT, I didn't like structured/object oriented programming on principle. It gave these jokers more time to mouth off, apparently. But once I cut and pasted code--and had to cut/paste 30 modifications--ok, I don't just know it, I've felt it.

So I may rewrite it. But it's not the sort of rewriting/succinctness I ultimately want. Still, despite my aptitude for computers, chess, and gaming, I'd never really combined them, or written any sort of solver. I didn't realize it til after I'd written the program. For some reason I'd put chess programmers on a pedestal--as if it were too tricky. I didn't write anything like AI, but...I was able to mock up something small in a hurry. And the more I do that, the more it gets old hat and I believe it can build to something bigger. I'd like to think I've always had faith, but taking just an hour for something like this gives reason for faith--and feels darn good.

As I write this I realized my code lets kings and knights and pawns wrap to the other side of the board. But I also realize worrying about that sort of thing too soon probably derailed some earlier projects. Sort of like the minor compulsion of proofreading rough drafts for grammar before letting the ideas out. (And that "focused" editing has often left bigger pieces more disjointed than I'd care to mention.) It's as if I'm finally able to tell my meddling overzealous proofreader--DONT DISTURB ME. COME BACK LATER. I'M BUSY.

Comments 6

LowerStreetBlues Jun 3, 2010

If I were trying to model chess, I would think accurately recreating the board would be very important since it gives definition to legal and illegal moves of any pieces. As long as the chessboard is a separate class to itself (and the pieces should probably be classes too), I don't think it's a bad call for you to keep going, because you could add boundary/validity checking functions to the cb class. But if that's not how this is modeled, I'd expect implementing corrections for the wrapping to be a pretty hairy job that'll come back to haunt and might make developing additional logic for a game horrific.

So obviously there's always different solutions, but that'd be my approach.

LowerStreetBlues Jun 4, 2010

PS Check out Wikipedia. My first thought was to use a double array, but I think the 0x88 method is pretty slick.

http://en.wikipedia.org/wiki/Board_representation_%28ches...

aschultz Blogger Jun 4, 2010

Wow. 0x88 is -very- neat. I hadn't thought of that.

Double arrays seem serviceable--there's always the possibility of flipping them, but that only has to be fixed once. Still, seeing a bit of minor magic like this is way cool.

I never thought of defining a piece as a class. I'd think something like

@bishopMoves = (+17 | 32,-17 | 32, +15 | 32, 0,-15 | 32)

Where 16=1 square left, 1 = 1 square up, and 32 = move multiple squares and make a language based on that.

This is more work than I meant to do but it's fun to think of more...

honestgamer Staff Jun 4, 2010

I have nothing to add except that arrays make me happy. I don't actually use them in a programming sense, just in web design, but they serve me well enough on that front that I've nothing but good will for them elsewhere.

Surprised you haven't used hashes yet, or had a need to. I used them extensively for the TT stats. They're even more fun than arrays. At least in Perl. PHP, I don't know about. I suspect if you posted something in depth, I would be semi lost too. But if we traded code, we'd be able to scrap out roughly what the other person was getting at. Programming languages are cool that way.

LowerStreetBlues Jun 5, 2010

I think we're on the same page, Schultz. My idea for a bishop class would, bare minimum, have some defining information (so, color=black; currentsquare=3), a function that calculated valid moves and an array/list of all valid moves at any moment.