Robots game

Your goal in this lab is to design and write a program to play robots. This will be a graded lab which you'll work on in groups of two. (You may work on your own if you ask for approval in advance.) First, carefully plan out your program. Before doing any programming, you should get your plan endorsed.

Play robots

The UNIX program robots predates the ubiquitousness of graphical interfaces, so you have to play using keyboard input.

In Emacs, type M-x man (for manual-page), and enter -M ~mc38/man robots. This gives your directions on how to play. (The -M ~mc38/man part says ``Please look for the man page in the MC38 directory.'')
In a Unix shell window, type ~mc38/bin/robots.

Plan your program

Your goal is to write a program to play this game. Your game will use a graphical interface, and need not include all the options in the Unix version. You need not include a score file. But you will need to decide on how the user will input decisions on where to move and how to teleport.

Just as Horstmann plans out the Clock game in chapter 8, you should plan out your program. You should have at least two classes (probably more), and should plan on most of your code being in member functions (as opposed to non-member functions).

Decide in advance what order you will write your classes and functions. You don't need to program a whole class all at once. On the contrary, I recommend coding part of it, testing a bit, and continuing. Plan how you will test as you go along.

Each card has a list of member functions and instance variables. (Instance variables are the private variables.)
One additional card lists non-member functions (if any) along with the purpose of each.
Number all member functions and procedures in the order you intend to code and test them. You'll put the number (1) in front of all methods and procedures you can test on their own without writing any others. Put a (2) in front of procedures you can't write until you've written procedures from (1), and so forth.
Identify with a (*) all methods which appear challenging to write. These are ones which you hope you can break up later into smaller procedures once you've thought about the robots program more.

You must get your plan endorsed before continuing.

Write a working program

Write a program to play the game. Be sure that the code is clean, and that all procedures are short and clear. (If you have time, feel free to add whatever features you think would enhance or personalize your program, but be sure your code is clean before embarking on ambitious plans.)
Rather than documenting each little member function, place documentation for the class in the class's header file. So each class declaration will have at least one header comment, and each non-member function will have at least one header comment.
Write a file called README which has the following:
- A list of authors.
- The rules for your game. You may assume that the reader already knows how to play the built-in robots game.
- A list of bugs in your program,
- Any large-scale information that would help me understand your code,
- A brief summary of each class and its purpose.
- A brief summary of each auxilary file and its purpose.

Common problems

We'll maintain a list of common issues and problems here.

The program ~mc38/labs/robots/random_points.cc reads characters from the keyboard, and places those characters on random points in cwin. It demontrates how to address the first few problems below.

How do I get input from the keyboard?
See ~mc38/labs/robots/random_points.cc
In particular, you need the system ("stty raw"); to let the computer know you want to read a character as soon as it's typed, and not wait for the "return" or "enter" key to be hit.
How do I get the screen to update?
Stuff isn't drawn until either (1) you do something like a cwin.get_point() or (2) you return from main() or (3) there are many things that need to be drawn (filling a buffer). If you include a loop which draws 50 points off the screen, the window will be forced to redraw.
```
      for (int i = 0; i < 50; i++)
         cwin << Point (-15,-15);
```
What if the compiler gives a ton of warnings at link time?
Maybe you forgot to include a library like -lX11. Check the compilation command your Makefile uses with care.
What if at compile time stuff is defined more than once?
- Perhaps you included ccc_win.cpp more than once. Be sure this is only included at the top of main(). Elsewhere, include ccc_win.h instead.
- Perhaps you #include a .cc file. Only #include .h files. (Except, #include ccc_win.cpp at the top of main.cc)
Why can't I make a vector of objects?
Perhaps you don't have a default constructor for that class, i.e., one which takes no arguments.
What if I have a very mysterious error near the top of a file?
Check the end of an included .h file. Perhaps you left a ; off the end of a class declaration?
How do I change the graphics window size?
In short, you can't. The graphics classes are limited for pedagogical reasons. The book describes all graphics classes in the appendix.