Your goal in this lab is to design and write a program to play a game. This will be a graded lab which you'll work on in groups of two. First, carefully plan out your program. Before doing any programming, you should get your plan endorsed.
Plan your program
Your goal is to write a program to play a game. Your game will use a graphical interface. You will need to
decide on how the user will input to play the game.
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.
One way to develop classes is to get some index cards, using 1 card per class, with the class name in bold at the top.
Each card has a list of member functions and data members. (Data members 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 your game.
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
READMEwhich has the following:
- A list of authors.
- The rules for your game. Assume that the reader is not aware of the 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 auxiliary file and its purpose
I'll maintain a list of common issues and problems here.
random_points.cc reads characters from the
keyboard, and places those characters on random points in
cwin. It demonstrates how to address the
first few problems below.
How do I get input from the keyboard?
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
Makefileuses with care.
What if at compile time stuff is defined more than once?
Perhaps you included a header file more than once. Be sure you use
#defineto ensure including header files only once.
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
.hfile. Perhaps you left a
;off the end of a
How do I change the graphics window size?
In short, you can't. The graphics classes are limited for pedagogical reasons.
Submitting your code
Use Eclipse to export your project directory to a
zip file of the same name as your project, then
email me that
zip. Your project must include the
README file described above.