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!
3 comments:
My approach to creating such a board would be to encapsulate a 2d array into a board object. There is no need to have a dynamic collection such as a linked list because the size of the board is static. Also, with a linked list, you must either traverse in a single direction, or make a node know about all of its neighbors. Suppose a player were to select a piece on a board and then select where they want to move it. To figure out what the user has just done by clicking in the two places, you must first map the click to a cell, then traverse to the cell in your linked list and read the data in that cell. However, with a 2d array you need only map the click to a cell and then read directly from the cell.
I would create a cell object that would hold information pertinent to that cell and on a new game initialize that cell with what should be in it.
As for the saving issue, the easiest way would be through the use of serialization. Rather than exporting and importing the information of each cell, you could simply save the class, which is holding its state and then when loading a save game simply reload that saved class.
Thanks for the comment. I agree with you in terms of the board being static. Actually, from the outset I was looking to do 2 things: 1. Avoid multiple dimension arrays and 2. Gain experience in implementing non-standard data structures (mainly for academic purposes). Those 2 things may have clouded my judgment in creating the best solution for the task, but that isn't to say that I wasn't well aware that the common approach to this issue was to use a multiple dimensioned array. I haven't done much with serialization in practice, but I'll definitely look more into that now that you proposed it.
Also, I have been toying with a concept in my head "similar" to what you've proposed such that instead of tightly defined and linked entities, the board be composed of "free standing" cell objects that have a basic understanding of their surroundings. It will take a bit more thought, as well as trial and error to work this out, but I think it's fairly "doable" and it may alleviate the issues you've outlined in terms of needing to traverse the entire list just to obtain a desired location. Although, I'm not sure that's entirely true if when the board is initially created all of the left/right links are setup in relation to the neighboring lists. In that fashion, you'd already be at the desired location, it would just be a matter of calling a lookup function to "arrive" there.
Post a Comment