Pauley Pavilion has been infested with zombies! The pest control company you work for has supplied you with poisoned brains and sent you in to exterminate the zombies.

Well, that's the scenario for a new video game under development. Your assignment is to complete the prototype that uses character-based graphics.

If you execute this Windows program or this Mac program (see how to override the security setting) or this Linux program, or run the command /usr/local/cs/bin/zombiesdemo on cs31.seas.ucla.edu, you will see the player (indicated by @) in a rectangular arena filled with zombies (usually indicated by Z). At each turn, the user will select an action for the player to take: Either move one step or drop a poisoned brain without moving. The player will take the action, and then each zombie will move one step in a random direction. If a zombie moves onto the grid point occupied by the player, the player dies from the zombie's attack. (If the player moves to a grid point occupied by a zombie, the player is attacked and dies, so that would be a dumb move.)

If a zombie lands on a grid point with a poisoned brain, it eats the brain. The first time a zombie eats a poisoned brain, it slows down: It doesn't move on its next turn, but it moves on the turn after that, then on the next turn it doesn't move, then it moves on the turn after that, etc., moving only every other turn. The second time a zombie eats a poisoned brain, it dies. (If a poisoned zombie moves to a grid point with both the player and a poisoned brain, it eats the brain and just before it dies, it attacks the player, so both die.)

This smaller Windows version or Mac version or Linux version of the game may help you see the operation of the game more clearly. You can also run /usr/local/cs/bin/minizombiesdemo on cs31.seas.ucla.edu.

At each turn the player may take one of these actions:

1. Move one step north, east, south, or west, and do not drop a poisoned brain. If the player attempts to move out of the arena (e.g., south, when on the bottom row), the player does not move, and does not drop a brain. If the player moves to a grid point currently occupied by a zombie, the player dies.
2. Do not move, but attempt to drop a poisoned brain. If there is already a poisoned brain at that grid point, no additional brain is dropped; a grid point may have at most one poisoned brain. The player has an unlimited supply of poisoned brains.

The game allows the user to select the player's action: n/e/s/w for movement, or x for dropping a poisoned brain. The user may also just hit enter to have the computer select the player's move.

After the player moves, it's the zombies' turn. Each zombie has an opportunity to move. A zombie that has previously eaten a poisoned brain will not move if it attempted to move on the previous turn. Otherwise, it will pick a random direction (north, east, south, west) with equal probability. The zombie moves one step in that direction if it can; if the zombie attempts to move off the grid, however, it does not move (but this still counts as a poisoned zombie's attempt to move, so it won't move on the next turn). More than one zombie may occupy the same grid point; in that case, instead of Z, the display will show a digit character indicating the number of zombies at that point (where 9 indicates 9 or more).

If after a zombie moves, it occupies the same grid point as the player (whether or not there's a poisoned brain at that point), the player dies. If the zombie lands on a grid point with a poisoned brain on it, it eats the brain (and the brain is no longer part of the game). If this is the second poisoned brain the zombie has eaten, it dies. If more than one zombie lands on a spot that started the turn with a poisoned brain on it, only one of them eats the poisoned brain.

Your assignment is to complete this C++ program skeleton to produce a program that implements the described behavior. (We've indicated where you have work to do by comments containing the text TODO; remove those comments as you finish each thing you have to do.) The program skeleton you are to flesh out defines four classes that represent the four kinds of objects this program works with: Game, Arena, Zombie, and Player. Details of the interface to these classes are in the program skeleton, but here are the essential responsibilities of each class:

Game

• To create a Game, you specify a number of rows and columns and the number of zombies to start with. The Game object creates an appropriately sized Arena and populates it with the Player and the Zombies.
• A game may be played.

Arena

• When an Arena object of a particular size is created, it has no positions occupied by zombies or the player. In the Arena coordinate system, row 1, column 1 is the upper-left-most position that can be occupied by a zombie or the player. If an Arena created with 10 rows and 20 columns, then the lower-right-most position that could be occupied would be row 10, column 20.
• You may tell an Arena object to put a poisoned brain at a particular position.
• You may ask an Arena object whether there's a poisoned brain at a particular position.
• You may tell an Arena object to create a Zombie at a particular position.
• You may tell an Arena object to create a Player at a particular position.
• You may tell an Arena object to have all the zombies in it make their move.
• You may ask an Arena object its size, how many zombies are at a particular position, and how many zombies altogether are in the Arena.
• You may ask an Arena object for access to its player.
• An Arena object may be displayed on the screen, showing the locations of the zombies, the player, and the poisoned brains, along with other status information.

Player

• A Player is created at some position (using the Arena coordinate system, where row 1, column 1 is the upper-left-most position, etc.).
• You may tell a Player to move in a direction or to drop a poisoned brain.
• You may tell a Player that it has died.
• You may ask a Player for its position and its alive/dead status.

Zombie

• A Zombie is created at some position.
• You may tell a Zombie to move.
• You may ask a Zombie object for its position and its alive/dead status.

The skeleton program you are to complete has all of the class definitions and implementations in one source file, which is awkward. Since we haven't yet learned about the intricacies of separate compilation, we'll have to live with it.

Complete the implementation in accordance with the description of the game. You are allowed to make whatever changes you want to the private parts of the classes: You may add or remove private data members or private member functions, or change their types. You must not make any deletions, additions, or changes to the public interface of any of these classes — we're depending on them staying the same so that we can test your programs. You can and will, of course, make changes to the implementations of public member functions, since the callers of the function wouldn't have to change any of the code they write to call the function. You must not declare any public data members, nor use any global variables whose values may change during execution; global constants are OK. You may add additional functions that are not members of any class. The word friend must not appear in your program.

Any member functions you implement must never put an object into an invalid state, one that will cause a problem later on. (For example, bad things could come from placing a zombie outside the arena.) Any function that has a reasonable way of indicating failure through its return value should do so. Constructors pose a special difficulty because they can't return a value. If a constructor can't do its job, we have it write an error message and exit the program with failure by calling exit(1);. (We haven't learned about throwing an exception to signal constructor failure.)

What you will turn in for this assignment is a zip file containing this one file and nothing more:

1. A text file named zombies.cpp that contains the source code for the completed C++ program. This program must build successfully using both g31 and either Visual C++ or clang++, and its correctness must not depend on undefined program behavior. Your program must not leak memory: Any object dynamically allocated during the execution of your program must be deleted (once only, of course) by the time your main routine returns normally. For this project, you do not have to write comments in your program.

Notice that you do not have to turn in a report describing the design of the program and your test cases.

By Wednesday, December 3, there will be link on the class webpage that will enable you to turn in your zip file electronically. Turn in the file by the due time above. There will not be any extensions of the due date for this project, so start early and do not procrastinate.