• DO NOT EVER SUBMIT TO MARMOSET WITHOUT COMPILING AND TESTING FIRST. If your final submission doesn’t compile, or otherwise doesn’t work, you will have nothing to show during your demo. Resist the temptation to make last-minute changes. They probably aren’t worth it.

• This project is intended to be doable by three people in two weeks. Because the breadth of students’ abilities in this course is quite wide, exactly what constitutes two weeks’ worth of work for three students is difficult to nail down. Some groups will finish quickly; others won’t finish at all. We will attempt to grade this assignment in a way that addresses both ends of the spectrum. You should be able to pass the assignment with only a modest portion of your program working. Then, if you want a higher mark, it will take more than a proportionally higher effort to achieve, the higher you go. A perfect score will require a complete implementation. If you finish the entire program early, you can add extra features for a few extra marks.

• Above all, MAKE SURE YOUR SUBMITTED PROGRAM RUNS. The markers do not have time to examine source code and give partial correctness marks for non-working programs. So, no matter what, even if your program doesn’t work properly, make sure it at least does something.

• Note: If you have not already done so for Assignment 4, make sure you are able to use graphical applications from your Unix session. If you are using Linux you should be fine (if making an ssh connection to a campus machine, be sure to pass the -Y option). If you are using Windows and putty, you should download and run an X server such as XMing, and be sure that putty is configured to forward X connections. Alert course staff immediately if you are unable to set up your X connection (e.g. if you can’t run xeyes).

Also (if working on your own machine) make sure you have the necessary libraries to compile graphics. Try executing the following:

g++ -L/usr/X11R6/lib window.cc graphicsdemo.cc -lX11 -o graphicsdemo

The Game of Biquadris

In this project, your group will work together to produce the video game Biquadris, which is a Latinization of the game Tetris, expanded for two player competition.

A game of Biquadris consists of two boards, each 11 columns wide and 15 rows high. Blocks consisting of four cells (tetrominoes) appear at the top of each board, and you must drop them onto their respective boards so as not to leave any gaps. Once an entire row has been filled, it disappears, and the blocks above move down by one unit.

Biquadris differs from Tetris in one significant way: it is not real-time. You have as much time as you want to decide where to place a block. Players will take turns dropping blocks, one at a time. A player’s turn ends when he/she has dropped a block onto the board (unless this triggers a special action; see below). During a player’s turn, the block that the opponent will have to play next is already at the top of the opponent’s board (and if it doesn’t fit, the opponent has lost).

The major components of the system are as follows:

Blocks

There are seven types of blocks, shown below with their names and initial configurations:

I-block J-block L-block O-block

S-block Z-block T-block

Question: How could you design your system (or modify your existing design) to allow for some generated blocks to disap- pear from the screen if not cleared before 10 more blocks have fallen? Could the generation of such blocks be easily confined to more advanced levels?

Blocks can be moved and rotated. When a block is rotated, it should be done such that the position of the lower left corner of the smallest rectangle containing the block is preserved. For a clockwise rotation, this means that the lower-right corner of the block should take the place of the lower-left corner of the original block. For a counterclockwise rotation, this means that the top-left corner of the block should take the place of the lower-left corner of the original block. A few examples follow (clockwise rotation):

The coordinate axes shown above should be understood as being fixed in space, and are there to show the position of the rotated block relative to that of the original.

Board

The board should be 11 columns and 15 rows. Reserve three extra rows (total 18) at the top of the board to give room for blocks to rotate, without falling off the board. If a block is at the extreme right-hand side of the board, to the extent that there is no horizontal room to rotate it, it can’t be rotated.

When a block shows up on the board, it appears in the top-left corner, just below the three reserve rows, such that the bottom row of the block occupies the row below the reserve rows (so, for example, a horizontal I block would use none of the reserve rows, while a vertical I block would use all of them). If there is not room for the block in this position, the game is over.

When a block is dropped onto the board, check to see whether any rows have been completely filled as a result of the block having dropped. If so, remove those rows from the board, and the remaining blocks above these rows move down to fill the gap.

Display

You need to provide both a text-based display and a graphical display of your game board. A sample text display follows:

Level: 1 Level: 2

Score: 0 Score: 0

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

TTT IIII

T

S

ZSS S

ZZIS SS

ZJI J S OO

OO JI OO JTTT OO

IIII OOJJI OOJJ TIIII

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

Next: Next:

L LLL

Your graphical display should be set up in a similar way, showing the current boards, the current blocks, the next blocks to come, and the scoreboard in a single window. The block types should be colour-coded, each type of block being rendered in a different colour. Do your best to make it visually pleasing.

Next Block

Part of your system will encapsulate the decision-making process regarding which block is selected next. The level of difficulty of the game depends on the policy for selecting the next block. You are to support the following difficulty levels:

• Level 0: (Make sure you at least get this one working!) Takes its blocks in sequence from the files sequence1.txt (for player 1) and sequence2.txt (for player 2) (samples are provided), or from other files, whose names are supplied on the command line. If you get to the end of one of these files, and the game hasn’t ended yet, begin reading the file again from the beginning. This level is non-random, and can be used to test with a predetermined set of blocks. Make sure that sequence[1-2].txt, and any other sequence files you intend to use with your project, are submitted to Marmoset along with your code.

• Level 1: The block selector will randomly choose a block with probabilities skewed such that S and Z blocks are selected with probability 1 each, and the other blocks are selected with probability 1 each.

12 6

• Level 2: All blocks are selected with equal probability.

• Level 3: The block selector will randomly choose a block with probabilities skewed such that S and Z blocks are selected with probability 2 each, and the other blocks are selected with probability 1 each. Moreover, blocks generated

9 9

in level 3 are “heavy”: every command to move or rotate the block will be followed immediately and automatically by a downward move of one row (if possible).

• Level 4: In addition to the rules of Level 3, in Level 4 there is an external constructive force: every time you place 5 (and also 10, 15, etc.) blocks without clearing at least one row, a 1x1 block (indicated by * in text, and by the colour brown in graphics) is dropped onto your game board in the centre column. Once dropped, it acts like any other block: if it completes a row, the row disappears. So if you do not act quickly, these blocks will work to eventually split your screen in two, making the game difficult to play.

Each player is free to choose his/her own level independently. The lower levels produce a greater percentage of “easier” blocks, but the corresponding scores are also lower.

For random numbers, you can use the rand and srand functions from <cstdlib>.

Question: How could you design your program to accommodate the possibility of introducing additional levels into the system, with minimum recompilation?

Special Actions

If a player, upon dropping a block, clears two or more rows simultaneously, a special action is triggered. A special action is a negative influence on the opponent’s game. When a special action is triggered, the game will prompt the player for his/her chosen action. Available actions are as follows:

• blind The player’s board, from columns 3-9, and from rows 3-12, is covered with question marks (?), until the player drops a block; then the display reverts to normal.

• heavy Every time a player moves a block left or right, the block automatically falls by two rows, after the horizontal move. If it is not possible for the block to drop two rows, it is considered to be dropped, and the turn ends.

• force Change the opponent’s current block to be one of the player’s choosing. If the block cannot be placed in its initial position, the opponent loses. (E.g., force Z)

Question: How could you design your program to allow for multiple effects to applied simultaneously? What if we invented more kinds of effects? Can you prevent your program from having one else-branch for every possible combination?

Command Interpreter

You interact with the system by issuing text-based commands. The following commands are to be supported:

• left moves the current block one cell to the left. If this is not possible (left edge of the board, or block in the way), the command has no effect.

• right as above, but to the right.

• down as above, but one cell downward.

• clockwise rotates the block 90 degrees clockwise, as described earlier. If the rotation cannot be accomplished without coming into contact with existing blocks, the command has no effect.

• counterclockwise as above, but counterclockwise.

• drop drops the current block. It is (in one step) moved downward as far as possible until it comes into contact with either the bottom of the board or a block. This command also triggers the next block to appear. Even if a block is already as far down as it can go (as a result of executing the down command), it still needs to be dropped in order to get the next block.

• levelup Increases the difficulty level of the game by one. The block showing as next still comes next, but subsequent blocks are generated using the new level. If there is no higher level, this command has no effect.

• leveldown Decreases the difficulty level of the game by one. The block showing as next still comes next, but subsequent blocks are generated using the new level. If there is no lower level, this command has no effect.

• norandom file Relevant only during levels 3 and 4, this command makes these levels non-random, instead taking input from the sequence file, starting from the beginning. This is to facilitate testing.

• random Relevant only during levels 3 and 4, this command restores randomness in these levels.

• sequence file Executes the sequence of commands found in file. This is to facilitate the construction of test cases.

• I, J, L, etc. Useful during testing, these commands replace the current undropped block with the stated block. Heaviness is detemined by the level number. Note that, for heavy blocks, these commands do not cause a downward move.

• restart Clears the board and starts a new game.