May 14, 2003

Checkers (not really Cocoa)

I'm working on this project for school. A game of checkers. It's you vs. the AI, where the AI randomly moves. Obviously all the rules of checkers must be enfoced, so if you have the ability to take a piece you must do so. Kings must also be supported. It's a console application, so no graphics allowed.

And now my question for you. I've looked at this for a little while, and even written parts of it twice. I'm just wondering what those of you who read this weblog would do? Specifically, I'd like to hear some implementation ideas.

As an example, the first time, I had a BOARD class and a CHECKER class. Internally, the BOARD used an apmatrix of CHECKER's (CHECKER's had a 'defined' variable, so you could have 'empty' checkers). I ended up not liking this way of doing it so much because I really didn't feel like I needed a CHECKER class with 99% of the work being done by the BOARD.

So, suggestions?

Posted by Stevos at May 14, 2003 09:35 PM | TrackBack
  Comments

Haven't given to much thought to that yet but I'd use a 2d array of shorts that way you could have something like:
#define EMPTY 0
#define WHITE_CHECKER 1
#define WHITE_KING 2
#define RED_CHECKER -1
#define RED_KING -2
that sounds convenient enough and pretty efficient (no need to go overboard either)
then I'm guessing from what you said that you'd randomly find a red piece and then move it. You could probably keep track of the red coordinates in a vector[pair [int, int]] and then just randomly pick and index or something but I don't know if the extra space really makes up in efficiency much...

·May 14, 2003 09:54 PM · comment by JWizard   -   ∞

I'd keep a vector of locations of checkers for each side to speed up access: instead of running through every square on the board looking for a red checker to validate moves for on Red's turn, you have them right there in RED_PIECES, and the same for Black.

·May 14, 2003 10:56 PM · comment by XRayNuke   -   ∞

I always try to keep my peices in the back row there for as long as possible. That way, the other guy can't king, and I don't have to worry about them getting jumped.

Hope that helps.

·May 15, 2003 09:14 AM · comment by preeb   -   ∞

XRay: I don't think you need a vector for the player's side since you'll never have to randomly pick one and the user will know where they are by looking at the board...

·May 15, 2003 10:24 AM · comment by JWizard   -   ∞

JWiz: but you need to do moves validation on them to see if there's a forced move and which checkers can be moved at all. Hence the user-side vector; it saves time.

·May 15, 2003 04:10 PM · comment by XRayNuke   -   ∞

Call me stubborn, but to see if there is a forced move isn't it more convenient to check the squares around the piece you want to move rather than keep a vector of pieces and go through it ?

·May 15, 2003 04:34 PM · comment by JWizard   -   ∞

You have to check all the pieces for forced moves! It doesn't matter which one you want to move if another one has to be moved.

·May 16, 2003 01:29 PM · comment by XRayNuke   -   ∞

OK, nevermind then... it's been too long since I last played checkers :)

·May 17, 2003 10:20 AM · comment by JWizard   -   ∞

This article has been up for days.

Update, you whore.

·May 17, 2003 12:39 PM · comment by preeb   -   ∞
  Post a comment









Remember personal info?