- Partner: Katherine Lynn Hutchinson
Our project is an implementation of the Dots and Boxes game - a description of which can be found on wikipedia . In brief, the game sets out a grid of dots that form the corners of a grid of boxes, and players take turns picking edges - drawing a line horizontally or vertically between adjacent dots. When a box is completed, the player who picked the edge that completed it “claims” the box and gets to take a bonus turn. Once all edges have been taken, the game ends and whoever has claimed the most boxes wins. Our implementation specifies a 3x3 grid of boxes and specifies that a game will only have two players. The only time either of those things are described are in the “main” function in main.cc, which leaves room for expanding the game at a later time to allow for more users or differently sized grids.
In our implementation, the ZedBoard’s push buttons are used as a controller. Whenever a player takes a turn, they would first use the push buttons to select a box from the grid and then select an edge of that box to draw. We thought this was a cleaner implementation and interface than attempting to directly select an edge, as there was no clear way to select an edge directly using the push buttons because we have both horizontal and vertical edges, meaning that it wouldn’t be obvious what would happen if you clicked a specific button. We interfaced with the ZedBoard by grabbing the ZedBoard class as we had written it in a previous lab and then dynamically creating an instance of it in main and passing it to the function which handled a single turn. We also chose to, in the turn function, print the current state of the game board - including the currently-selected box and edge if in the second part of a turn - whenever a user pressed a push button so that there would be consistent feedback about which box and/or edge was currently selected.
The game board itself is represented by an object-oriented series of classes that represent first the board, and then the boxes and edges. The main function only creates the DotsBoard itself, specifying the number of rows and columns for the board, and then the DotsBoard constructor creates the DotsBox objects and DotsEdge objects which represent the boxes and edges, respectively. The DotsBoard class itself has a vector of vector of boxes, which represents the overall grid of boxes. This approach was chosen as the size of the board is unknown until the time of construction, and pure arrays would not handle this well. The DotsBoard class does not contain references to edges, but rather creates the edges and then tells the edges which boxes they are adjacent to, and tells the boxes which edges are on each side of it. This was interesting to accomplish simply because many boxes share edges with each other, so some edges of a box might have been instantiated before a box was instantiated - same with an edge and the second box it is attached to. For this reason, neither the constructors for DotsEdge and DotsBox do not take any arguments, and the appropriate values are instead set using appropriate “setters” that then update the values - the constructors initially set them to NULL, which is especially important for edges, as they may or may not have a second adjacent box.
For this project we exercised object oriented programming in C++ for the creation of the game in software. We broke down the Dots Boxes game into its four core components; the boxes, the edges, the controller, and the board. When we run the program we assemble our game by creating an object of class DotsBoard, and a ZedBoard object. The constructor for the DotsBoard class creates the according number of DotsEdge and DotsBox objects for the size of the grid specified by the user. We took advantage of this programming approach because we create various objects of the same class, and could easily debug and test the program. This prompted us to exercise our design skills on modeling the physical game in software objects.
We also applied the technique learnt in class of memory-mapped I/O to access the ZedBoard. As described previously, we created four different classes, three for the game and one for the ZedBoard. In the constructor for the ZedBoard class we use the technique of memory-mapped I/O, where we access a virtual file that represents different I/O of the Zedboard and create a pointer that holds the base address of the virtual memory allocated for this device. By dereferencing the pointer, offset at the according address, we could read the state of the device. This allowed us to base our game on the state of the five different push buttons on the ZedBoard.
Since our program has the ability to expand, we used a vector of vector of boxes to dynamically allocate memory for the board based on the user choice for the size of the grid. We based our decision on what we researched about choosing the right kind of data structure for our program’s goal. We exercised our knowledge of data structures to instantiate the objects with the goal of most efficiently using the memory.