代写ECS 36A程序、Programming编程设计代写、C/C++代写程序代做

日期：2020-12-16 11:30

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

• <stdio.h>

• <stdlib.h>

• <stdbool.h>

• <ctype.h>

• <string.h>

• <limits.h>

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