代写 TeensyPewPew race car game C

日期：2018-05-12 09:24

CAB202 Assignment 2 Return to Exercise Lis , Exercise 1:

Assignment 2

Results so far:

No submission has been made so far. (0%).

Assessed weight: 1E-08%. This item is assessed. You may continue to attempt this item until

you reach 50 submissions, or until submissions close for this item. So far, you have made 0

submissions. Submissions will close for this item at 3/06/2018 11:59:59 PM.

Requirements:

Use this form to submit the source code of your solution for Assignment 2.

Date due: 03 June 2018, 11:59:59 PM.

Introduction:

In this assignment you will implement a TeensyPewPew port of the race car game you

implemented in Assignment 1.

The assignment consists of three parts.

Part A: Port Basic Game (10%): Implement, test, and document a TeensyPewPew program

which is a modified version of the basic Race to Zombie Mountain game from Assignment 1.

Part B: Extend Game (10%): Implement, test, and document specific extensions to the

basic game as defined below.

Part C: Demonstrate Mastery (20%): Demonstrate the use of micro-controller programming

techniques in your implementation.

Your task is to implement Race To Zombie Mountain (Parts A, B, and C), using the CAB202

libraries to target the TeensyPewPew hardware platform. Detailed specifications of the

required items of functionality appear in the following sections.

Listen Up!

1. The assignment will be graded by strict reference to the criteria listed below.

2. Assessment is evidence-based. You must submit a written report via TurnItIn which

provides evidence of completion, supported by working source code submitted via AMS.

Both items must be submitted by the due date. Absence of either or both will result in a

score of 0.

3. This is not a group assignment. While we encourage you to discuss the assignment and

brain-storm with your associates, you must ensure that your submission is your own

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

individual work.

Share ideas, not code!

4. A high standard of academic integrity is required. Breaches of academic integrity,

including plagiarism or any other action taken to subvert, circumvent, or distort the

assessment process, will not be tolerated. QUT policy regarding academic conduct is

available in the QUT MOPP Section C/5.3 Academic IntegrityIn particular, under the provisions of MOPP

statement C/5.3.7, Part (e),

we reserve the right to require you to authenticate your learning. You may be required

to show evidence of materials used in the production of the assignment such as notes,

drafts, sketches or historical backups. You may also be required to undertake a viva or

complete a supervised practical exercise.

5. Use of any third-party code library (other than those provided by the CAB202 teaching

team or supplied with a standard distribution of gcc/avr-gcc) is strictly prohibited.

Use of code downloaded from the internet without correct attribution to the original

author(s) is strictly prohibited. Subcontracting, outsourcing, off-shoring, purchasing,

borrowing, stealing, copying, or obtaining source code or report content by any means

other than through an act of original creation by yourself, is strictly prohibited.

6. Abundant code samples, demonstrations, and exercises have been made available to support

your effort toward this programming task. Written permission must be obtained from the

Unit Coordinator if you want to use technology other than the CAB202 libraries to

implement your game. Permission will only be granted if there are compelling special

circumstances that make it impossible for you to use the CAB202 libraries. Without this

permission, a game implemented with some other graphical framework will receive a score

of 0.

Deliverables

1. Report, submitted via TurnItIn.

Submit a succinct and well-presented written report which accurately describes your

program and how you have tested it. You may refer to QUT Cite Writefor information on the general

structure of a report. Adapt the outline as necessary to suit this task.

The report is your primary assessable item.

The report is the medium through with you will convince your tutor that the program you

have written is in fact a solution to the task that has been set. It is not a copy of

the source code of your program. It needs to contain enough information to convince an

intelligent reader (who may not necessarily have a background in software engineering)

that you have done what you claim to have done, and indicate where they can look in the

source code to learn how you did what you claim to have done. The reader should be able

to see easily in the report how you have tested the respective features, and whether

they work as claimed.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

The report should contain one section for each feature or subsystem that you implement.

Each section should be given a clear title which identifies the subsystem in question,

and include the following subsections:

a. High-level description of the feature.

b. List of global variables and functions used to implement the functionality.

For each global variable, briefly say what its name is and what it is used

for.

For each function, briefly state its name (or line number range) and what it

does.

Do not include a copy of the source code in your report.

Explicitly mention details of any aspect of the implementation for which you

wish to get credit but which is not obviously demonstrated via the outcomes of

a test.

c. Test plan and results.

Provide written evidence that you have comprehensively tested your program,

and what the results were.

Do not attempt to capture screen shots or photographic evidence.

Use written descriptions augmented with diagrams to indicate expected and

actual visual phenomena.

Most subsystems will require several tests.

A test case contains three components:

Test description and setup. Describe the exact steps that must be taken

to set up and execute the test.

Expected outcome. State what should happen if the program is written

correctly.

Actual outcome. Record what actually happens when you carry out the test.

Each test case should be well narrated. Provide sufficient detail to allow an

independent tester to recreate the exact conditions required for the test, and

to execute the test. After following the instructions, the tester should be

able to easily and without ambiguity observe the actual outcomes you record.

The most appropriate format for the test plan is a table.

Your mark for each feature will be awarded for what you document that you have tested.

Make sure you cover all relevant points in your implementation, and supply evidence of

comprehensive testing to back up all assertions.

2. Source Code, submitted via AMS.

Submit full source code for your implementation into AMS using this form.

A working implementation of your program which can be executed by your tutor running the

CAB202 Teensy software is required. Therefore, your program must compile in AMS and the

resulting executable program must work as stated in your report.

3. TL;DR

NO REPORT: NO MARKS.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

GAME DOES NOT COMPILE IN AMS: NO MARKS.

GAME DOES NOT RUN: NO MARKS.

SUBMITTED GAME DOES NOT MATCH REPORT: NO MARKS.

FRAUDULENT OR FABRICATED TEST PLAN: NO MARKS.

Part A – Port Basic Game (10%)

Overview of Part A

The game consists of a top-down scrolling view depicting a roadway in the middle, with

scenery filling the remainder of the window to the left and right.

The player controls a race-car which is positioned near the bottom of the display, and

which can move horizontally across the display.

A dashboard will show some information about the state of the car at all times.

Additional information about the state of the car can be obtained by pressing the Pause

control (see below).

The illusion of forward motion is achieved by scenery and other objects which scroll

smoothly into view at the top of the display, then travel downwards until they scroll

smoothly off the bottom of the display.

The downward speed of scenery and other objects is determined by the speed of the car,

which may take values between 0 (stationary) to 10 (very fast).

The player nominally controls the speed of the car, but it is limited to a maximum of 3

if any part of the car is not on the road.

The race-car must steer around scenery (which appears beside the road) and obstacles

(which appear on the road); if it crashes into any scenery or obstacle it will sustain

damage, then restart as described in the detailed instructions below.

As the car drives forward, it consumes fuel at a rate proportional to the speed of the

car. If the fuel runs out it must stop, and the game is over.

To avoid running out of fuel, the player must pull over next to a fuel depot and wait

for three seconds while the fuel supply replenishes.

Assuming that the player does not run out of fuel, the game ends when the race-car

reaches Zombie Mountain.

1. Splash Screen (0.5%)

Before the game starts, a welcome screen should be displayed.

Include the name of your program, your name, and your student number.

In your report: include instructions which tell the user how to play the game.

The screen should display until (at the user’s discretion) either the left or

right button is clicked to start playing.

Include in test plan:

Include at one test case for each button.

2. Dashboard (0.5%)

A graphical or textual display must be used to show the following information.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

Condition of the race car.

Current speed of the race car.

Amount of fuel remaining.

You are free to render this as you wish. A clear boundary (like the border) should

separate the dashboard from the rest of the playing area.

Include in test plan:

Sufficient test cases to support your assertion that the dashboard has been

implemented, and that it is consistent with the state of the game.

3. Paused View (0.5%)

When the user activates the Pause control the game is suspended, and the Paused View is

displayed.

In Paused View the user can inspect the total distance travelled by the car, and

the elapsed time since start of game, accurate to the nearest 1/100 of a second.

While the game is suspended, elapsed time must pause. When the game resumes,

elapsed time must once again continue to accumulate.

When the user activates the Resume control, the game resumes.

Include in test plan:

Test cases to cover passage of game time, movement at various speeds (including 0),

plus controlled pause-resume-pause patterns with particular intervals.

4. Race car, horizontal movement (non-collision) (1.5%)

The race car is permanently visible in the lower 25% of the playing area.

A distinctive sprite at least 3 units wide and 4 units high should be used. It

should look as much like a race-car as possible.

If the current speed of the race car is zero, then no lateral motion is permitted

at any time.

If the current speed of the race car is non-zero, then the left and right keys move

the car one unit left or right respectively per key-press.

You may choose any pair of keys to function as left and right. Document this choice

in your report, and describe on the Splash Screen.

The car must be constrained so that it never overlaps the border, any scenery

object (such as trees, hills), obstacles on the race track, or fuel depots.

Include in test plan:

Test cases for meaningful combinations of (Car in middle of road; Car next to left

border; Car next to right boarder) vs. (Speed zero; Speed non-zero).

Make sure you precisely document the source code locations where these conditions

are enforced.

5. Acceleration and speed (1%)

Subject to constraints elsewhere in this document, pressing the accelerate and

decelerate controls should increase and decrease (respectively) the speed of the car.

th

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

https://sefams01.qut.edu.au/CAB202_2018_01/Exercise?TopicNumber=11&ProblemNumber=1 6/15

You can choose any pair of switches for this purpose. Document the decision in the

report and include them on the Splash Screen.

Initially, the speed of the car is 0.

In the basic game, the car moves forward, i.e. the speed is always greater than or

equal to 0.

When travelling on the road, the speed may never exceed 10 (very fast).

If the car is travelling off-road, the speed may never exceed 3.

The speed must be accurately reflected by the dashboard at all times.

Include in test plan:

Test cases for meaningful combinations of (Car stationary; Car moving intermediate

speed; Car going very fast) vs. (Accelerate; Decelerate).

6. Scenery and obstacles (2%)

Background objects and obstacles provide the illusion of movement by smoothly scrolling

into view at the top of the window, sliding down the window, and smoothly scrolling out

of view at the bottom of the window.

These objects never obscure the border or the dashboard and are never visible

through the dashboard.

The rate at which scenery and obstacles move down the screen is proportional to the

speed. Thus, when the car is stationary, scenery and obstacles do not move.

Scenery may be trees, bushes, houses, hills, (stationary) zombies, lakes, or other

such things. Scenery is not on the road.

Obstacles are similar to scenery, but they are on the road, and they should be

consistent with that role. Thus, a zombie or road-block might appear on the road,

but a house or tree never would.

There should be at least 5 items of scenery or obstacles (altogether) in view at

all times.

The horizontal (and initial vertical) position of scenery and obstacles must be

randomised.

Include in test plan:

Test cases for meaningful combinations of (Car stationary; Car moving intermediate

speed; Car going very fast) vs. (Scenery/obstacle scrolling in at top of window;

Scenery/obstacle in middle of window; Scenery/obstacle scrolling out at bottom of

window).

7. Fuel depot (1%)

Occasionally a fuel depot should appear next to the road.

A fuel depot is indicated by a distinctive icon which should be at least as large

as the race-car.

Fuel depots appear at unpredictable intervals, but with sufficient frequency that

the player always has a chance to refuel.

Fuel depots appear, move and disappear in the same way as scenery and apart from a

stronger constraint on their horizontal location they obey the same constraints as

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

scenery.

Fuel depots always appear just next to the road, with equal probability of

appearing on the left or the right.

Include in test plan:

Test cases for meaningful combinations of (Car stationary; Car moving intermediate

speed; Car going very fast) vs. (Depot at top of window; Depot in middle of window;

Depot at bottom of window).

8. Fuel (0.5%)

The car requires fuel to move.

Initially, the car has a full tank.

Fuel is consumed at a rate proportional to the speed of the car.

If the car parks next to a fuel depot for 3 seconds, its fuel level is restored to

maximum.

The current fuel level is always faithfully reflected in the dashboard / status

display.

Include in test plan:

Test cases for (Car stationary; Car moving at constant speed).

Test case for refill at fuel depot.

9. Distance travelled (0.5%)

The total distance travelled appears in the paused view.

Initially, this value will be zero.

Distance accumulates at a rate proportional to the speed of the car.

The distance is never reset to zero during a game.

When the car has travelled a very long way, it reaches Zombie Mountain, and the

player wins.

Some kind of finishing line or other such indication that the player is

approaching the goal should scroll into view.

When the car crosses the line, a victorious form of the Game Over dialogue is

displayed.

Include in test plan:

Test cases for (Car stationary; Car moving at constant speed).

10. Collision (1.5%)

In the basic game, bounding box collision detection is used, as outlined in the Topic 3

lecture.

If the car hits a scenery object (such as trees, hills), roaming zombie, or

obstacle on the race track, then:

The condition is reduced to reflect the damage inflicted.

If the condition reaches zero, then the car is destroyed. Display game over

dialogue.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

https://sefams01.qut.edu.au/CAB202_2018_01/Exercise?TopicNumber=11&ProblemNumber=1 8/15

The car instantly moves to a safe position on the road, with speed equal to 0,

and a full fuel tank.

If the car collides with a fuel depot, the car is immediately destroyed. Display

Game Over dialogue.

Include in test plan:

Test cases for representative combinations of (Head-on collision; Left side

collision; Right side collision) vs. (Scenery; Obstacle; Fuel depot).

11. Game Over Dialogue (0.5%)

When the game ends, display a screen which:

Advises the player whether they won the race, along with their elapsed time, and

distance travelled.

Prompts to see if they want to play again, then waits for either affirmative or

negative response.

If affirmative, a new game should commence. All counters should be as the first

time the game starts.

If negative, the program should end.

Include in test plan:

Test cases for (Player wins; Player does not win).

Indicate in report clearly how you restart the game.

Part B – Extend Game (10%)

1. Curved road (3%)

Ensure that the race track follows some smoothly varying but non-linear path such that

the car is guaranteed to leave the road if no obstacles interfere and the player drives

straight.

Random jiggling of the edges of the road will not qualify for any marks under this

criterion.

A simple sinusoidal path will qualify for part marks under this criterion.

To attain full marks, use a method which produces a smooth path which is hard for

the driver to predict. You may be able to achieve the desired effect by combining

multiple sine curves having different amplitudes and frequencies.

Include in test plan:

Test cases which demonstrate that the functionality has been implemented.

2. Accelerator and brake (3%)

Correct implementation of this feature also attracts the marks assigned to the

Accelerator function in Part A.

This feature introduces more realistic acceleration, deceleration, and braking.

Use a data type which supports fractional values to implement speed.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

The decelerate control becomes a brake.

When the brake is pressed:

The accelerator has no effect on the state of the car.

If the speed is greater than zero, then speed decreases linearly such that it

would go from 10 to 0 in approximately 2 seconds.

When the brake is not pressed and the accelerator is pressed, then speed increases

linearly:

from 1 to 10 over a period of approximately 5 seconds when on the road.

from 1 to 3 over a period of approximately 5 seconds when off-road.

When the brake is not pressed and the accelerator is not pressed, and the speed of

the car is greater than 1, then the speed decreases linearly at a rate equivalent

to:

going from 10 to 1 over a period of approximately 3 seconds when on the road.

going from 3 to 1 over a period of approximately 3 seconds when off-road.

After decelerating in this manner, the car will continue to coast at a speed of 1.

When the brake is not pressed and the accelerator is not pressed, and the speed of

the car is less than 1, then the speed increases linearly at a rate equivalent to:

from 0 to 1 over a period of approximately 2 seconds when on the road.

from 0 to 1 over a period of approximately 3 seconds when off-road.

After decelerating in this manner, the car will continue to coast at a speed of 1.

Include in test plan:

Test cases which demonstrate that the functionality has been implemented.

3. More realistic steering (2%)

Horizontal movement of the car is restricted to a maximum speed which is proportional to

the speed of the car.

Thus, the faster the car is moving forward, the faster it can swerve left or right.

Include in test plan:

Test cases which demonstrate that the functionality has been implemented.

4. Fuel level increases gradually (2%)

When the car parks next to a fuel depot, the fuel will increase in a linear manner

equivalent to a full fuel tank in 3 seconds.

This will allow the car to do partial top-ups in less than 3 seconds, or a full

top-up in 3 seconds.

The fuel display should update in real time as the car refuels.

Include in test plan:

Test cases which demonstrate that the functionality has been implemented.

Part C – Demonstrate Mastery (20%)

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

https://sefams01.qut.edu.au/CAB202_2018_01/Exercise?TopicNumber=11&ProblemNumber=1 10/15

This is a chance to showcase your skills with TeensyPewPew hardware in an open-ended setting.

The choice of exactly how you do this is left up to you.

Each of the following items should be addressed in a separate section of your report. Include

specific details about how your program addresses each criterion, backed if appropriate by an

extended test plan to document any functionality which has not already been covered

elsewhere.

1. Use ADC (1%)

Your program uses ADC (one or both potentiometers) in an appropriate manner to implement

significant functionality in the game.

If a potentiometer is used for steering, then (in addition to other rules for

horizontal motion) the rate of horizontal motion of the vehicle when turning should

be proportional to the distance of the potentiometer from its central position.

2. De-bounce all switches (2%)

Your program implements de-bouncing for all switches in a maximally efficient manner

using the algorithm developed in Portfolio Topic 9.

3. Direct screen update (3%)

Your program uses direct control of the LCD display in an appropriate manner to:

Bypass the cab202_teensy screen buffer entirely for implementation of some visual

feature; OR

Selectively update a small region of the display using lcd_write (ie: without using

show_screen or any equivalent function); OR

Some other operation which is logically and technically equivalent to the above.

4. Timers and volatile data (3%)

Your program uses multiple timers and interrupts in an appropriate manner to implement

elapsed time and other time-dependent control tasks.

5. Program memory OR PWM (2%)

Your program uses Program (flash) memory in an appropriate manner (other than the ASCII

font already supplied in library code) to store large data objects which would normally

occupy static memory.

OR

Your program uses PWM in an appropriate manner to implement a special effect of some

kind.

6. Pixel-level collision detection (3%)

Your program includes sprites which have significant empty space on at least three

edges, so that it is possible for their bounding boxes to overlap without the objects

colliding. You use pixel level operations to detect collision when (and only when) nonbackground

pixels occupy the same screen location.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

https://sefams01.qut.edu.au/CAB202_2018_01/Exercise?TopicNumber=11&ProblemNumber=1 11/15

Solutions which use the screen buffer to detect collisions will not qualify for any

marks under this criterion.

A solution which uses nested loops to iterate over all pairs of pixels in two

sprites will qualify for part marks under this criterion.

To attain maximum marks, use bit-shifting and bitwise operators to process pixels

in large groups (8 or 16 at a time), and use at most one loop.

7. Bidirectional serial communication and access to file system (6%)

Your program uses USB serial communication to communicate with a program running on your

desktop computer (the server).

While the game is paused, the user may activate the Save control on the Teensy to

send a snapshot of the game state to the server.

The server will examine the incoming request, determine that it contains game

state, and save the state to a file.

While the game is paused (or on the Game Over dialogue), the user may activate the

Load control on the Teensy to download the most recent saved state of the game from

the server.

The server will examine the incoming request, determine that it is a request for

the saved game state, read the state from the file, and send it to the Teensy.

After loading the state, the game should resume exactly as it was when it was

saved.

A separate submission form is provided for you to submit the source code of your server

program.

Marking

The assignment is worth 40% of your total grade in this subject, and it is marked out of 40.

The breakdown of marks is outlined in the previous section. The following points should be

noted about marking:

1. If your code does not compile when submitted to AMS, the mark awarded will be 0.

Give yourself plenty of time to get the basics right.

Submit Early. Submit Often.

2. If the program has been implemented via a framework other than the ZDK without prior

written permission from the Unit Coordinator, the mark awarded will be 0.

3. If the program fails with segmentation faults or other fatal errors, marks will be

awarded for the features that were observed prior to the crash.

No effort will be made to work around the crash, nor will we debug your code to

make it compile or run.

Your program must compile and run well on any modern desktop machine equipped with

a Unix-like environment.

To this end, part of your job is to test the program in a variety of environments,

including (as a minimum) QUT lab machines using the CAB202 portable Cygwin

environment.

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

“It runs fine on my computer!” may be true, but it is largely irrelevant if the

program crashes when executed on another machine. Such an excuse will not be

accepted.

4. Penalties will be applied if the code exhibits general defects or undesirable behaviour

not otherwise covered in this document. This includes but is not limited to such things

as:

Objects moving outside their permitted area;

Collisions involving invisible or non-existent objects;

Disturbing or flashing display;

Gratuitous errors in program structure, including but not limited to: inappropriate

use of recursion; use of inappropriate data structures such as linked lists or

binary search trees.

Notes:

For purposes of AMS assessment, this activity has been classified as non-assessed. This

does not mean the assignment is non-assessable – it means that the system is not able

to assess the assignment automatically. AMS will not enforce a hard close-down for

submissions, however in line with QUT policy, late submissions without an approved

extension will not be marked. If special circumstances prevent you from meeting the

assessment due date, you can apply for an extension

(https://www.student.qut.edu.au/studying/assessment/late-assignments-and-extensions)

before the due date. If you don’t have an approved extension you should submit the work

you have completed by the due date and it will be marked against the assessment

criteria.

If your solution consists of a single C source file, you may either paste the contents

into the text area provided below, or use the “Attach file” button to load your file

into a new text area.

If your solution consists of multiple C source files and header files, as indicated by a

suffix of *.c or *.h, use “Attach file” once for each file.

A maximum of 30 files may be included in each submission. This consists of the built-in

"submission.c" document, plus 29 attachments.

Attach only one version of your program in any single submission.

When you have attached all required files, press the “Submit” button.

Source files for each submission will be placed in a single distinct folder on the

server, and compiled with the following command:

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2

Attach file:

*.c \

-mmcu=atmega32u4 \

-Os \

-DF_CPU=8000000UL \

-std=gnu99 \

-I../cab202_teensy \

-L../cab202_teensy \

-Wl,-u,vfprintf \

-lprintf_flt \

-lcab202_teensy \

-lm \

-o a2_n9999999.obj

C:/WinAVR-20100110/bin/avr-objcopy -O ihex a2_n9999999.obj a2_n9999999.hex

where n9999999 represents your student number.

Therefore, you should organise your files in a folder alongside the cab202_teensy

folder and use this command to build your solution. Make sure there are no additional

files (such as old versions of your program) in your work folder to prevent

unpredictable build errors due to inclusion of incorrect versions of files.

If compilation is successful, AMS will verify that your program has compiled

successfully and return. Your program will not be executed because there is no

meaningful test that can be performed automatically on a program such as this.

The transcript will contain a copy of the compiled .hex file. You can paste this into a

text document (using notepad++ or a Linux-compatible text editor) and save it as a

*.hex file for local testing.

Attach usb_serial.cand usb_serial.hif you use

USB serial in your assignment.

Submitted files:

submission.c

Declaration and submission

By submitting this form, I certify that:

I have read, and understand, QUT Manual Of Policy and Procedures, Section C/5.3,

Academic Integrity; and

This submission is in full compliance with all provisions of QUT Manual of Policy and

Procedures, Section C/5.3, Academic Integrity; and

With the exception of support libraries provided to the class by the CAB202 teaching

team, I am the sole author of all source code and attachments included in this

submission.

Agree to these conditions:

Submit

Transcript:

2018/5/11 CAB202 - CAB202 Assignment 2, Exercise 1: Assignment 2