APSC 142 – Introduction to Programming for Engineers II
Objective:
Students will display their knowledge of all course material to build a complete computer 
program with a real-world application.
Problem:
The rules of the game are quite simple. The goal is for Pacman (the player) to collect all the dots 
on a map, while avoiding the enemy ghosts (AI) that are chasing you. The game is won when all 
the dots on the map have been collected. The game is lost when a ghost catches the player.
All characters in the game are bounded by that level’s map. The map contains walls (W) that 
restricts the characters from passing through them, creating a maze of sorts. The dots (.) are 
what need to be collected for the player to win the game. The characters can only travel 
through the paths between the walls. 
Below is the map that will be used in this project. The input text file will look slightly different, 
as it will show you the starting position for both Pacman and the Ghosts, and will not contain 
the outer walls. The primary map file is called “map.txt” and it is included in the starter code
which is available on OnQ.
APSC 142 – Introduction to Programming for Engineers II
Instructions:
Write a Pacman program in C that uses the following specifications:
• Read the map from a file called “map.txt” into an array created using malloc(). Make 
sure to implement correct memory management techniques for full credit. Your 
program must be able to read any map.txt file that is formatted correctly. There is an 
alternative “map2.txt” file included in the starter code, for example. Any file named 
map*.txt (where * can be any string) will be copied to the build directory to use upon a 
CMake reload.
• The map must contain exactly one Pacman (or player) ‘P’ and two Ghosts ‘G’. Their 
positions must be read from the map. If they aren’t present, or “map.txt” is not 
readable, the program must return appropriate error codes. The only other characters 
to be read from the map are ‘W’ for a wall, ‘.’ for a dot, or ‘ ‘ for an empty space. You 
should use #defines from defines.h to refer to these characters. All such characters in a 
map must have two spaces between them.
• Have the user enter an input of ‘w’, ‘a’, ‘s’, or ‘d’ that instantaneously moves the player
in that direction (up, left, down, right) if there is not a wall. You must get this input using 
the getch() function included in the starter code. If there is a dot in the new location, 
the player “eats” it and it is removed from the map.
• Implement 2 Ghosts (Enemies) to move around the map. If they can see the player 
(there are no wall tiles between them), have the ghost move toward the player.
o The ghosts are allowed to pass through each other.
APSC 142 – Introduction to Programming for Engineers II
o The ghosts should always move when the player does.
• You must implement some specific functions using the given prototypes and 
descriptions (these are listed below).
• The updated map must be printed to the console after every move. Unlike the map.txt 
file, which has two spaces between each symbol, you must print the map with one 
space between each symbol.
• You must write unit tests for your code. The tests must execute at least 85% of the lines 
of code included in the required functions.
• You must follow any other requirements written in the starter code, for example, using 
the provided global variables for storing map data (and no other globals).
• Use only the techniques and features taught in the course. If you use advanced or 
unexpected features, we may assume your code has been copied.
• When the win condition has been met, the following message must be printed:
o Congratulations! You win!
• When the loss condition has been met, the following message must be printed:
o Sorry, you lose.
Comments are mandatory for this project. Add comments as necessary for important parts of 
your code, such as function calls & definitions, conditions, and calculations to explain what the 
program is doing.
Global Variables 
Only the already specified global variables in the starter files are allowed.
The included globals will allow functions to access some commonly used variables without 
being passed as arguments. In practice, global variables should be used sparingly, so you are 
required to use only local variables for any other data.
Getting Started with the Starter Files
To get started, download the starter files in the zip file and unzip them into the directory you 
want to work out of. Then, in CLion, choose New Project in the project menu and make the 
following choices:
• In the left pane, choose C Executable.
• In the right pane, use the file picker to set the location to the directory where you
unzipped the starter files and leave the Language standard set to C11.
CLion will then pop up a modal dialogue that says Directory Is Not Empty and ask what
APSC 142 – Introduction to Programming for Engineers II
you want to do. Choose Create from Existing Sources. Then delete the main.c file from the 
project, as this will not be used and can create some confusion.
Mandatory Functions:
You must implement the following functions using the provided prototypes:
• int check_win(void);
• int check_loss(int player_y, int player_x, int ghosts_y[NUM_GHOSTS], int 
ghosts_x[NUM_GHOSTS]);
• char sees_player(int player_y, int player_x, int ghost_y, int ghost_x);
• char * load_map(char * filename, int * map_height, int *map_width);
• int is_wall(int y, int x);
• int move_player(int * player_y, int * player_x, char direction);
• int move_ghost(int * ghost_y, int * ghost_x, char direction);
• void print_map(void);
For each function, a detailed description of its expected behavior is provided in the comments 
in its respective header file: actor.h, game.h, and map.h. See those files and the main source 
file, apsc142project.c for details.
Other Important Details:
• Map details will be held in two different global maps: dot_map to hold where all the 
dots are and map that contains everything printed to the screen. Whenever you need to 
replace a dot in map (after a ghost moves over it), you will copy the contents from 
dot_map to map. Using the maps in this way is mandatory. The auto grader will not 
work if this convention is not followed.
o Note: It is a good idea to only rely on the map for tracking dots and walls. You 
will track of the position of the player and the two ghosts independently.
• The maps must be stored as 1D arrays. If you use a 2D array, you will not receive full 
marks. To use a 1D array (that is easy to allocate using malloc) like a 2D array, access 
elements using the index [(y * width) + x].
• To check if the win condition has been met, count the number of dots still in dot_map. 
This avoids the need to worry about if a ghost is covering a dot, since ghosts should not 
appear in dot_map.
• You can get a random integer between 0-3 with rand() % 4.
• The getch() function is available by including “colours.h”. Do not include <conio.h> 
yourself, as this will prevent your code from running on Gradescope.
APSC 142 – Introduction to Programming for Engineers II
• A good suggestion is to write tests before you implement your functions. This is called 
Test-Driven Development and it is a way to make sure your code does what you think it 
should, while ensuring good test coverage. Tests are required to get full marks in the 
final labs of this course.
Getting Terminal Emulation Working in CLion
When you first load the 
project starter code, you will 
want to modify the run/debug
configuration for the project
executable so that it emulates 
a terminal. This will cause the 
getch() function to behave as 
expected. To do this follow 
these steps (might vary 
slightly depending on your 
platform and CLion version):
 
Find the run/debug configuration dropdown to the left of the build/run/debug buttons in the 
top right corner of CLion. Click on “Edit Configurations…” at the bottom of that menu to bring 
up a modal dialogue. Select project under CMake Application on the left panel, then check the 
box next to Emulate terminal in the output console.
 
APSC 142 – Introduction to Programming for Engineers II
In-Lab Work
The final 4 lab sessions (weeks 9, 10, 11, 12) of the term will have deliverables for this project. 
The labs are designed so that you need to accomplish the first one or two tasks before you can 
move on to the next lab but it is “possible” to get by without question 3. If you do not complete 
a lab: it is highly recommended you finish all tasks before the next lab session. The lab tasks 
alone will not represent a fully completed project but do represent a passing grade. Any tasks 
that require you to modify functions have that function prototype written in bold text. The 
tasks will be released on a weekly basis but will follow what is given in the stater code. The 
general outline is:
1. Week 09: Print the map.
2. Week 10: Make the player move.
3. Week 11: Make the ghosts move.
4. Week 12: read a map from a file.
Submission Instructions:
Create your program using CLion, basing it on the provided starter code. Do not include any 
personal information (student number, name, etc.) in your submission. You will need to submit 
your code in a zip file containing all the .c .h .cpp and .txt files in your project. You must include 
all such files that appeared in the starter code to get full credit, even if you did not modify them 
from the starter code.
While developing your solution, you should submit your code to Gradescope, which will provide 
some automated test feedback, although your project will also be marked by a human. You can 
(and should) set up your group when you submit to Gradescope so that both members can see 
the feedback.
Refer to the project rubric in OnQ for a detailed breakdown of the grading criteria. Your 
submission must adhere to the project rules as outlined in the submission policy document for 
this course, which can also be found on OnQ. There is zero tolerance for plagiarism in this 
course. This auto grading software will automatically flag potential cases of plagiarism, which 
will be reviewed by the instructors.
Marking Rubric Summary
The official marking rubric can be found on OnQ, but it is summarized below. 
The project is marked out of 36 with each lab being worth 4 marks and the other 20 marks 
distributed as follows:
APSC 142 – Introduction to Programming for Engineers II
• [4] Required function implementation
◦ This tests that the required functions conform to their description in the starter files. 
This mark is based almost entirely on automated tests in Gradescope.
• [4] Test coverage of required functions
◦ This checks the percentage of lines of code in the required functions that are 
executed by your unit tests and is calculated almost entirely in Gradescope.
• [4] Code style and comments
◦ This checks that your code is well organized and documented properly, with good 
variable names. This is marked by a human.
• [4] Game functionality (calculated mostly in GradeScope)
▪ Winning and losing occur immediately when conditions are met.
▪ Valid maps are loaded correctly and displayed to the user.
▪ Ghosts chase player when they should.
▪ Dots disappear when they should and not when they shouldn't.
▪ Player and ghosts move and respect walls.
▪ Proper error codes are returned when maps are invalid.
• [4] Secure coding practices
◦ This checks that your program follows secure best practices and does not contain 
undefined behavior. This is calculated from a combination of GradeScope and 
manual checks.

請加QQ：99515681  郵箱：99515681@qq.com   WX：codinghelp