c/c++代写 CAB202 Assignment 1, Exercise 1: Assignment 1

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

CAB202 Assignment 1, Exercise 1: Assignment 1

Results so far:

Requirements:

Return to Exercise List »

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 30 submissions. So far, you have made 0 submissions.

CAB202 Assignment 1

Due Date: 23:59:59 (AEST) Monday 10th of September 2018 Marks: 30 (30% of your final mark)

For this assignment, you will be writing a computer 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.

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 1/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

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 (15 Marks)

1. The display screen is 5 characters high, located at the top of the screen, is entirely visible at all times (i.e. never occluded in any way) and displays:

a. Student number, b. Lives remaining,

c. Playing time in minutes and seconds format as mm:ss, d. Score,

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 2/12

2018/8/30

CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

e. Border that separates the display screen from the game area.

The player initially appears on a ‘starting block’ in the top row. The player’s sprite is at least 3
characters high and 3 characters wide.
All blocks are:
a. 2 characters high,
b. At least 7 characters wide (unless Advanced Functionality is implemented) and are clearly

distinguished from each other (through characters in bitmap or spacing between sprites), c. Always at least sprite height + 2 characters vertically away from other blocks.
Columns are calculated as visible screen width / max block width + horizontal spacing (if used to distinguish between sprites) and there are:
a. The number of blocks on screen is proportional to the number of columns, to a maximum of 160 safe blocks and 40 forbidden blocks,

b. At least 1 safe block per column denoted by ‘=’ on the screen at all times,
c. At least 2 forbidden block on the screen denoted by ‘x’ on the screen at all times.
Blocks have no consistent observable pattern and each block:
a. Appears in a randomly selected row,
b. Appears in a randomly selected column (after there is 1 safe block per column),

c. Does not overlap other blocks or the display screen.
Player movement behaves such that:
a. Pressing the ‘a’ or ‘d’ key moves the character left and right respectively, b. The player can not overlap the display screen.

c. When off a block, the player free falls downwards at an appropriate speed,
d. No lateral motion occurs during downward motion (unless Advanced Functionality is

implemented).
There is a treasure sprite that:
a. Is no larger than the player’s sprite and has a clearly distinct image,
b. Spawns at the bottom of the screen and moves back and forward along the bottom,

changing horizontal direction when it reaches the edges of the screen,
c. Stops moving when ‘t’ is pressed and starts moving again if ‘t’ is pressed again (i.e. motion

toggles on and off when ‘t’ is pressed),
d. Disappears when the player collides with it and gives the player 2 more lives and returns

the player to the ‘starting block’.
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 when they fall off the bottom of the screen or hit a forbidden block. On death, the player starts from the ‘starting block’ (unless Advanced Functionality is implemented).

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

e. The game over screen allows the player to restart by pressing ‘r’ (score, lives, time, and screen all reset) or quit with the ‘q’ key which ends the game gracefully.

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 3/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

Advanced Functionality (7 Marks)

Each block has a random width between 5 and 10 and:
a. The top and bottom rows of blocks remain stationery, but the blocks in other rows move at

appropriate speeds (different rows may have different speeds),
1. Blocks in the same row move at the same speed and direction,
2. Blocks reappear on the other side of the screen as they go off the screen,
3. Each row of blocks moves in opposite directions or speeds to the row directly above (e.g. if
  row 2 moves left, row 3 could move right),
Player motion is controlled as follows:
a. An ‘a’ or ‘d’ key press gives the player a horizontal velocity so that if ‘a’ or ‘d’ is pressed on a moving block, the player moves along the block accordingly,
1. When on a block, a ‘w’ key press gives the player a vertical velocity upwards (pressing ‘w’ again does not do anything until player lands again),
2. When the player lands on a block their vertical velocity changes to zero and they adopt the same horizontal velocity as the block,
3. If the player is on a block and any part of the block goes off screen, the player loses a life and respawns.
A constant vertical acceleration (i.e. gravity) acts downwards at all times, generating a reasonably realistic ballistic motion effect when the player is in flight after stepping or jumping from a block. Gravity generates the following visually observable behaviour:
a. When on a block, the effects of gravity are eliminated – the player does not fall through the block,
1. When jumping, the player’s vertical velocity is slowest at the peak jump height,
2. When jumping with a horizontal velocity, the player traces a parabolic path. The horizontal
  velocity is constant, while the vertical velocity increases at a constant rate with passage of
  
  time,
3. When falling with a non-zero horizontal velocity, the player also traces a parabolic path
  but starts with zero vertical velocity,
e. When hitting the side of a block, the player’s horizontal velocity becomes zero.
Player randomly respawns on any of the top row safe blocks after dying (doesn’t just reappear on the ‘starting block’).

Advanced Graphics (4 Marks)

13. The treasure has some sort of animation. 14. The player’s image changes when:

a. The player falls or when they jump, b. The the player is moving left,

c. The the player is moving right,
d. The player is stationery or only moving with the blocks.

15. The player has some sort of animation every time the player respawns.

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 4/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

Advanced Coding Practices (4 marks)

Your program has minimal code duplication and is cleanly structured for a human reader.
You have used arrays or pointers where appropriate.
Your program is composed of functions. A function should only perform one task and not exceed
20 lines of code.
You have used parameters where appropriate and minimised the number of global variables.

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,
A brief description of what you have implemented from the Advanced Graphics section and how it can be observed,
A written explanation of why and how you implemented what you have from the Advanced Coding Practices.

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

Assignment Implementation Summary
Item Number	Item Description	Implementation Level
1	Display screen	Partially implemented
2	Player size and initial position	Fully implemented
3	Block size and spacing	Not implemented
4	Blocks are randomly positioned.
5	Columns and block types
6	Player movement
7	Treasure
8	Basic game mechanics

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 5/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

9	Block width and movement
10	Advanced player movement
11	Ballistic motion
12	Player random respawning
13	Treasure animation
14	Player movement animation
15	Player respawn animation
16	Minimal duplication
17	Arrays or pointers
18	Functions
19	Parameters

Table 2: Test Plan Example

Display Screen
Test of Specific Functionality	Test Setup and Actions	Expected Result	Actual Result
Display screen is 5 pixels high, at top of screen and is entirely visible at all times.	Run game and press ‘w’ for player to jump.	Player and blocks should never cross the display screen.	Player can jump into display screen.
Lives remaining are displayed in the status display area.	Run game and die.	Lives should be displayed towards the right of the display screen area and decrease on death.	As expected.
Student number is displayed in the status display area.	Run game	Student number should be displayed in the left of the display screen.	As expected.

Submission Information Important!

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

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 6/12

2018/8/30

CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

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.
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!
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 (http://www.mopp.qut.edu.au/C/C_05_03.jsp). In particular, under the provisions of MOPP statement C/5.3.7 (http://www.mopp.qut.edu.au/C/C_05_03.jsp#C_05_03.07.mdoc), 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.
Use of any third-party code library (other than the ZDK 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.
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 ZDK to implement your game. Permission will only be granted if there are compelling special circumstances that make it impossible for you to use the ZDK. Without this permission, a game implemented with some other graphical framework will receive a score of 0. Direct use of the ncurses library to render graphics or text is expressly prohibited.

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 (https://www.citewrite.qut.edu.au/write/report.jsp) 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

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 7/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

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

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 Portable Cygwin software is required. Therefore, your program must compile in AMS and the resulting executable program must work as stated in your report.

Please Read

NO REPORT: NO MARKS.
NO COMPILE IN AMS: NO MARKS.
NO RUN ON STANDARD MACHINE WITH PORTABLE CYGWIN: NO MARKS.

Marking

The assignment is worth 30% of your total grade in this subject, and it is marked out of 30. 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.

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 8/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

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.
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.
“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.
It is your responsibility to implement each feature sufficiently well that it is readily detected through normal operation of the game. Any feature that is not apparent through normal play will be deemed to be unimplemented.
We require tutors to adhere to a strict time limit of 3 minutes play time when marking each submission. Any feature that cannot be assessed in that time will be deemed to be unimplemented. Therefore you must avoid defects in game dynamics such as extremely fast motion, extremely slow motion, inconsistent control settings, premature program termination, or other properties that render the game unfit for use.
It is better to implement some of the features extremely well than to try to do everything and deliver a substandard product.
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:
Errors in object motion, such as objects/player jumping more than one character position per frame;
Objects moving outside their permitted area;
Failure to clear the screen appropriately between updates;

Collisions involving invisible or non-existent objects;
Disturbing or flashing display;
Failure to purge the keyboard buffer at appropriate times.
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-

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 9/12

https://sefams01.qut.edu.au/CAB202/Exercise?TopicNumber=6&ProblemNumber=1 10/12

2018/8/30 CAB202 – CAB202 Assignment 1, Exercise 1: Assignment 1

Submitted files:

extensions) before the assignment 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.

Use “Attach file” to submit your solution. You may attach your solution in one C file or, if your solution is in multiple C source files and header files, you can attach a single copy of each file.

!!! Do not include more than one version of any file !!!

Do not attach multiple versions of your solution.

Files with names ending with a pattern other than .c or .h will be rejected. Please ensure that your naming convention takes this limitation into account.

A maximum of 30 files may be included in each submission. This consists of the built-in “submission.c” document, plus 29 attachments.

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:

     gcc *.c -std=gnu99 -Wall -Werror -I../ZDK -L../ZDK -lzdk -
     lncurses -lm -o a1_n9999999

where n9999999 represents your student number.
Note that the wildcard pattern *.c will compile all files with a name that ends with the extension

.c in the present working directory.

Therefore, you should organise your files in a folder alongside the ZDK 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 which may cause unpredictable build errors and/or run-time behaviour.

It is your responsibility to use this compile command locally to verify that your project will compile before submission.

If you are using the #include directive to connect multiple C source files, the #included files should be renamed to have an extension of .h to avoid errors arising from multiple definition of functions. However, in general you should not include anything other than .h files in the first place.

If compilation is successful, AMS will verify that your program has compiled successfully, and then 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 score allocated by AMS for this task is not your mark for the assignment.

Attach file:

Related Posts