Essentially a your board is a 32-element array (eight rows, four slots per row). You don't strictly speaking need to use a 2D array to represent this, as you can use a 1D array just fine with a bit of indexing math (it's useful to understand how to do so, because in some cases it can be a huge benefit; in this case it's likely to be a "six of one, half-dozen of the other" type of trade off though).
Each slot in the board can be empty, or a color. You could thus represent the value of a slot with the following enumeration:
enum SlotState {
SS_EMPTY,
SS_RED,
SS_GREEN,
SS_BLUE,
// ...however many colors there are...
};
and represent the board itself with a simple class with the following minimal interface:
class Board {
public:
static const int COLUMNS = 4;
static const int ROWS = 8;
Board() {
std::fill_n(slots, ROWS * COLUMNS, SS_EMPTY);
}
SlotState getSlot(int row, int column) const {
return slots[row * COLUMNS + column];
}
void setSlot(int row, int column, SlotState state) {
slots[row * COLUMNS + column] = state;
}
private:
SlotState[ROWS * COLUMNS] slots;
};
Then, given any board, you can print it by simply iterating through the rows/columns of the board, asking the board for the value of the slot at that position, and rendering it. For example, to do so using the standard C++ console output object might look something like:
void printBoard(const Board& board) {
for(int row = 0; row < Board::ROWS; ++row) {
for(int column = 0; column < Board::COLUMNS; ++column) {
switch( board.getSlot( row, column ) ) {
case SS_RED:
std::cout << 'R';
break;
case SS_GREEN:
std::cout << 'G';
break;
// ..et cetera...
default:
std::cout << ' ';
}
}
std::cout << "\n";
}
}
You could just as easily be telling your graphics API to enqueue sprites or colored triangles/quads at that point, though, instead of printing characters.
The reason I suggest this approach is that, as you can see, the board itself ends up only knowing about the board's logical state... the size of the board and the value of every slot in the board. It also provides a relatively minimal (but functional) interface to manipulating the board. It has a single responsibility -- to represent the board. There's nothing in there about rules for what colors must go where (although a real-world class should perform some bounds checking that I have eschewed here for brevity). And there's nothing in there for rendering the board -- that is accomplished entirely by an external, non-member function and can be done entirely via the public interface of the board object.
This keeps the class lightweight and reusable and helps to increase it's maintainability as well -- it's a good habit to get in to trying to approach designs like this (and also to, in general, keep logical interfaces and rendering interfaces distinct).
