source code代写 Assignment代写 programming task代写

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

source code代写 Race To Zombie Mountain is a race-car game that you will implement with the CAB202 ZDK character-based graphics library.

Date due: 22 April 2018, 11:59:59 PM.

Introduction: source code代写

Race To Zombie Mountain is a race-car game that you will implement with the CAB202 ZDK character-based graphics library. Extended information is provided in the following sections of this document, however in a nutshell a minimal implementation should work as follows.

The game is played in a Linux terminal window(Cygwin/Mintty for Windows users). It 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. A dashboard or status display appears at the top of the window, in which information about the current state of the racing car is displayed. The player controls a race-car which is positioned near the bottom of the window, and which can move horizontally across the window. The illusion of forward motion is achieved by scenery and other objects which scroll smoothly into view at the top of the window, then travel downwards until they scroll smoothly off the bottom of the window.source code代写

The downward speed of scenery and other objects is determined by the speed of the car,source code代写

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 and obstacles which may appear on the road;

if it crashes into any obstacle it will sustain damage and stop for a period of 5 seconds after which the player will have to apply the accelerator to get back up to speed. As the car drives forward, it consumes fuel at a rate proportional to the speed of the car, and 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 a 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.

Edit – deleted the following sentence, which no longer forms part of the specification and should be ignored: “The score is the number of elapsed seconds from the start of the race.” L.B. 11 April 2018.

The assignment consists of two parts,

A and B. Part A is worth 20%. Part B is worth 10%. In Part A you will implement, test, and document a basic version of the Race to Zombie Mountain. Part A is tightly specified, with correspondingly detailed assessment criteria. In Part B, you are given the freedom to extend the basic game, demonstrating creative and insightful application of the content taught in the unit up to and including Topic 5. For Part B, you will devise one or two additional subsystems which extend the basic game. You will design, implement, test, and document your extensions. The criteria for assessment of Part B are expressed in generic terms, but they are just as rigorous and well-defined as those for Part A. You should address both parts of the assignment with a single version of your program.

Your task is to implement Race To Zombie Mountain (Parts A and B), using the ZDK library to target a generic UNIX-like system, and following the patterns and examples you have been shown in class. Detailed specifications of the required items of functionality appear in the following section.

Listen Up! source code代写

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 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 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 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 ncurseslibrary to render graphics or text is expressly prohibited.

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 Write for 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.

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,source code代写

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.

• The most appropriate format for this will be a sub-section or bullet point which describes each test, and a small number of screen-shots which show the outcome of the test.
• Some subsystems may require several tests.
• Suggested test categories for each feature in the basic game are included in the feature description.

Your mark for each feature will be awarded for what you document that you have done. Make sure you cover all relevant points in your 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.

3. TL;DR

NO REPORT: NO MARKS.

NO COMPILE IN AMS: NO MARKS.

NO RUN ON STANDARD MACHINE WITH PORTABLE CYGWIN: NO MARKS.

Part A – Basic Game (20%)source code代写

1. Splash Screen (1%)

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

• Include the name of your program, your name, and your student number.
• Also include a command list which tells the user how to play the game.
• The screen should display until the user presses any key to start playing.

Include in test plan:

• One test case is sufficient. Include a screen shot of the welcome screen.

2. Border (0.5%)

A border should be rendered around the edges of the terminal window.

• The border should adapt to the size of the window at the time the program started running.
• For this and all other criteria, you may assume a minimum screen width of 80 characters and a minimum screen height of 24 characters.
• Do not make any assumption about the maximum dimensions of the screen.

Include in test plan:

• At least three test cases, with different-sized screens.
• State the dimensions of the screen and include a screen shot for each test case.

3. Dashboard (1.5%)

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

• Elapsed time since start of game, accurate to the nearest 1/100^thof a second.
• Condition of the race car.
• Current speed of the race car.source code代写
• Amount of fuel remaining.
• Total distance travelled since the start of game.

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.
• For each test case include a suitable caption and a screen shot.
• Screen shots should be captured at various stages of a single run of the game.

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

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 leftand right keys move the car one unit left or right respectively per key-press.
• You may choose any pair of keys to function as leftand 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), roaming zombies (!), 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).
• For each test, describe set-up actions that must be taken, and report the results.
• Make sure you precisely document the source code locations where these conditions are enforced.

5. Acceleration and speed (1.5%)

Subject to constraints elsewhere in this document, pressing the accelerate and decelerate keys should increase and decrease (respectively) the speed of the car.

• You can choose any pair of keys 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: source code代写

• Test cases for meaningful combinations of (Car stationary; Car moving intermediate speed; Car going very fast) vs. (Accelerate; Decelerate).
• For each test, describe the test case combination, and capture before/after screen shots to show results on the dashboard.

6. Scenery and obstacles (4%)

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.
• 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, 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:source code代写

• Test cases for meaningful combinations of (Car stationary; Car moving intermediate speed; Car going very fast) vs. (Scenery scrolling in at top of window; Scenery in middle of window; Scenery scrolling out at bottom of window).
• For each test, describe the test case combination, and capture a pair of screen shots spaced adequately to show effects of motion on the scenery and values displayed by dashboard.

7. Fuel depot (1.5%)

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 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).
• For each test, describe the test case combination, and capture a pair of screen shots spaced adequately to show effects of motion on the scenery, in combination with the dashboard.
• Also, prove that your depots have a chance of appearing on the left and right. If this is also visible from earlier tests, include the test case but refer to the earlier screen shot to avoid duplication.

8. Fuel (1%)

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).
  • Capture sequences of two or more screen shots spaced adequately to show that time has passed and either:
    • Car has not moved and fuel has not decreased, or
    • Car hasmoved and fuel has decreased and that amount of fuel consumed is proportional to speed (which is constant).
  • Test case for refill at fuel depot.
    • Capture sequence of shots that shows approach, parking, time passed, and top-up of tank.

9. Distance travelled (1%)

The total distance travelled appears in the dashboard.

• 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).
• Capture sequences of two or more screen shots spaced adequately to show that time has passed and either:
  • Car has not moved and distance has not increased, or
  • Car hasmoved and distance has increased and that increase in distance is proportional to speed (which is constant).

10. Collision (3%)

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.
  • 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).
• Capture sequences of two or more screen shots spaced adequately to show that time has passed and:
  • Car was approaching obstacle/scenery from designated direction.
  • Car was immediately adjacent to obstacle/scenery.
  • Car immediately after the collision, or Game Over dialogue.

11. Game Over Dialogue (2%)source code代写

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).
• A single screen shot for each should suffice.
• Indicate in report clearly how you restart the game.

12. Pause and single step (0%)

To aid in testing, you may implement Pause and Single Step functions as demonstrated in the lecture recording for Week 4.

• This function can be implemented by direct copy from a code example. There is no credit for this function.
• Include instructions about how to pause, single-step, and resume the game on your Splash Screen.

Part B – Advanced Game (10%)

This is a chance to showcase your skills with arrays and functions in an open-ended setting. Your brief in Part B is to design, implement, and test one or two additional subsystems which form meaningful extensions to the game.

As is the case for Part A, your solution to Part B must be fully documented in the report in order to qualify for credit.

1. Extension(s) form a compelling continuation of the Basic Game (0%; PREREQUISTIE FOR ALL OTHER MARKS IN PART B)

Your extension(s) must extend the original game in a sensible manner.

• If a proposed extension is not a compelling addition to the game specified in Part A, it will receive a score of 0.

Examples of safe extensions are:

• Implementation of more realistic acceleration and deceleration, with a gear-box system which governs acceleration and maximum speed.
• A great many (20+) zombies move around the playing area, behaving like scenery except that they don’t stand still. In this case, motion must be relative to the scenery, not relative to the screen. Upon collision, the car would be damaged as usual, while the zombie would re-spawn off-screen ready to scroll into view as the car moves forward.
• Pixel-level collision detection which would allow risky close-call manoeuvres and near-misses.source code代写
• A fleet (20+) of AI cars which scroll onto the screen like obstacles, but drive forward at moderate speeds and weave left and right, potentially blocking or colliding with the player. A technically interesting variant of this would be cars that have been overtaken and left behind being able to scroll onto the screen from the bottom if the player slows down.

• A raceway that instead of remaining locked in the middle of the screen,

veers left and right, and perhaps occasionally gets very narrow. Corollaries of this would include modified algorithms for placement of scenery, obstacles, and fuel depots.

• A raceway in which a very large number of scenery, obstacles, and fuel depots remain in fixed but randomised world co-ordinates, spread out over a distance of a couple of kilometres. The internal position of the car would synchronise with world co-ordinates to produce the effect of repeating laps on the track.

• Any reasonably sensible extension which remains true to the genre of Part A will be accepted. Incongruous extensions, such as a sudden jump into a completely unrelated game, will be rejected.

2. Extension(s) introduce a minimal number of additional global variables (1%)

Excessive use of global variables is a symptom of bad software engineering.

• You may introduce a maximum of 5 additional global variables altogether.

3. Array(s) are used. (3%)

At least one extension generalises or replicates some aspect of the game in such a way that an array is the most appropriate implementation choice.

• All collections of variables which should properly be elements of an array are aggregated into an array.
• Correctly written loop constructs are used to process the elements of arrays in all places.
• Break and continue are used on all appropriate occasions to selectively stop processing elements of an array or skip one or more elements of an array.

4. Functions are used to decompose the task (3%)source code代写

The program is implemented as a collection of cooperating functions.

• Duplicated code is eliminated by introducing functions.
• Each function is substantially unique. Functions are not duplicated.
• Parameters are used to transfer information from one function to another.
• No function in the entire program (including Part A) may have more than 20 executable lines of code.
  • This does not include comments or lines which contain a single opening or closing brace character.
  • No line may contain more than one executable statement.

5. Extension(s) are comprehensively tested and documented (3%)

Your extended program has a clearly articulated design and test plan, both of which are reported in the same manner as for Part A.

Marking source code代写

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.
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.
   • “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.It is your responsibility source code代写

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.

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

6.It is better to implement some of the features extremely well than to try to do everything and deliver a substandard product.source code代写

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

• If your solution consists of a single C source file, you may eitherpaste the contents into the text area provided below, or use the “Attach file” button to load your file into a new text area.
• !!! Do not include more than one version of any file !!!source code代写
• If your solution consists of multiple C source files and header files, use “Attach file” to attach a single copy of each file.
• Do not attach multiple versions of your solution.
• Files with names ending with a pattern other than .cor .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.source code代写

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

更多其他： 数学代写  assignment代写 C++代写  代码代写 作业代写  作业帮助 数据分析代写 code代写 java代码代写

合作平台：天才代写 幽灵代写  写手招聘 Essay代写