CS2704:  Summer I, 2002

Project 1

Same Game

 

This project is to provide you with practice using composition by association.  Association allows objects to use other objects to carry out services, but they do not contain the other object.  This means that the associated object can easily change during the execution of the program.  This project illustrates this using the game "Same," for which the goal is to eliminate all pieces on the board by "touching" a piece with neighbors that are the same "color" (we will use the symbols +, - , and * as the "colors").  As pieces are eliminated, the neighbors of a piece will change.

For example, suppose the board is size 6 by 10 and initially looks like this

  0 1 2 3 4 5 6 7 8 9

0 * * - + * + + - - *

1 - * - - * + * + - +

2 - * * * * - * - + +

3 - + * * * - * + - -

4 - - - * * * * - + +

5 * * * * - * + + + +

 

 
 

 

 

 

 

 

 

 


If we touch the * at location 3,4, then the board would change to look like this

  0 1 2 3 4 5 6 7 8 9

0     - +   + + - - *

1 -   - -   +   + - +

2 -         -   - + +

3 - +       -   + - -

4 - - -         - + +

5         -   + + + +

 

 
 

 

 

 

 

 

 

 


Touching ay of the locations with a * in the eliminated cluster actually would have given the same result.  Notice that the piece at the location 0,9 was not affected by the touch, since it was not adjacent to any of the neighbors of the piece at 3,4.  Also, note that pieces that were not previously neighbors, are now.  For instance, the piece at locations 0,3 is now a neighbor of the piece at 0,5.  The neighbors of a piece are the non-blank) symbols above, below, left, and right of the piece (pieces diagonal are not neighbors).  The score after this touch is 24.

 

Continuing the game, if we touch the + at location 1,5, the board looks like the following, and the score is 35.

  0 1 2 3 4 5 6 7 8 9

0     -         - - *

1 -   - -         - +

2 -         -   - + +

3 - +       -   + - -

4 - - -         -

5         -

 

 
 

 

 

 

 

 

 

 


Notice that the piece at 3,7 was not affected because it was not a neighbor of any of the affected pieces.  Touching a piece whose neighbors are not the same "color" does nothing to the board nor the score.

 

If we now touch the piece at 4,7, the board looks like this, and the score is 51.

  0 1 2 3 4 5 6 7 8 9

0                   *

1                   +

2                 + +

3   +           + - -

4                

5         -

 

 
 

 

 

 

 

 

 


From this state we can finish the game by touching the pieces at 3,1, then 2,8, then 3,8.  This produces the final board below, with a score of 58.

  0 1 2 3 4 5 6 7 8 9

0                   *

1               

2         

3  

4                

5         -

 

 
 

 

 

 

 

 

 

 


No further eliminations are possible because no non-blank piece has a matching neighbor.

 

 

Input:

Input for this program will be from a command file named sgIn.txt that can contain commands and comments.  All lines beginning with a semicolon (";") are comments and should be ignored.  The file will begin with the board information;  the first non-comment line will be the size of the board and will have the form

            size <int>  <int>

where <int> indicates that a positive, non-zero integer occurs.  The first integer is the number of rows in the board, and the second is the number of columns.  Unless otherwise stated, tokens in command lines will be TAB separated (e.g. a TAB after the keyword size and another after the first integer).

 

Following the size information, the initial board is given.  The number of input lines should match the number of rows on the size line, but your program should verify this and produce an appropriate error message if incorrect.  Each line of the board will have the form

            <symbol>{<TAB><symbol>}*

where <symbol corresponds to one of the characters +, *, or -.  Note that the {<TAB><symbol>}* is a meta-notation, indicating zero or more occurrences of what appears in the braces may appear.  So, the means that a line consists of one or more symbols separated by TABs.  The number of symbols on each line must match the number of columns on the size line, otherwise an error would be displayed.

 

One the initial board has been determined, the following commands may occur.  All command are case-sensitive (You should check for this and produce error messages, if necessary.)

 

display

Print the current board to the output file described below in the format described below.  Given the design below, your program should iterate through the board calling the display function for each individual piece.  The display function of the piece will simply print the "color" of the piece.

 

exit

End program execution

 

score

Print the current score

 

touch   <int>   <int>

If the piece at the coordinate (given by row then column) has any neighbors that are the same symbol, set the piece symbol to be blank, and touch the matching neighbors.  The result is that any pieces with the same symbol touching the piece at the given location, one of its neighbors, or a neighbor of its neighbors should be "touched."  Neighbors of the touched piece must be reassigned (see design section below).  If a piece has no neighbor with the same symbol, nothing should happen.  More details are discussed below in the design section.

 


For example, the following is a sample input:

; test file 1

;

; board size 3 X 4

size 3    4

; initial layout of board

*    -    +    *

*    *    -    +

+    +    -    +

; commands

display

touch      2    0

score

display

exit

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


For this project, you will implement a program that parses such command files and executes the given commands.  The input is guaranteed to be syntactically correct, so you do not have to check for syntax errors.

 

The input file may contain an arbitrary number of comment lines and command lines, and the ordering of the commands may be different from the given example.  Therefore, you should test you own code will many input files that you define.

 

Sample Output:

 

Output should be printed to a file named sgOut.txt.  Here is the output for the input file given above:

Programmer:  Todd Stevens

CS 2704 Project 1

-----------------------------------

Board:

  0 1 2 3

0 * - + *

1 * * - +

2 + + - +

---------

 

Score: 2

 

Board:

  0 1 2 3

0 * - + *

1 * * - +

2 + + - +

---------

-----------------------------------

 

 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Design, Coding, and Documentation

 

This assignment has fairly strict implementation requirements -  you must follow these directions to receive full credit.  Note that the purpose of this assignment is not simply to produce a program that works (which you should already be bale to do), but you must practice and understand association and good program construction.

 

You must implement at least 2 classes: Gamepiece and Counter.  The Gamepiece class contains the current symbol of the piece and has methods for touching the piece and displaying the symbol to an output stream.  The counter should simply allow an integer count (i.e. the game score) to be incremented.  Ideally, the board would be implemented as a class, but it would require aggregation and that is for the next program.  Instead, the board should be implemented as a dynamically allocated, two-dimensional array of game pieces.  It should be declared in main( ) or the driver function (the use of pointers in the array is not a strict requirement, but suggested).  Since there are technical problems with passing dynamically allocated, two-dimensional arrays as parameters, we will provide an implementation of a two-dimensional array template class that will be available through the course web site. (Use it or you'll have problems that you will have to figure out yourself.)  The Counter object is to store the score, and there should only be one that is also declared locally in the driver (or main( )).  The Counter object should be initialized to 0, clearly.

 

You must use the following class structure in implementing your assignment:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Notice that each Gamepiece has an association with up to2 to 4 other Gamepiece objects.  These are the neighbors of the object in the game.  Initially, they should be set to the objects adjacent to the object on the board.  The touch( ) method should only be called when processing a touch command from input.  It should check to see that there is a Gamepiece object that is a direct neighbor that has the same "color," and if so do three things.  First, it should change its own color to blank.  Second, it should revise the neighbor association of its neighbors.  For instance, giving the pointer for the neighbor above to the neighbor below, and vice versa.  If this is done properly, objects on the boundary of the board with NULL pointers will just pass the NULL pointer to the appropriate neighbor.  When done with their operation the object should still be accessible from the board but not from any other Gamepiece object.  Third, the touch( ) method should touch its (old) neighbors using the touch(color) method using the original color of the piece as the parameter.

 

The touch(color) method should only be called by touch( ) and does nearly the same thing as the touch( ) method.  More details may be discussed in class.

 

A touch command must access the first object through the board using the coordinates given, and then subsequent touch operations on objects in the game must be handled by the touch(color) method.  You will receive a 0 (ZERO) on this assignment if you implement this by iterating through the board!   However, both initialization and the display command can be accomplished by iterating through the board.

 

It also violates the intention of the association to write your code so that the data of neighbors is accessible from other Gamepieces.  You must not allow this.  Consider instead methods such as setLeftNeighbor(somearg).

 

You need to add methods to the Gamepiece and Counter classes, but you must include (and use) the ones above.  All data should be properly encapsulated in the classes.  You also have the freedom in designing the parsing and command driver, but realize that we expect that principles of good design must be used and will affect your grade.

 

You should document your implementation in accordance with THE Standards Page on the course web site.  Your program will be evaluated for documentation as well as correctness.

 

Grading & What to Turn in Where:

 

To be discussed in class…