代做CAB202、代做C/C++语言、TeensyPewPew程序代写代做、代做C/C++程序设计

日期：2018-10-20 10:50

CAB202 AMS

Home

Hello,QUTAD\n9592547!

CAB202 Assignment 2, Exercise 1:Assignment 2

Return to Exercise List ?

Results so far:

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

Assessed weight:0%.This item is not assessed. You may continue to attempt this item until you reach 100 submissions. So far, you have made 0 submissions.

Requirements:

CAB202 Assignment 2

Due Date: 23:59:59 (AEST) Friday 26th October 2018

Marks: 40 (40% of your final mark)

For this assignment, you will be writing a TeensyPewPew program that emulates a player moving through a series of static and moving blocks. The aim of the player is to move/jump between blocks while gaining points and lives. This assignment builds on Assignment 1 and requires that you demonstrate knowledge of the Teensy microcontroller.

Please join the Assignment 2 Slack channel to ask your questions.

FAQ

Assignment Specifications

This assignment is divided into different sections, however you may attempt the sections in any order you see fit. You may attempt other sections even if you have not fully completed the Basic Functionality.

You will submit documentation as per the instructions given below and you will be marked on a combination of your documentation and your program. You will need to do both well to get the full marks. If you submit code without the specified documentation you will be marked down, conversely, if you submit documentation for aspects you have not implemented or documentation that does not accurately reflect your program, you will be marked down.

If your program crashes, you will be marked for the sections your marker was able to test before the program crashed. Please test your code regularly to minimise your chance of this happening. You can make multiple submissions to AMS and you are encouraged to do so.

Basic Functionality(12 Marks)

1.Your program begins with an intro screen showing your name and student number. When SW2 is pressed, the game begins.

2.When joystick centre is pressed once, the game pauses (all sprites stop moving and are unable to move by using the normal controls), the game screen is cleared, and game information is displayed. The game is resumed when joystick centre is pressed again. The game information displayed is:

a.Lives remaining

b.Current score

c.Game time in mm:ss format

3.The player initially appears on a 'starting block' in the top row. The player’s sprite is at least 3 pixels high and 3 pixels wide.

4.All blocks are:

a.At least 2 pixels high,

b.At least 10 pixels wide and are clearly distinguished from each other (through spacing between sprites or other visual design),

c.Always at least player sprite height + 2 pixels vertically separated from other blocks.

d.There are at least 7 safe blocks on the screen at one time.

e.There are at least 2 forbidden blocks on the screen at one time.

f.Safe and forbidden blocks are easily distinguished from each other.

5.Blocks have no consistent observable pattern and each block:

a.Appears in a randomly selected row,

b.Appears in a randomly selected column,

c.Does not overlap other blocks.

6.Pressing the joystick LEFT or RIGHT has the following effect:

a.Pressing the joystick left or joystick right moves the character one step left or right, respectively,

b.If the player is not supported by a block, it will move vertically toward the bottom of the screen.For Basic Functionality, realistic physics such as acceleration and horizontal momentum, are not required.

c.The joystick has no effect on the player's motion when the player is not supported by a block.

d.If the falling player collides with a safe block from above, then the player lands on the block. The player will then immediately stop moving.

e.Under no circumstances may the visible pixels of the player sprite overlap with the visible pixels of a block.

7.There is a treasure sprite that:

a.Is no larger than the player's sprite and has a clearly distinct image.

b.Does not overlap any of the blocks.

c.Spawns in the bottom half of the screen and moves back and forward, changing horizontal direction when it reaches the edges of the screen.

d.Stops moving when SW3 (right button) is pressed and starts moving again if SW3 (right button) is pressed again.

e.Disappears when the player collides with it and gives the player?2?more lives and returns the player to the 'starting block'.

f.Does not reappear again unless the game is restarted.

8.The following game mechanics are present:

a.The player starts with 10 lives.

b.A point is scored every time the player lands on a safe block.

c.The player dies if any part of the player sprite moves off the screen in any direction or manner, or if it collides with a forbidden block.

d.On death, the player respawns on the 'starting block'.

e.When the player loses all their lives, the game over screen is displayed which displays a game over message, total score, and game play time.

f.The game over screen allows the player to restart by pressing SW3 (right button) and score, lives, time, and player position all reset or end the game by pressing SW2 (left button) which clears everything and just displays student number on the screen.

Advanced Functionality?(10 Marks)

9.In addition to the functionality of points 4 and 5 above, the blocks move.

a.All blocks move at a constant horizontal speed.

b.Each row of blocks must move in the opposite direction to the row above it.

10.The functionality defined in point 6 above is?redefined?as follows:

a.Pressing the joystick either LEFT or RIGHT while the player is supported by a block sets the player in continuous horizontal motion at a constant speed (relative to the block) in the appropriate direction. When in horizontal motion, the players horizontal velocity must be greater than that of the block, so that it is possible for the player to make progress against the direction of the block.

b.If the player is moving horizontally on a supporting block, and the joystick is pressed in the opposite direction, then the player stops moving relative to the supporting block, and is carried by the block.

c.If the player is moving horizontally on a supporting block, and the joystick is pressed in the same direction as current movement, then the player continues to move at the same speed in the current direction.

d.If the player is moving horizontally on a supporting block, and the joystick is not pressed, then the player continues to move at the same speed in the current direction.

e.If the player is not supported by a block, then it will commence to accelerate downwards. If the player is moving horizontally before leaving the support of a block, then the player must continue to move horizontally at the same speed while accelerating downwards, so that a parabolic flight path will be observed.

f.If the player is moving without support of a block (ie, flying, jumping, or falling) and the player lands on a safe block, it will then immediately begin to move horizontally in the same speed and direction as the block, and all vertical motion will cease. That is, the player will ride along the block, and player movement block.

g.If the player is moving without support of a block, and its Sprite collides with the end of a safe block (from the side), then its horizontal motion becomes zero, and it continues to accelerate downward.

h.All other collisions between the player and safe blocks are treated in a manner consistent with the combined motion.

i.Any collison with an unsafe block results in death.?

11.Pressing the joystick UP while the player is supported by a block causes the player to jump.

a.After UP is pressed, the player should commence to move upwards. Any horizontal motion should continue, and the acceleration provision of 10(e) will take effect.

b.Once UP is pressed, the joystick has no effect until the player lands on a block or dies.

c.Immediately upon landing on a block, the player's velocity changes to match that of the block so it is carried along.

d.If the player jumps off screen, the player dies.

e.The initial vertical velocity should be sufficient to allow the player to jump through gaps between blocks and land on blocks on the row above.

12.Player has an inventory which stores Food. Food occurs such that:

a.At the start of the game, the player has five (5) Food in their inventory.

b.The Food sprite's area (i.e. sprite width * height) is no larger than the player sprites's area.

c.When the player is supported by a block and joystick DOWN is pressed, Food appears. The Food must be supported by the block, and overlap the player sprite. The number of Food in the inventory decreases by one.

d.The total Food count (inventory + screen) must always equal 5.

e.Food dropped on a block is carried by the block.

f.Food may overlap.

13.Five (5) Zombies appear from the top of the screen, and fall straight down without overlapping each other, after the program has been running for approximately 3 seconds. The Zombies behave as follows:

a.Zombies stop falling when they land on any block.

b.If a Zombie falls all the way to the bottom of the screen, it passes from view and does not reappear immediately. The player doesn't get any points for this.

c.After landing on a block, Zombies prowl left and right along the blocks at fixed constant speed?relative to the blocks. Zombies can cross over narrow gaps (just how narrow depends on the span of the Zombies' "feet"). Whenever a Zombie reaches a gap that it cannot cross, it reverses and moves in the opposite direction.

d.Zombies may overlap each other if they are moving in opposite directions on the same span of blocks.

e.If a Zombie is on a block that leaves the screen, the Zombie is carried off the screen; it continues to move along the blocks as if nothing untoward had occurred.

f.When a Zombie collides with Food:

i.the Zombie disappears,

ii.the player gains 10 points,

iii.the Food disappears, and

iv.the Food inventory increases by 1.

g.If a Zombie collides simultaneously with multiple Food, then the Zombie consumes one Food, leaving the others unaffected.

h.Zombies do not disappear when the player collides with them, but instead the player loses a life and respawns.

i.Three seconds after the last of the five Zombies disappears, either by feeding or falling out of view, the full complement of five Zombies respawn in the manner noted above.

14.In addition to the items listed under point 2, the pause screen shows:

a.Number of Zombies on screen.

b.Number of Food in inventory.

Specialised Teensy Functionality?(18 Marks)

15.ADC (your program uses one potentiometer) to control the movement of blocks, such at:

a.All rows of blocks move at the same speed which is proportional to the potentiometer value.

b.Block movement speed should range from 0 to a speed where the blocks are still clearly visible.

16.All switches that are used in the program are debounced efficiently, using the algorithm developed in AMS Topic 9, Question 3.

17.Both LED0 and LED1 flash at approximately 4Hz (synchronously or asynchronously) before the zombies spawn and continue to flash until all the zombies have landed or fallen off screen.

18.Direct control of the LCD using lcd_write (without using show screen or any equivalent function) is used to animate a death animation when the player dies the final time (i.e. when lives reach 0).

19.Multiple timers and interrupts are used to implement elapsed game time and zombie spawning and animation.

20.Program (flash) memory is used in an appropriate manner (other than the ASCII font already supplied in the library code) to store large data objects which would normally occupy static memory.

21.PWM is used to control the backlight when the player loses a life (but not the last time, when lives reach 0) and respawns and contrast changes as well so that the following effects are observable:

a.When the player dies, the backlight fades off and the screen fades out so nothing is visible,

b.Then the screen gradually goes back to normal contrast, the backlight fades on and the player respawns at the top row of blocks.

22.Pixel-level collision is testable and sprite images are chosen for their ability to clearly demonstrate this.

a.The method of testing pixel level collision versus what would occur if box collision was implemented is clearly documented.

b.If the player's sprite is humanoid, the player could collide with the block so that its hand lands on top of the platform and it gets pulled along hanging by its hand.

23.Serial communication is used to send information to a computer. The events and information are:

a.Game starts - name of event, player x position, player y position.

b.Player dies - name of event, reason for death, lives after death, score, game time.

c.Player respawns - name of event, player x, player y.

d.Zombies appear - name of event, number of zombies, game time, player lives, player score.

e.Zombies collide with Food - name of event, number of zombies on screen after collision, number of Food in inventory after collision, game time.

f.Player collides with treasure - name of event, score, lives, game time, position of player after returning to the top row,

g.Pause button pressed - name of event, player lives, player score, game time, number of zombies on screen, number of Food in inventory.

h.Game over - name of event, player lives, player score, game time, total number of zombies fed.

24.Your program uses USB serial communication to control the Teensy Game. All requirements specifying joystick and buttons now also apply to the corresponding keyboard keys specified below:

a.'s' starts the game from the intro screen,

b.'a' moves the character left,

c.'d' moves the character right,

d.'w' lets the character jump,

e.'t' stops and starts the treasure movement,

f.'s' drops the Food where the player stands,

g.'p' pauses the game and shows the game information,

h.'r' restarts the game after game over,

i.'q' takes the game to the student number screen after game over.

Documentation

You must document all the functionality you have implemented for full marks in each criteria.?Your documentation must be clearly written, formatted appropriately, follow the structure in the template, and include:

A cover page with your full name, student number and assignment date,

A contents page,

A list of all the features outlined above and which ones you have attempted as per?Table 1,

A heading, linked to the contents page, for each section,

Test plans for all functionality implemented from the Basic Functionality and Advanced Functionality sections as per?Table 2. You do not need to write a test plan for items you have not implemented,

Test plans for all the functionality implemented from Specialised Teensy Functionality that are not specified below.

A written explanation of?how?and?why?you implemented the following from Specialised Teensy Functionality:

oSwitch debouncing

oDirect control of LCD write

oTimers

oProgram memory

Use the templates below, and/or the Word document provided on Blackboard, for your documentation.

Table 1

Assignment Implementation Summary

Item NumberItem DescriptionImplementation Level

1Intro

2Pause Game

3Player size

4Block size

5Random blocks

6Player movement

7Treasure

8Basic game mechanics

9Player velocity

10Player jumping

11Block movement

12Player inventory

13Zombies

14Pause screen advanced

15ADC for block speed

16Switch debouncing

17LED warning

18Direct control of LCD

19Multiple timers

20Program (flash) memory

21PWM controlled visual effects

22Pixel level collision

23Serial communication events

24Serial communication game control

Table 2: Test Plan Example

Intro screen

Test of Specific FunctionalityTest Setup and ActionsExpected ResultActual Result

Program displays student name and number initially. When SW2 is pressed the game starts.Load the program and check that name and student number are displaying as expected.Student name and student number are displayed.As expected.

Pressing SW2 starts the game.After loading game, press SW2.Intro screen clears and game screen is drawn.As expected.

Submission Information

Important!

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 Blackboard 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 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 Integrity. In 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 the ZDK, cab202_teensy and those supplied with a standard distribution of GCC and ncurses) 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_teensy library 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_teensy library. Without this permission, a game implemented with some other graphical framework will receive a score of 0.

Deliverables

1.Report, submitted via Blackboard

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 Write?for information on the general guidelines for writing a report. For convenience we provide a word template.

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. The reader should be able to see easily in the report how you have tested the respective features, and whether they work as claimed.

The report should contain one section with the summary of the features that you implement and one section with the test plan and results. Refer to the report structure template in the specification in AMS and the Word document on Blackboard.

Implementation Summary.

Provide indication whether the requested feature was fully, partially or not implemented.

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

Test plan and results.

The most appropriate format for this is the template provided. Do not submit screenshots of the program or code.

Some features may require several tests.

Your mark for each feature will be awarded based what you document that you have done. Make sure you cover all relevant features in your documentation and implementation, and supply evidence of comprehensive testing to back it up.

2.Source code submitted via AMS

3.Teensy Return

Please note that safe return of your Teensy to the Technical Services counter on Level 9 of S Block by 02 November 2018 is required as a precondition for your assignment to be marked. If you have an extension for Assignment 2, then the due date for return of the Teensy is also extended by an equal amount. If the device is not returned by the relevant date, a score of 0/40 will automatically be recorded for your Assignment.

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.

oGive yourself plenty of time to get the basics right.

oSubmit Early. Submit Often.

2.If the program has been implemented via a framework other than the cab202_teensy libraries 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.

oNo effort will be made to work around the crash, nor will we debug your code to make it compile or run.

oYour program must compile and run well on any modern desktop machine equipped with a Unix-like environment.

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

o“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:

oObjects moving outside their permitted area;

oCollisions involving invisible or non-existent objects;

oDisturbing or flashing display;

oGratuitous 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?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:

C:/WinAVR-20100110/bin/avr-gcc \

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

FAQ:

Respawning on moving blocks

You may create a static safe start block that is above the first row of moving blocks and is in the leftmost or rightmost column. It does not need to be player height + spacing above the first moving row. To ensure that the player does not move into the start block after it moves to the first moving row, the first moving row should move away from the start block.

Player spawning on forbidden block

This should not happen. You only need two forbidden blocks so you can confine them to other rows if you do not implement a start block.

Player spawning on block with zombie

You may always respawn on the start block. Zombies may fall through the start block as well to ensure the player does not collide with the zombies immediately on respawn. The start block should either be zombie height away so that the player on the start block will not die on respawn or the player should be immune to zombie collisions while on the start block if the zombie sprite overlaps the start block. Alternatively, you may choose a column to always respawn your character in and ensure that the zombies never land in that column.

Zombie movement along blocks

Zombies should move to the edge of the block and then change horizontal direction. If there are two blocks next to each other that are less than zombie width apart, the zombie should travel from the first block to block second and only change horizontal direction when it reaches the edge of second block. For example, if blocks are spaced 1 pixel away from each other, this spacing won’t cause zombies to change direction, however when there is no block in a column the zombie will change horizontal direction. Zombies should never fall off blocks.

Zombies sometimes land on forbidden blocks or fall off screen during spawn process

This is okay. It is bad luck, if your game is randomised this shouldn’t happen every time.

How to randomise blocks properly

You need to use?srand?with a seed that changes each time the game is run. The easiest option for this is to use a timer and read the value when the player first presses start. Alternatively, there are other pins on the Teensy that generate noise that you could read instead.

Block rows and spacing

You need at least two moving rows to demonstrate moving functionality. You also need gaps in all rows that the player can move from one row to another.

Copying code from lecture examples, ZDK, and your own AMS submissions

You may copy code from lecture examples and the ZDK but please add a comment in your code to say where that section of code comes from. You may also reuse code from your own AMS submissions. Again, please make a note of where it comes from if you have not changed it substantially.

You may not copy other students’ AMS submissions.

Player pixel collision and food

If player is hanging onto a moving block and you drop food, the food should fall directly downwards and land on the first block directly below the player.

USB serial in submission

You do not need to upload USB serial. The CAB202_teensy library behind AMS includes it. If you are testing your compilation on your own computer you will need to add it to the compile command outlined above.

Source control

Any cloud based mechanisms and source control that you use for CAB202 should not be available to the public.?GitHub repositories are public by default! You can get private repositories for free as a student.

Report expectations and clarification

The report must reflect your submitted program.?Do not say you have completed something you have not.?Marks will be deducted for reports that do not reflect the submitted game state.

The overview should be as per the table below and the levels of implementation should be “not implemented”, “partially implemented”, “fully implemented”.

The test instructions should be sufficiently detailed, clear, and concise so that your tutor can adequately assess the quality of your work in an appropriate time frame.

The setup for your tests should be specific. “Run game” is not acceptable. For testing that lives decrease when you land on a forbidden block, you might say something like “Start the game and check that the player has 10 lives by pressing pause. Move player right by pressing the joystick so that the player falls off the start block and keep moving until you collide with a forbidden block. Press pause to observe the lives after colliding with the forbidden block.”

The following Advanced Teensy Functionality: switch debouncing, direct control of LCD write, timers, and program memory should be explained in at least 1 paragraph each. The how part should be understandable to someone who does not know C (clearly written English, not code) and the why part should be clearly and concisely explained. If you wish to use supporting evidence you need to include references (any style outlined in QUT Cite/Write is acceptable).

Bugs, crashing, flickering, unspecified functionality

Your marker can deduct marks for elements not specified in the above criteria. These include, but are not limited to: bugs in your program, flickering, crashing, unspecified functionality.

Submitted files:Attach file:?

Use the file chooser to attach a source file.

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:?

Transcript:

2018 - Queensland University of Technology