联系方式

  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-21:00
  • 微信:codinghelp

您当前位置:首页 >> C/C++编程C/C++编程

日期:2019-04-23 10:44

Assessments: Assignment

There is one assignment in three stages. After the first stage, each

builds on the work of the previous one.

The assignment is to build the flying stickman game.

1

1Super Mario Bros. http://en.wikipedia.org/wiki/Super Mario Bros.

Hell is Other People

’s code. (misquoted from Sartre.)

The first stage you will do yourself.

At stages two and three, you will extend someone else’s code from

your class. Your tutor will determine whose. Make sure your code

is nice to maintain. . .

There is no group coding in this course2

2Yay!

But how will it be graded?

And while we’re at it, what if I get some code I really hate, or that

doesn’t work?

1. We will attempt to find code that works. If we can’t then that

doesn’t bode well.

2. The grade for Stages after the first will be based on what you

add as well as how well you work with the existing code

(simply replacing previous code with your own is not

acceptable).

3. The assessment for the first Stage will be easy because we’re

assessing the difference between nothing and your code.

4. Marks for subsequent stages will be based on the difference

between your code and its previous version.

 The Three Stages of the

Assignment 

Stickman is all alone

Stage one: A lonely stickman

Write a graphics program using Qt

Creator to model the basic dynamics of

a side-scrolling game

There will be a small text “.config” file

in which the details of the stickman’s

initial position, their size, and the

speed they are travelling, along with

the dimensions of their world.

Stage 1 Overview

The first stage of your assignment is to create a graphics display

using Qt Creator (whichever version works but a recent version if

possible!). Remember you must demo your code on the lab

machines.

I Configuration file in a format that YOU specify — NOT

QSettings. Use a TEXT file format. Call it what you want.

I The background must move at a constant speed. The

stickman remains stationary until stage 2.

I The stickman can be created in four sizes defined as words

within the config file.

I You will select a coding style to use, and specify it in the

accompanying README.txt

Style I

Your specified style may be as simple as referring to an existing

C++ style guide, or you may specify your own variations. Writing

your own complete style guide would be far too excessive for an

assignment.

e.g. The style for this project is based on the Google C++ style

guide (link) with the following variations:

I The base indentation is 4 spaces

I System header includes come before local header includes.

You are expected to follow your own style guide (as will anyone

extending your project).

Config file I

The Configuration file stores:

I The size of the stickman as a string. The options are: tiny,

normal, large, and giant. (These will be used in Stage 3)

I Stickman’s starting position as an x coordinate

I Stickman’s starting velocity

I Background image

I Anything else you want, that’s not specified in later stages.

Marking guidelines I

50%:

I it must compile and run on the lab machines;

I sensible / appropriate OO design.

I it must read the configuration file;

I stickman has four sizes

I the background moves not the stickman

Marking guidelines II

25%:

I appropriate use of a creational design pattern, with comments

to explain its use;

I sensible error checking, e.g., for missing or incorrect

configuration files;

I clear code using meaningful variable and method names as

well as informative commenting and documentation;

Marking guidelines III

10%:

I memory, and other resources, are handled efficiently;

I clear code structure, that will be simple to maintain and

extend;

Marking guidelines IV

The final 15%:

I Extensions to the functionality that are simple and effective,

using only Qt libraries and what you write: e.g.,

I sound effects,

I ability to change colours and position and size of the stickman

from within the program and then save the changes to a new

configuration file,

I pause and resume play (must not use the space bar or left and

right keys, they are reserved for Stage 2 and 3);

I animating the stickman (giving them a unicycle to ride

perhaps)

I Documention of the extensions. e.g. README.txt to describe

the features, and inline comments for developers to

understand them.

5% penalty for each feature implemented from later stages.

Stage 2

What’s required for Stage 2

1. One to two A4 pages typed review of the Stage 1 code you

received. Portable Document Format (pdf) only. This

component is worth 5%.

2. Extensions of the Stage 1 code. This component is worth

10%.

Marking guidelines I

Stage 2 is worth 15% to your final grade.

The first part is 5% and is a one-to-two page review of the code

you received.

Don’t skimp on the writing.

Illustrate using standard UML if you believe it will help.

Marking guidelines II

Your review will have 5 sections:

Documentation: how well was the code described, either as in-code

comments or if there was separate documentation?

Extensibility: how well designed was the code for the extensions

that you hope to make to it?

Design: what design patterns did the code use? Comment on

whether you think they were good or poor choices,

and justify your comments.

Implementation: was the coding well done? What would you have

done differently? What was good about the

implementation?

Style: comment on the style of the code. Were names,

layout, code clich′es consistent?

If you have studied the code thoroughly the above points can easily

be made.

Marking guidelines III

Marks will be removed for

I poor spelling, grammar and/or punctuation;

I bad organisation;

I unprofessional terminology such as “the previous guy was an

idiot” or “this is rubbish coding”;

I incorrect format submission (-1 mark penalty each time).

Extending Stage 1 I

Obstacles:

I Obstacles are initially laid out as a sequence according to the

configuration file. Obstacles are rectangular and their position

is based on the y coordinate.

I Obstacles must have configurable size and spacing between

them.

I The obstacles should move at the same rate as the

background.

I Once the sequence of obstacles defined in the config file

finishes it should restart from the beginning (the game never

ends).

Extending Stage 1 II

Movement:

I When the stickman hits an obstacle the background and

obstacles should stop moving.

I The stickman should be able to jump over obstacles using

space bar. Once they have jumped above an obstacle, the

obstacles and background should resume moving.

I A test mode exists that replaces the graphical interface with a

test interface for automated testing. The tests will include

that collisions stop movement, and that jumping over an

obstacle resumes movement.

Marking scheme I

The programming part is worth 10% for Stage 2.

50%:

I it must compile and run on the lab machines;

I Stage 1 behaviour, and interface, must be preserved;

I appropriate use of a structural design pattern;

I it must correctly use the configuration file to place both the

stickman and the obstacles on the screen;

I crash safety: the program will not crash given invalid

configuration files;

Marking scheme II

15%:

I intersection code works as expected and is extensible

I clear code using meaningful variable and method names as

well as informative commenting and documentation;

Marking scheme III

10%:

I correctly deals with overlapping items: later obstacles cannot

be placed over existing obstacles (and should be abandoned)

I different coloured obstacles as specified in the config file;

Marking scheme IV

15%, more sophisticated extensions:

I obstacles which move along the y axis at a specified rate

I double jump

I obstacles can have different shapes, as specified in the config

file.

Discuss your extension idea(s) with your tutor before you go ahead!

Penalty of 1 mark if you go on and implement the next stage.

Stage 3

For your extension of Stage 2 : It’s finally a game

I Just code: extend Stage 2 to complete the Flying Stickman

game. This will include:

1. Adding user control for the rate at which the character moves

(they don’t move on their own any more). This will allow you

to move both backwards and forwards.

2. The ability to lose. Crashing into obstacles now will result in

the loss of a life.

3. The ability to win. The obstacles should no longer repeat,

rather there should be checkpoints to take you to new levels

and then to finally win.

4. An ability to provide a score to the user.

5. Finally there should be powerups. The powerups should

transform the stickman into their four personas each which

should provide a possible advantage.

Marking Scheme

50%:

I it must compile and run in the lab (but this time you may use

your laptop)

I preserve the previous two stage’s functionality

I appropriate use of a behavioural design pattern

I clear code using meaningful variable and method names as

well as informative commenting and documentation

I the stickman must have a configurable number of lives

I When the stickman intersects with an obstacle they lose a life

and restart the level

I a score must be displayed, showing how well the player is

doing (this could be as simple as a timer or as complex as you

like)

Credit

15%:

I user control over the stickman. The left and right keys will

control the character which will then in turn move the

background and the obstacles

I there must be levels (at least 2) and therefore must be

checkpoints that you can reach in each level to move you on

to the next

I a memory efficient design;

Distinction

10%:

I include power-ups: the power-ups should alternate the

stickman between their four states. Tiny mode should permit

you to walk underneath some obstacles, large should permit

you to jump higher than normal mode, and giant mode should

make you immune to obstacles that is they explode on impact;

I a sensible testing framework for your code3

;

3Note: that doesn’t mean you don’t have to test your code before this!

High Distinction

15%, add some cool extensions, such as:

I further power-up

I infinite levels

I a scoreboard that persists between games!

I more things with exclamation marks!!

Make sure you discuss your extension idea(s) with your tutor

before you go ahead with them.


版权所有:编程辅导网 2021 All Rights Reserved 联系方式:QQ:99515681 微信:codinghelp 电子信箱:99515681@qq.com
免责声明:本站部分内容从网络整理而来,只供参考!如有版权问题可联系本站删除。 站长地图

python代写
微信客服:codinghelp