CSSE2310作业代做、代做Data structures作业、Java,c++,Python编程语言作业代写 代写留学生 Statistics统计、回归、迭

- 首页 >> Database作业
Example Design Document for CSSE2310 Assignment X - tictactoe++
Data structures
Due to the fixed size of the game board (3x3), I am using a 3x3 array of integers to store the
game state. To avoid using global variables, I have encapsulated this into a type, supported by
an enum to capture player identities. PLAYER NONE indicates an empty space.
enum player {PLAYER_NONE = 0, PLAYER_X = 1, PLAYER_O = 2);
typedef struct gameState {
enum player board[3][3]; // Contents of board
enum player who; // Whose turn is it?
} gameState;
Game logic
The game logic is pretty simple, my main loop just keeps track of whose turn it is, reading the
next move for that player. Handling of game saving and loading is done in the getInput()
function. After each valid move, the function checkWinner() is called to see if anybody has
won the game. checkWinner() it a wrapper function around several other functions that are
used to check for rows, columns or diagonals filled by the same player marker. I could have
probably done this more efficiently.
File handling
My program was required to read several different kinds of files, although there were some
things in common. Files could have comment lines starting with ’#’ so I wrote a function
called readLineWithComments() to handle this.
Using this as a building block, I wrote functions to handle each of the possible file types I
had to read.
Encapsulating the game state into a struct made it really easy for me to write a function
displayBoard() which I could update as required. In particular, the requirement to print row
and column headers, and separator characters between player markers was something I could
just implement in displayBoard() without changing the underlying gameState data type. I
really feel like I learned something about data type abstraction in this assignment.
Error handling
The specification defines a large number of possible error conditions, some of which might
possibly occur in the same run. A clarification was posted to the course Piazza which said that
only one error cnodition would be tested at a time, which means that the relative priority of
error states and the order of checking is not critical.
My approach to error handling is by printing a hard-coded string and calling exit() with
a hard-coded error code, as shown below:
if (something bad happened) {
Given that there are about 10 possible error codes, this means I have exit() calls scattered
all around my program. On reflection, this approach made it quite painful for me when the
spec changed and updated some error messages and codes. I might think about doing this
differently next time. It also made it difficult to debug my program.