Objectives

• to work with a framework using templates and inheritance

Assignment

• The width and height of the board can be any even number at least 4 and can be different, with the width always at least as large as the height. The dimensions will be given as two command-line arguments (width first, then height). The starting configuration alternates red and blue stones with red in the bottom right of the upper left quadrant of the board (so the center four stones are the same as in the original 8x8 version of the game), with the edge rows and columns empty and the corners of the starting configuration clipped so that the leftmost (and rightmost) column is empty, the next column to the right (and left) has two stones in the middle two rows, the next column to the right (and left) has four stones, etc. until the columns are filled except for the top and bottom rows.
• For boards of height at least six, each player has four light stones that replace the regular stones in the in the columns that contain four stones. Light stones move like regular stones. When another stone (either light or regular) hits a light stone, only the light stone and the stone that hit it are removed.

The input interface for the game should be the same as for Checkers. Red moves first. Moves are specified by the coordinates of the stone to move and the coordinates of the empty space to move it to (so the space beyond must either contain another stone or be off the board). If the game ends in a draw then the final line of output should be "Draw". In the (impossible?) case that a player cannot move on their turn then the other player wins.

Along with a text display of the current state at the beginning of the game and after each legal move in the same format as for Checkers (with B now representing blue stones instead of black checkers and lower case letters for light stones), your program should produce an HTML file called fission_output.html so that the final state of the game can be rendered in a web browser. The dimensions of the canvas element should be 20 pixels per row and column and the form of output should be as given in the example HTML file. The smaller circles represent the light stones. Ideally, your code would produce exactly the same HTML file as the given one for the corresponding final state (the script in the sample file draws the squares for the board top-to-bottom, left-to-right and then the pieces, also top-to-bottom and left-to-right). If there is a problem writing the file then your program should fail gracefully.

You must submit a makefile that creates an executable called Fission.

Grading will be based on correctness and design, with a large part of the grade for design determined by the extent of changes to the code you submitted for Checkers (preferably only small changes to main) and by the amount of code in new classes. Some part of the grade for design will be determined by a judgement of how easily your implementation could be modified to play with other new kinds of pieces (ideally, only new code in a new class and a modification of the setup code would be required; the code for regular and light pieces should not need to be modified if we were to introduce yet another kind of piece).

We also reserve the right to deduct points from submissions for violations of the following guidelines.

• Submissions should not rely on any particular compiler's implementation in situations where the C++ specification states that behavior is undefined.
• Submissions should not leak memory.
• All source code should be easily comprehended, with adequate and consistent spacing, concise but descriptive idenitifiers, comments before long sequences of code, and enumerations and constants favored over literals.
• Submissions should be modularized, with collections of related functions and methods divided into separate files. Generally this means that each class that is intended for external use should have its own header and implementation files declaring and defining its members and related functions.
• Header files should be written so that they can be #included regardless of what other files have been #included -- if a declaration is required by your header files, then #include the appropriate header file in your header file (or write a forward declaration in your header) rather than relying on your #includers to have already #included those header files before they #include yours.
• You should use C++ libraries and constructs rather than the corresponding C libraries and constructs where possible and not otherwise specified (for example, use cin and cout with the I/O operators << and >> rather than printf and scanf).
• Each public member of a class should be documented with a comment before it in the header file. For a method the comment should include 1) a description of the parameters including any limitations on the values allowed (preconditions), and 2) a description of what the function does and/or what it returns (postconditions).
• Things that make sense to be declared as const should be declared as const.
• There should be no warnings when your code is compiled with the -Wall and -pedantic options.

Files and Submissions

Submit everything you need in order to build Fission.