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.

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.

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 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  yourself, as this will prevent your code from running on Gradescope.

•    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.

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:

•    [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.