Complete using C code and run through unix terminal:

Race To Zombie Mountain is a race-car game that you will implement with the 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. 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 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. The score is the number of elapsed seconds from the start of the race.

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.

Part A Basic Game (20%)

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.

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.

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/100th of a second.

Condition of the race car.

Current speed of the race car.

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.

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 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), 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.

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:

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.

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:

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.

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.

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 has moved 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.

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 has moved and distance has increased and that increase in distance is proportional to speed (which is constant).

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.

Game Over Dialogue (2%)

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.

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.

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

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.

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

Array(s) are used. (3%)

Functions are used to decompose the task (3%)

ZDK Library:

https://1drv.ms/f/s!At8jiexFYHfugQ1PX2YCLVuS_keF