Rage Against the Machines

The Mechanoids of Planet Zork have captured you! To satisfy their lust for oilshed and bloodshed, they have pitted you in combat against killer robots. 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 or this Linux program, you will see the player (indicated by @) in a rectangular arena filled with killer robots (usually indicated by R). At each turn, the user will select an action for the player to take. The player will take the action, and then each robot will move one step in a random direction. If a robot lands on the position occupied by the player, the player dies.

This smaller Windows version or Mac version or Linux version of the game may help you see the operation of the game more clearly.

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

1. Stand. In this case, the player does not move or shoot.
2. Move one step up, down, left, or right. If the player attempts to move out of the arena (e.g., down, when on the bottom row), the result is the same as standing. It is allowable for the player to move to a position currently occupied by a robot. If no robot occupies that position after the robots have moved, the player survived the turn.
3. Shoot in one of the four directions up, down, left, or right. If there is at least one robot at any distance in that direction, the nearest one in that direction is the candidate victim. If more than one robot is nearest (i.e., they occupy the same position), only one robot at that position is the candidate victim. With 2/3 probability, the candidate victim is damaged; with 1/3 probability, the shot is ineffective and no robot is damaged. A robot that has been damaged for the second time is destroyed (i.e., to destroy a robot takes two shots that hit).

The game allows the user to select the player's action: u/d/l/r for movement, su/sd/sl/sr for shooting, and just hitting enter for standing. The user may also type q to prematurely quit the game, or c to have the computer select the player's move.

When it's the robots' turn, each robot picks a random direction (up, down, left, or right) with equal probability. The robot moves one step in that direction if it can; if the robot attempts to move out of the arena, however, (e.g., down, when on the bottom row), it does not move. More than one robot may occupy the same position; in that case, instead of R, the display will show a digit character indicating the number of robots at that position (where 9 indicates 9 or more). If after the robots move, a robot occupies the same position as the player, the player dies.

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, Robot, 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 robots to start with. The Game object creates an appropriately sized Arena and populates it with the Player and the Robots.
• A game may be played.

Arena

• When an Arena object of a particular size is created, it has no robots or player. In the Arena coordinate system, row 1, column 1 is the upper-left-most position that can be occupied by a Robot or Player. (If an Arena were 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 the Arena object to create or destroy a Robot at a particular position.
• You may tell the Arena object to create a Player at a particular position.
• You may tell the Arena object to have all the robots in it make their move.
• You may ask the Arena object its size, how many robots are at a particular position, and how many robots altogether are in the Arena.
• You may ask the Arena object for access to its player.
• An Arena object may be displayed on the screen, showing the locations of the robots and player, 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 stand, move in a direction, or shoot in a direction.
• You may tell a Player to take an action of its choice.
• You may tell a Player it has died.
• You may ask a Player for its position, alive/dead status, and age. (The age is the count of how many turns the player has survived.)

Robot

• A robot 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 Robot to move.
• You may ask a Robot object for its position.

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 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, 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 other than the global constants already in the skeleton code, except that you may add additional global constants if you wish. 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 robot 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 robots.cpp that contains the source code for the completed C++ program. This program must build successfully, 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.

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

By Wednesday, June 3, there will be a 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.