| CMSC 106 | Project #4 | Fall 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 an extension of the Sokoban game of Project 3. Using arrays, you will be able to use more interesting game boards, and you will be able to handle more than one box and target location. As before, the player will move within a grid of points surrounded by walls. The program will read and process a series of moves for the player until it reaches the end of the input.
As you read this section, you may also want to refer to the ``Sample output'' section below.
Following this line will be a series of lines representing the squares of the game board. Each row will contain a series of characters:
Note that the game board will be inside a rectangle of the given size, but there may be some points of the rectangle which are actually outside the playing area. All points outside the playing area will be empty. There will be no blanks between items in a row, but there may be 1 or more blanks at the end of a row. If the number of rows and columns in the first input line is valid, then the number of rows to be read will equal the first number read in the first input line, and the number of items in each row will equal the second number read in the first input line. The program may assume that there will always be exactly 1 player. There will be no limit to the number of boxes or goals, other than the number of available locations on the game board.
The next line will contain a list of moves for the player. Each move will be represented by a single character:
The program will continue reading and processing moves until it reaches the end of the input file.
After the program has read in and checked the game board setup, it will start processing the moves for the player. The basic rules for moving the player are the same as in Project 3:
Note that since there may be multiple boxes, a box may also be blocked by another box. This means that only one box may be pushed at a time.
As each move is read, the program must check whether it is valid, as in Project 3. If the player is blocked from moving by a wall, or a box is blocked by a wall, the program must print out the appropriate message, as in Project 3. However, if a box is blocked from moving by another box, the program must print a new message:
Box blocked by box moving M at r c!
where M is L for left, R for right, U for up, or D for down,r is the row and c is the column for the player's current position.
(Rows and columns are numbered starting with 1, as in Project 3.)
The program must also keep a count of the number of successful moves and the number of successful pushes of a box. A move is counted as successful if the player moves into an empty square (including a goal). A move is counted as a successful push if the player moves into the square previously occupied by a box, moving the box to the next square. Note that any particular move is considered either a successful move or a successful push, but not both.
After the end of the input has been reached and the last move has been processed, the program must print the message:
********** Final Board **********
preceded by a blank line. Following the message, the program must print out the final game board configuration. The game board is printed using the same characters used for the input, including the asterisk ('*') for a box located on a goal. (If the player is located on a goal, that location is simply shown as 'O'). Following the game board configuration, the program must print the message:
Moves: m, Pushes: p, Points n
where m is the number of successful moves, p is the number of successful pushes, and n is the number of points. One point is scored for each box which is located on a goal at the end of the game. If a box is located on every goal, the program must also print the message:
Congratulations, you have solved this level!
on the next line. (Note that there may be more boxes than goals, or more goals than boxes.)
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.
Points will also be deducted for excessive amounts of duplicate code.
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 ``game.c'', submit would be run as
submit 4 game.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 ``game.x'', here is a sample execution for one input data set. The content of the input file is shown as displayed by the UNIX ``cat'' command. Following the data file 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!
|