Checkers

I love Checkers. Chess is too complicated for my likes, but Checkers has just the right mix of fun and strategy for me. I'm currently working on my own version of the game. Basically, I'm taking Checkers and adding a few tweaks to the gameplay, and hopefully that will create a new realm for the game that will be as enjoyable as the original. The point of this post, however, is to discuss the underlying structure of the Checkers board.

Coding a Checkers board is similar to coding a deck of cards: there are countless ways you could go about doing it. I tend to like to find my own way of doing something like this without looking at how someone else did it first. I think Checkers is one of the most re-done games out there, or at least tile-based board games in general are, so I could be making life a lot easier for myself but where is the fun in that?

The current idea that I'm toying with on paper is that of a custom linked list that not only has links to the item in front/behind, but also left/right. It took about 20 minutes of staring at a checkerboard to come up with this due to the orientation of the board. Pieces in Checkers can only move in diagonal directions, so thinking of a traditional linked list doesn't work too well...but if you simply turn the board on it's corners, you'll see you have a linear path up each column. That's when it clicked that adding left/right linkages to a traditional linked list setup could be a neat way of representing a checkerboard.

The issue I'm working out now is the initial creation of the board and the subsequent management of the board when a new game is started or a saved game is loaded. Currently I'm thinking that I'd need an array that held 64 tile objects, and then I'd create each tile object in some init function. It would go through and setup the front/back/left/right links, the occupied flag, and the color of each tile on the board. As opposed to having 64 ctor calls in a row, I thought about storing tile data in a data file of some sort and then iterating over a vector to create each tile object. Then, that would also be the mechanism to save/load games. The game would simply write out each tile's data to the file and then upon resuming the game it would load them back in.

The objects would be fairly small, so I don't think this would be too terrible of an approach, but I'm sure I could do it better. I need to do it this way first, though. After all, if you sit around and think about how to make something better, you'll never end up making it AT ALL!