代写APSC 142、代做C/C++程序设计

项目预算：开发周期：发布时间：要求地区：

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