辅导ECS 36A程序、Programming编程设计辅导、C/C++程序讲解 讲解数据库SQL|讲解SPSS
- 首页 >> Matlab编程 ECS 36A: Programming Assignment #7
Fall 2020
Contents
1 Changelog 1
2 General Submission Details 1
3 Grading Breakdown 1
4 Submitting on Gradescope 1
4.1 Regarding Autograder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.1 Game Files by Visible Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.2 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.3 Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5 Game 2
1 Changelog
You should always refer to the latest version of this document.
• v.1: Initial version.
• v.2: Added statement in red: “You may assume that the user only enters one character at a time.”
• v.3: Autograder details.
2 General Submission Details
Partnering on this assignment is prohibited. If you have not already, you should read the section on
academic misconduct in the syllabus.
This assignment is due the night of Monday, December 14. Gradescope will say 12:30 AM on Tuesday, December 15, due
to the “grace period” (as described in the syllabus). Be careful about relying on the grace period for extra time; this could be
risky.
You should use the -Wall and -Werror flags when compiling. The autograder will use these flags when it compiles your
program.
3 Grading Breakdown
The autograder score will be out of 120 points.
4 Submitting on Gradescope
You should only submit game.c. You may be penalized for submitting additional files. You have infinite submissions until
the deadline.
During the 10/02 lecture, I talked about how to change the active submission, just in case that is something that you
find yourself wanting to do.
∗This content is protected and may not be shared, uploaded, or distributed.
1
4.1 Regarding Autograder
Your output must match mine exactly.
There is a description about how to interpret some of the autograder error messages in the directions for the previous
two programming assignments. I will not repeat that description here.
The autograder uses the same main.c file that was used in the examples.
As always, make sure to compile on the CSIF if the autograder reports that you have compiler error messages even though
you don’t find compiler error messages on your end.
4.1.1 Game Files by Visible Test Case
Case Number Game File
1 game files/game4.txt
2 game files/game5.txt
3 game files/game6.txt
5 game files/game6.txt
7 game files/game6.txt
9 game files/game4.txt
11 game files/game4.txt
12 game files/game1.txt
14 game files/game10.txt
15 game files/game10.txt
16 game files/game10.txt
17 game files/game10.txt
19 game files/game3.txt
21 game files/game2.txt
4.1.2 Inputs
For each test case, I uploaded a text file containing the inputs. You can use input redirection (from chapter 6 of your
Linux reading); for the larger test cases, this is more convenient than typing all of the inputs in, as some of the cases enter
at least 100 inputs.
4.1.3 Memory Leaks
Two of the test cases (#19 and #20) check for memory leaks.
5 Game
For this assignment, all that you have to do (in game.c) is implement one function: the function playGame() that is declared
in game.h. You will only submit game.c, so any changes that you make to game.h will be ignored. The function
playGame() should load data from the file whose name is passed to it and then allow the user to play a game. In this game, the
player is represented by a single character on a board. In the below, the asterisks form the border of the board, the A is the
player’s icon, each X represents an enemy, the * (in the middle of the board) represents a “power orb”, and each $ represents
an item. There are also two buildings on the board.
playGame() reads the contents of the board from a file. Below is the file that corresponds to the above board. You may
assume that the input file is properly formatted; input validation is not a part of this assignment.
First two lines: The first line contains the dimensions (height and width, respectively) of the board, not counting the
borders (i.e. the asterisks). The second line contains the five keys that the user will use to move left, move right, move
upwards, move downwards, and quit (respectively). It is possible that this line of the file is empty, in which case a set of
default keys (left: ‘a’, right: ‘d’, up: ‘w’, down: ‘s’, quit: ‘q’) should be used. Either all five keys will be provided, or none
will be provided.
Player line: The third line starts with the default icon used to represent the player. In the above file, this is ‘A’, which
is why A was the player’s icon in the above map. The ‘B’ is the powered icon, which I talk more about below. Then, there
are the starting coordinates (y-coordinate and x-coordinate, each zero-based) of the player. Note that a y-coordinate of 0
corresponds to the top row of the board, not the bottom row. Also note that the player’s icon could be the same as the
item’s icon.
Bulding, enemy, item, and power orb lines: The game file will always have at least one item (you may assume this),
but it may have zero buildings, zero enemies, and/or zero power orbs. At this point in the file, you will have the lines for
the buildings (if any, and each starting with a ‘B’), followed by the lines for the enemies (if any, and each starting with an
‘E’), followed by the lines for the items (each starting with an ‘I’), followed by the lines for the power orbs (if any, and each
starting with a ‘P’). For each of these kinds of lines, the special character is followed by the coordinates. Like the player,
each of an enemy, an item, and a power orb take up one spot. A building always looks the same as you see it in the example
above. That is, a building is always a 4-by-6 block of dashes, except for a “door” built with ampersands in the middle of
it. In the case of a building, the provided coordinates locate its top-left. You may assume that there are no overlapping
elements, e.g. there won’t be an item inside of a building. You may assume that everything is in bounds, e.g. there won’t be
a building that is halfway outside the boundaries of the board.
End conditions: The game ends when any of the below conditions occur. Depending on which end condition is
achieved, your program should print a specific message; see the examples below. The player is always shown their ending
score. Moreover, if the player loses by dying, then the board is shown one extra time; one of the examples emphasizes this.
• The player quits using the quit key.
• The player wins by collecting all of the items.
• The player dies.
Input and collision detection: When prompting the user for input, if they do not enter one of the four movement keys
or the quit key, then they should be prompted again (see the examples below). You may assume that the user only enters
one character at a time. Each movement key attempts to move the player one unit in the indicated direction. Certain events
occur based on what the player interacts/collides with:
• Borders: The player is prevented from going through the board’s borders.
• Building: The player is prevented from going through the building.
• Item: The player collects the item, removing it from the game.
• Power orb1
: When the player touches a power orb, they enter “power mode”. While they are in power mode, their
icon is the powered icon that was mentioned above, instead of the default icon. They remain in power mode during
their next 7 inputs. This duration is reset/replenished (back to 7) if they touch another power orb during this time.
Note that during the last input in which the player is in power mode, their power mode should run out immediately
after they enter their input / before collision detection is done; see one of the examples below, where I specifically
comment about this. Also note that the duration goes down even if the player’s input is wasted, e.g. if they spent the
next 7 inputs trying to move into a wall (and thus move nowhere), then the power mode will expire.
• Enemy:
– If NOT in power mode (default): The player dies, and the game ends. As stated in the end conditions above, the
board should be printed one more time in this case, and the player’s icon will be a @ (that’s the character that I
felt most looked like an explosion).
– If in power mode: The player removes the enemy from the game.
1Power orbs mimic the behavior of “power pellets” in the game Pac-Man.
3
Indicators: As you can see in the examples, I’m always shown the current score and the number of items remaining.
The score is incremented whenever an item is collected or (while in power mode) an enemy is destroyed/eaten2/collected.
Here are some suggestions that you may or may not find helpful:
• After performing some setup, your game could go to what we will call its “main loop”, which is the loop that keeps the
game going until an end condition is satisfied. In each iteration of this loop, the game should be drawn, and then user
input should be obtained, and then updates (movement, collision detection, etc., where applicable) should be performed.
• I would start small and make sure things still work as you make gradual, carefully thought out changes. An example of
this would be to start with a file that only contains the bare minimum requirements, i.e. the first three lines and then
a single item, all on a small board. Don’t try to type a lot of code at once without pausing to check if any of it works.
• I used a lot of helper functions to organize my code when I thought it would help me think about the different steps.
Here are examples of helper functions that I had: setupBoard(), loadKeys(), drawBuilding(), getInput(). Each helper
function identifies a clear step, and this helped me to write my solution in a methodical manner.
• I lost a bit of time dealing with that the second line could be blank because I was using a mix of fgets() and fscanf()
to read the file. If you put a newline character at the end of the format string of fscanf() and there are two newline
characters in a row (which occurs when the second line is blank), fscanf() will read both (not just one) of those newline
characters (after reading whatever else it was supposed to read according to the format string).
Memory leaks: Your program should have none, and you should close any files that are opened.
Below is a list of headers that you are allowed to include in game.c. You may not need all of these.
• game.h
•
•
•
•
•
•
•
Below are examples of how your code should behave. You can find all of the demo files (e.g. main.c, game2.txt) on Canvas.
1 $ cat main .c
2 # include " game . h"
Fall 2020
Contents
1 Changelog 1
2 General Submission Details 1
3 Grading Breakdown 1
4 Submitting on Gradescope 1
4.1 Regarding Autograder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.1 Game Files by Visible Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.2 Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1.3 Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5 Game 2
1 Changelog
You should always refer to the latest version of this document.
• v.1: Initial version.
• v.2: Added statement in red: “You may assume that the user only enters one character at a time.”
• v.3: Autograder details.
2 General Submission Details
Partnering on this assignment is prohibited. If you have not already, you should read the section on
academic misconduct in the syllabus.
This assignment is due the night of Monday, December 14. Gradescope will say 12:30 AM on Tuesday, December 15, due
to the “grace period” (as described in the syllabus). Be careful about relying on the grace period for extra time; this could be
risky.
You should use the -Wall and -Werror flags when compiling. The autograder will use these flags when it compiles your
program.
3 Grading Breakdown
The autograder score will be out of 120 points.
4 Submitting on Gradescope
You should only submit game.c. You may be penalized for submitting additional files. You have infinite submissions until
the deadline.
During the 10/02 lecture, I talked about how to change the active submission, just in case that is something that you
find yourself wanting to do.
∗This content is protected and may not be shared, uploaded, or distributed.
1
4.1 Regarding Autograder
Your output must match mine exactly.
There is a description about how to interpret some of the autograder error messages in the directions for the previous
two programming assignments. I will not repeat that description here.
The autograder uses the same main.c file that was used in the examples.
As always, make sure to compile on the CSIF if the autograder reports that you have compiler error messages even though
you don’t find compiler error messages on your end.
4.1.1 Game Files by Visible Test Case
Case Number Game File
1 game files/game4.txt
2 game files/game5.txt
3 game files/game6.txt
5 game files/game6.txt
7 game files/game6.txt
9 game files/game4.txt
11 game files/game4.txt
12 game files/game1.txt
14 game files/game10.txt
15 game files/game10.txt
16 game files/game10.txt
17 game files/game10.txt
19 game files/game3.txt
21 game files/game2.txt
4.1.2 Inputs
For each test case, I uploaded a text file containing the inputs. You can use input redirection (from chapter 6 of your
Linux reading); for the larger test cases, this is more convenient than typing all of the inputs in, as some of the cases enter
at least 100 inputs.
4.1.3 Memory Leaks
Two of the test cases (#19 and #20) check for memory leaks.
5 Game
For this assignment, all that you have to do (in game.c) is implement one function: the function playGame() that is declared
in game.h. You will only submit game.c, so any changes that you make to game.h will be ignored. The function
playGame() should load data from the file whose name is passed to it and then allow the user to play a game. In this game, the
player is represented by a single character on a board. In the below, the asterisks form the border of the board, the A is the
player’s icon, each X represents an enemy, the * (in the middle of the board) represents a “power orb”, and each $ represents
an item. There are also two buildings on the board.
playGame() reads the contents of the board from a file. Below is the file that corresponds to the above board. You may
assume that the input file is properly formatted; input validation is not a part of this assignment.
First two lines: The first line contains the dimensions (height and width, respectively) of the board, not counting the
borders (i.e. the asterisks). The second line contains the five keys that the user will use to move left, move right, move
upwards, move downwards, and quit (respectively). It is possible that this line of the file is empty, in which case a set of
default keys (left: ‘a’, right: ‘d’, up: ‘w’, down: ‘s’, quit: ‘q’) should be used. Either all five keys will be provided, or none
will be provided.
Player line: The third line starts with the default icon used to represent the player. In the above file, this is ‘A’, which
is why A was the player’s icon in the above map. The ‘B’ is the powered icon, which I talk more about below. Then, there
are the starting coordinates (y-coordinate and x-coordinate, each zero-based) of the player. Note that a y-coordinate of 0
corresponds to the top row of the board, not the bottom row. Also note that the player’s icon could be the same as the
item’s icon.
Bulding, enemy, item, and power orb lines: The game file will always have at least one item (you may assume this),
but it may have zero buildings, zero enemies, and/or zero power orbs. At this point in the file, you will have the lines for
the buildings (if any, and each starting with a ‘B’), followed by the lines for the enemies (if any, and each starting with an
‘E’), followed by the lines for the items (each starting with an ‘I’), followed by the lines for the power orbs (if any, and each
starting with a ‘P’). For each of these kinds of lines, the special character is followed by the coordinates. Like the player,
each of an enemy, an item, and a power orb take up one spot. A building always looks the same as you see it in the example
above. That is, a building is always a 4-by-6 block of dashes, except for a “door” built with ampersands in the middle of
it. In the case of a building, the provided coordinates locate its top-left. You may assume that there are no overlapping
elements, e.g. there won’t be an item inside of a building. You may assume that everything is in bounds, e.g. there won’t be
a building that is halfway outside the boundaries of the board.
End conditions: The game ends when any of the below conditions occur. Depending on which end condition is
achieved, your program should print a specific message; see the examples below. The player is always shown their ending
score. Moreover, if the player loses by dying, then the board is shown one extra time; one of the examples emphasizes this.
• The player quits using the quit key.
• The player wins by collecting all of the items.
• The player dies.
Input and collision detection: When prompting the user for input, if they do not enter one of the four movement keys
or the quit key, then they should be prompted again (see the examples below). You may assume that the user only enters
one character at a time. Each movement key attempts to move the player one unit in the indicated direction. Certain events
occur based on what the player interacts/collides with:
• Borders: The player is prevented from going through the board’s borders.
• Building: The player is prevented from going through the building.
• Item: The player collects the item, removing it from the game.
• Power orb1
: When the player touches a power orb, they enter “power mode”. While they are in power mode, their
icon is the powered icon that was mentioned above, instead of the default icon. They remain in power mode during
their next 7 inputs. This duration is reset/replenished (back to 7) if they touch another power orb during this time.
Note that during the last input in which the player is in power mode, their power mode should run out immediately
after they enter their input / before collision detection is done; see one of the examples below, where I specifically
comment about this. Also note that the duration goes down even if the player’s input is wasted, e.g. if they spent the
next 7 inputs trying to move into a wall (and thus move nowhere), then the power mode will expire.
• Enemy:
– If NOT in power mode (default): The player dies, and the game ends. As stated in the end conditions above, the
board should be printed one more time in this case, and the player’s icon will be a @ (that’s the character that I
felt most looked like an explosion).
– If in power mode: The player removes the enemy from the game.
1Power orbs mimic the behavior of “power pellets” in the game Pac-Man.
3
Indicators: As you can see in the examples, I’m always shown the current score and the number of items remaining.
The score is incremented whenever an item is collected or (while in power mode) an enemy is destroyed/eaten2/collected.
Here are some suggestions that you may or may not find helpful:
• After performing some setup, your game could go to what we will call its “main loop”, which is the loop that keeps the
game going until an end condition is satisfied. In each iteration of this loop, the game should be drawn, and then user
input should be obtained, and then updates (movement, collision detection, etc., where applicable) should be performed.
• I would start small and make sure things still work as you make gradual, carefully thought out changes. An example of
this would be to start with a file that only contains the bare minimum requirements, i.e. the first three lines and then
a single item, all on a small board. Don’t try to type a lot of code at once without pausing to check if any of it works.
• I used a lot of helper functions to organize my code when I thought it would help me think about the different steps.
Here are examples of helper functions that I had: setupBoard(), loadKeys(), drawBuilding(), getInput(). Each helper
function identifies a clear step, and this helped me to write my solution in a methodical manner.
• I lost a bit of time dealing with that the second line could be blank because I was using a mix of fgets() and fscanf()
to read the file. If you put a newline character at the end of the format string of fscanf() and there are two newline
characters in a row (which occurs when the second line is blank), fscanf() will read both (not just one) of those newline
characters (after reading whatever else it was supposed to read according to the format string).
Memory leaks: Your program should have none, and you should close any files that are opened.
Below is a list of headers that you are allowed to include in game.c. You may not need all of these.
• game.h
•
•
•
•
•
•
•
Below are examples of how your code should behave. You can find all of the demo files (e.g. main.c, game2.txt) on Canvas.
1 $ cat main .c
2 # include " game . h"