| CMSC 106 | Project #4 | Spring 2001 |
In this project you will write a program which uses arrays to store and process data, and which reads input until the end of file or a specific value is seen.
Your project will be a game to play where you give directions to an explorer who will travel around a grid looking for treasure. As he finds the treasures, he puts them into his pack collecting points. His goal is to collect as many points as possible before the end of the game. One problem is that there are also bombs scattered through the grid. If he finds a bomb, he dies immediately. At the end of the game, the game will report if the explorer suvived or not and a summary of the treasures he collected before he died or (if he didn't die) before the game ended.
The game board will have some squares that are empty (-), some contain a wall (W), some which contain a bomb (B) and some have a treasure. The treasure will be either silver (S), gold (G), emeralds (E), rubies (R), diamonds (D), cat's eye saphires (C) and platinum (P). Each type of treasure is worth a different number of points. The number of points for each type of treasure will be determined by the order they are listed in the gameboard setup file. The treasure listed first is worth 1 point, the second is 2 points, etc. The treasure is gone from a square if he has picked it up - so if he visits that same square again later in the same game, the square is empty (contains a ``*'' to indicate he has been there). The gameboard (exploration area) should be viewed as a spherical surface meaning that if you step off the board on one side you will go to the opposite side of the board.
As you read this section, you may also want to refer to the ``Sample output'' section below.
Your program will read the game board setup from one ASCII text file
and then the player's moves from a second ASCII file. The files will
both be read input the program using standard input redirection.
Because the input needs to come from two separate files in sequence,
the < standard input redirection can not be used. Instead you
will use a shell command in the following form. (This assumes the
board's description is in a file named boardfile and the player's moves
are in a file named moves, and the executable version of your program
is in the file named hunt.x.)
% cat boardfile moves | hunt.x
The first input file will have description on how the board is set before
the explorer begins moving and the description of how many points each of
the treasures will receive. The first line of that file will contain
two integers which will tell the size of the board (the width first followed
by the height). Neither dimension of the board will be smaller than 2 or
greater than 20. You do not need to check these values for validity.
At this point, the content of the game board (of the indicated
size) should be assumed to be all empty squares (``-''). These empty squares
are safe for your explorer to travel through, but he does not gain any points
as he goes either. After reading the size of the board, the program should
echo that it is setting up a board that is ``height X width'' - the line must
include the word Board followed on that same line by the height
followed immediately by an ``X'' which is followed immediately by the width.
Each of the next lines in the first input file
will contain two integers
followed by an individual character (delimited by whitespace).
The character will tell what is being positioned
on the board (B for bomb, W for wall, or one of the single letters from
above for each of the treasures).
The integers will tell the position on the board
where that item should be placed.
The top lefthand corner of the board
is known in these dimensions as 1 1. The first number tells
which row and the second tells which column. For example, the 3 5
position is the third row from the top and the fifth column from the left.
If there is nothing wrong with that line, the game board should be modified to
reflect the change, but nothing should be printed to the screen.
You will know that you are done setting up the board when the character at the end of the line is an ``X''. When the X is read, you should print a line saying that the board is set. This one line must include the word ``board'' followed by the word ``set''.
If there is a line in the first input file whose data
is not appropiate for the
board you must print an error message. The line of the error message
must begin with the word ``ERROR:'' followed by the details of the error
read from the input file. If the error is that the letter (last chracter)
is inappropriate (not B, W, S, G, E, R, D, C, P or X),
you must echo that letter
followed by the word ``invalid''. If the position is invalid, you must echo
both numbers in the order read followed by the word ``invalid''. One
additional restriction is that nothing can be placed in square with
coordinates 1 1 since the explorer will need to step onto the
board there before play actually begins. If the coordinates 1 1
is specified during the board setup it should be called invalid the
same as positioning something off the indicated size board.
After the configuration of the gameboard is set, there should be seven additional lines telling the relative values of each of the seven treasures. There will be 7 lines, and the 7 lines will each contain one character S, G, E, R, D, C or P. The only thing you are looking for is the order these 7 things appear. The treasure listed first is worth one point toward your total, the second is worth 2 points, ... to the last one listed being worth 7 points for each occurence. You do not need to check those 7 lines - you can assume they will contain each of the treasures on its own line (make sure any input files you create has these 7 lines as described here. You should store the order these characters were read so you can use that to tell what number of points are associated with that treasure. You should store these 7 in an array and have a parallel array which will keep track of the quantity of that treasure found on your explorations.
Before the playing of the game can start, the gameboard should be printed to the screen so that the top left (square 1,1) is in the top left corner. There should be one and only one character printed for each square of the gameboard. It must be printed so that rows are horizontal and columns are vertical.
Once the board is setup, the explorer must first step onto the board (even before any move is read from the second input file). He steps onto the board in the top left corner. This is then his starting point for exploration.
As the explorer moves through the board, the square where he was is changed to an asterisk (star ``*'') so we will be able to see the path he traveled when the game is over. This is true except when he steps into a square that has a bomb - in this case the square is changed to an exclamation point ``!'' to indicate his point of death.
Each line of the second input file will have a single integer. If the integer is smaller than 1 or larger than 9, it is considered an invalid line and an error message should be printed including the word ``ERROR:'' at the beginning of the line followed by the words ``invalid input''. If the integer is between 1 and 9 inclusively, the input is indicating the direction of an attempted move.
The direction is indicated as 1=southwest, 2=south, 3=southeast, 4=west, 5=stay (no move), 6=east, 7=northwest, 8=north, 9=northeast or graphically it would look like:
7 8 9 \ | / \|/ 4--5--6 /|\ / | \ 1 2 3
If you attempt a move in the direction indicated, there are the following possibilities. One and only one line of output should be printed for each and every input from the second input file.
The end of the input for this second file will be marked only by the end of file marker (there is no sentinel value marking this second input like there was for the setup of the gameboard in the first input file).
Once the end of file is reached or the explorer has hit a bomb, the game ends by printing the summary lines. The first line of the summary must contain the word ``Summary''. The second line must either contain the word ``dead'' or the word ``alive'' (the one that correctly represents the explorer's condition at the end of the game). The third line must contain the word ``points'' followed by the total number of treasure points you have collected during this run of the game. After the total number of points, each of the treasures should be listed in the order of their value (least valuable to most valuable) followed in a column by the quantity of that item collected while you played the game.
After printing the summary lines, the gameboard should again be displayed. The only change from the one displayed originally is that the path the explorer traveled will be marked with stars (``*'') and, if there was a point of death, it would be marked with an exclamation point (``!'').
All your C programs in this course should be written in ANSI C, which
means they must compile and run correctly with cc -std1 -trapuv
on the OIT
UNIX Class Cluster. You will lose credit if your program generates any
warning messages when it is compiled. Even if you already know what they
are, you may not use any C language features other than those introduced
in Chapters 1 through 8 of your textbook, plus those presented in lecture
while these chapters were covered. Note that as a result user-defined
functions may not be used. In addition, although they are covered in the
allowable chapters, neither the goto nor the continue
statement may be used, and the break statement may not be used in any
loop. Lastly, your program must contain only one single return
statement at its end, and may not use the exit() library function at
all. Using C features not in these chapters, or using the goto
statement, the exit() library function, multiple returns, or
break or continue in loops, will result in losing
credit.
Your program must have a comment near the top which contains your name, login ID, student ID, your section number, your TA's name, and an original description of the action and operation of the program. Do not put your alias in this comment! Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:
You may want to skip this section at first, read the rest of the project, and come back to study it carefully when you are about to begin writing your program.
Even if you didn't need to refer much to the methods presented in the corresponding sections in the earlier project assignments, you will need to begin reading these carefully now because as the assignments get larger and more complex these techniques for debugging and program development will become indispensable. Remember, one of the important topics you must learn in this course is how to track down and fix both syntax and semantic errors in your code. You will need to follow the procedures described, as well as be able to describe an error and what you have already done to find it, and bring a printout of your source code if you need to come for assistance with it during office hours.
These steps are a suggestion only; you can follow others if you prefer, since there are many ways to develop any program. However, whatever steps you do choose, you should be certain to write small parts of your program at a time and test each one to verify that it works before going on!
#define
If every line (or most lines) which use a symbolic constant is flagged as an invalid statement, the error is most likely in the definition of the constant itself.
The most common error in C programs with arrays is using invalid subscripts to refer to array elements (falling off one edge or other of an array).
Getting this error when a program runs usually means it has
referred to an invalid area of memory, which is often caused by
incorrect array subscripts. To find the problem, add debug
printfs to narrow down where in your program the problem
occurs. Before every reference to an array element appearing in
that section of code you can add debug printfs which
display the values which will be used as subscripts. For
instance, if your code contains a statement like
printf("%d", array[i][j]);
|
then add test statements above it to print the values of i
and j. Verify by running the program that i is not
larger than the maximum row subscript for the array, and j
is not larger than the maximum column subscript. Falling off an
edge of the array won't necessarily lead to a core dump, it may
just cause incorrect results.
\n for debug printfs
For technical reasons, all debug printfs used must end in
\n. Otherwise, if your program has a core dump, some (or
all) of the debug print results may not be displayed before the
program halts, defeating the purpose of adding the debug
printfs.
A core dump creates a file named "core" which contains the contents of your memory space at the time of the program crash. This file can get large and is not useful at all for our purposes, so it should be removed before going on to prevent exceeding your quota of disk space.
Any evidence of unauthorized use of computer accounts or cooperation on projects will be submitted to the Student Honor Council, which could result in an XF for the course, suspension, or expulsion from the University. Projects are to be written INDIVIDUALLY. For academic honesty purposes, projects are to be considered comparable to a take-home exam. Any cooperation or exchange of ideas which would be prohibited on an exam is also prohibited on a project assignment, and WILL BE REPORTED to the Honor Council.
VIOLATIONS OF ACADEMIC HONESTY INCLUDE:
|
IT IS THE RESPONSIBILITY, UNDER THE UNIVERSITY HONOR POLICY, OF ANY STUDENT WHO LEARNS OF AN INCIDENT OF ACADEMIC DISHONESTY TO REPORT IT TO THEIR INSTRUCTOR.
Your project must be electronically submitted by the date above to avoid losing credit. No projects more than two days late will be accepted for credit without prior permission or a valid medical excuse, as described on your syllabus. Only the project which you electronically submit, according to the procedures provided, can be graded; it is your responsibility to test your program and verify that it works properly before submitting. Lost passwords or other system problems do not constitute valid justifications for late projects, so do not put off working on your program or wait to submit it at the last minute!
Turn in your assignment using the ``submit'' program as before, except
using ``4'' for the project number. You are to submit only the .c file
containing your source code, not the executable version of your program!
If your program is in a file named ``hunt.c'', submit would be run as
submit 4 hunt.c.
Before you submit your project, you must exactly follow the specific submission checklist in the ``Testing projects before submitting'' handout separately posted by your instructor!
Assuming the name of the executable version of the program is ``hunt.x'', here is a sample execution for one input data set. The content of the input files are shown as displayed by the UNIX ``cat'' command. Following the data files contents, the results of running the program is shown. The data files shown here will be considered the ``primary input'' (and ``it's corresponding output'') for grading purposes.
Be sure to test your program against a variety of inputs, so you are sure it works in all circumstances!
|