In this project you will write a program that uses arrays to store and process data. Your program will simulate an automobile race with just one car. (Not very exciting to watch is it?) The car will move around the track in a predictable way, always turning just before it hits a wall. The car starts off with a certain amount of fuel, which is used up as it travels. The track will contain oil slicks (drawn as '*' symbols) and some fuel supplements (drawn as 'F' symbols). When the car encounters an oil slick, the oil slick will disappear from the track, and the car's direction will change abruptly. When the car encounters a fuel supplement, the fuel supplement will disappear from the track, and the car's fuel supply will be increased. (Each fuel supplement will increase the fuel supply by a different amount - explained later). The car will leave behind its own oil slicks from time to time. The race is over when the car either runs out of fuel, or completes a pre-determined number of laps.
If all goes well, the output from your program will appear to be a real-time animation of the race. Below is a snapshot of a typical race at one point in time:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@ F X | @@@@@@ @@@@@ | * @@@@@ @@@ | @@@ @@ | * @@ @ F @@@@@@@@@@@@@@@@@@ @ @ @@@@@@@@@@@@@@@@@@ @ @@ * @@ @@@ F @@@ @@@@@ * @@@@ @@@@@@ @@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The `@' symbols are walls surrounding the track.
The '|' symbols represent the finish line.
The 'F' symbols are fuel supplements.
The '*' symbols are oil slicks.
Finally, the 'X' is the car!
The following files are provided in your instructor's posting account:
race.x animation_input primary_input primary_output
Copy all of these files into your own account. (By now you should know how to do this. If you don't know, drop by TA office hours.) When you are done with the project, your executable should work just like ``race.x''.
To see the program work, type:
race.x < animation_input
You should see an animation of a one lap race.
As with previous projects, the input for your program will be read from a file using Unix redirection. Below are the contents of the primary input file which we have given you:
12 38 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@ | @@@@@@ @@@@@ * | X @@@@@ @@@ | @@@ @@ | * @@ @ @@@@@@@@@@@@@@@@@@ @ @ @@@@@@@@@@@@@@@@@@ @ @@ * @@ @@@ @@@ @@@@@ * @@@@ @@@@@@ @@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 3 1 9 20 5 6 25 8 30 35 1 N
You may assume (without checking) that all of the numbers that appear in the input stream will be integers. (There are no floats at all in this project.)
The first two numbers (in this case 12 and 38) describe the dimensions of the track area. (In this case: 12 rows and 38 columns). Important: The dimensions of the track will never exceed 57 units in either direction. You may also assume that each dimension will be at least 4 units.
After the dimenions, the input file includes the grid
of characters that represent the shape of the track. '@' symbols represent
the walls, '*' symbols represent oil slicks, '|' symbols represent the
finish line. The 'X' represents the starting position of the car.
Hint: Don't forget that every line in the input file ends with
a newline character. If you are reading in one character at a time,
you will need to carefully remove the newline character after each line.
After the picture of the track, you are given data about the fuel supplements that will be provided at the start of the race. They will be scattered around at various locations on the track.
The first value (in this case 3) specifies the number of fuel supplements that this particular race will start with. Important: The race will never start with more than 40 fuel supplements on the track.
Next you will find one line of data for each fuel supplement. For each fuel supplement you are given the location coordinates and the amount of fuel that is available at that location. In the example above, the first fuel supplement is located in row 1, column 9, and contains 20 units of fuel. When you draw the track you will represent the location of these fuel supplements by drawing an 'F' symbol.
Just after the fuel supplement data, you will see a number. (In this case it is a 1.) This number represents the number of laps that the car must complete around the track. (More about that later.)
The last data element in the file represents a flag (either 'Y' or 'N') that will indicate whether or not the program should show every frame in the animation, or just show the track once at the end of the race. (We'll say more about this flag later.) Hint: Don't forget that the previous line ended with a newline character. You may have to remove this character before reading in the animation flag.
Important: The coordinates of the track should be envisioned as below. (Note that we are using 0-based indexing). The 'F' indicates the position row 1, column 9, where the first fuel supplement is located in the primary input case.
0 1 2 3 4 5 6 7 8 9... 0 1 F 2 3 4 . . .
If the car wants to move to the Left, but there is a wall there, it will change its direction to ``Down''.
If the driver wants to move Up, but there is a wall there, it will change its direction to ``Left''.
If the car wants to move Right, but there is a wall there, it will change its direction to ``Up''.
If the car wants to move Down, but there is a wall there, it will change its direction to ``Right''.
Note that you may need to apply more than one rule for a particular
movement.
As an example, consider the diagram below. Imagine that the car is
indicated by the 'X' and wants to
move LEFT.
@ @ @@X @@@@ @@@@@@@@
Since it cannot move left, it changes its mind and decides to move down. Unfortunately, it cannot move down either, so it changes its mind again and decides to move to the right. The subsequent frame would look like this:
@ @ @@ X @@@@ @@@@@@@@
You may assume that the car will never be trapped on all sides like this:
@@@ @X@ @@@
If the car has just moved LEFT onto an oil slick, its direction on the subsequent movement will be UP.
If the car has just moved UP onto an oil slick, its direction on the subsequent movement will be RIGHT.
If the car has just moved RIGHT onto an oil slick, its direction on the subsequent movement will be DOWN.
If the car has just moved DOWN onto an oil slick, its direction on the subsequent movement will be LEFT.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@ * | @@@@@@ @@@@@ | * @@@@@ @@@ | @@@ @@ * | * @@ @ @@@@@@@@@@@@@@@@@@ @ @ @@@@@@@@@@@@@@@@@@ @ @@ @@ @@@ * X F @@@ @@@@@ * @@@@ @@@@@@ @@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@ * | @@@@@@ @@@@@ | * @@@@@ @@@ | @@@ @@ * | * @@ @ @@@@@@@@@@@@@@@@@@ @ @ @@@@@@@@@@@@@@@@@@ @ @@ @@ @@@ * X F @@@ @@@@@ * @@@@ @@@@@@ @@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@ * | @@@@@@ @@@@@ | * @@@@@ @@@ | @@@ @@ * | * @@ @ @@@@@@@@@@@@@@@@@@ @ @ @@@@@@@@@@@@@@@@@@ @ @@ @@ @@@ * X F @@@ @@@@@ * @@@@ @@@@@@ @@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Important: To get this to look like an animation on your screen, you will need to slow the computer down. To accomplish this, insert the following line so that it will be executed once after each time the track is drawn during animation mode:
usleep(300000);
This instruction tells the computer to ``sleep'' (i.e. do nothing) for 300000 microseconds. (A microsecond is one millionth of a second.) You may want to change this number to either speed up or slow down the animation. If it doesn't look smooth on your screen, try slowing it down by using a larger value.
IMPORTANT: BEFORE YOU SUBMIT YOUR PROGRAM, TAKE OUT ALL CALLS TO THE USLEEP FUNCTION. OTHERWISE WE CANNOT GRADE YOUR PROJECT.
To see your output as an animation, you should use Unix redirection for your input, but send your output to the screen. For example:
% a.out < animation_input
You will need to keep track of the number of times the car actually crosses over the finish line. Note that the car will cross the finish line once just as the race begins. That means that if the race is supposed to go on for four laps, then the race will end just after the car has reached the finish line for the fifth time.
Here is what must transpire each time through this big loop. (It is important that things happen in the exact order listed below.)
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. 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.
IMPORTANT: BEFORE YOU SUBMIT YOUR PROJECT, TAKE OUT ANY LINES WHERE YOU HAVE USED ``USLEEP''. OTHERWISE YOUR PROJECT CANNOT BE GRADED.
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 ``p4.c'', submit would be run as
submit 4 p4.c.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.61)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -show_section_numbers -split 0 -no_navigation -no_footnode project4
The translation was initiated by Fawzi Emad on 2003-10-18