Assessments: AssignmentThere is one assignment in three stages. After the first stage, eachbuilds on the work of the previous one.The assignment is to build the flying stickman game.11Super 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 fromyour class. Your tutor will determine whose. Make sure your codeis nice to maintain. . .There is no group coding in this course22Yay!But how will it be graded?And while we’re at it, what if I get some code I really hate, or thatdoesn’t work?1. We will attempt to find code that works. If we can’t then thatdoesn’t bode well.2. The grade for Stages after the first will be based on what youadd as well as how well you work with the existing code(simply replacing previous code with your own is notacceptable).3. The assessment for the first Stage will be easy because we’reassessing the difference between nothing and your code.4. Marks for subsequent stages will be based on the differencebetween your code and its previous version.� The Three Stages of theAssignment �Stickman is all aloneStage one: A lonely stickmanWrite a graphics program using QtCreator to model the basic dynamics ofa side-scrolling gameThere will be a small text “.config” filein which the details of the stickman’sinitial position, their size, and thespeed they are travelling, along withthe dimensions of their world.Stage 1 OverviewThe first stage of your assignment is to create a graphics displayusing Qt Creator (whichever version works but a recent version ifpossible!). Remember you must demo your code on the labmachines.I Configuration file in a format that YOU specify — NOTQSettings. Use a TEXT file format. Call it what you want.I The background must move at a constant speed. Thestickman remains stationary until stage 2.I The stickman can be created in four sizes defined as wordswithin the config file.I You will select a coding style to use, and specify it in theaccompanying README.txtStyle IYour specified style may be as simple as referring to an existingC++ style guide, or you may specify your own variations. Writingyour own complete style guide would be far too excessive for anassignment.e.g. The style for this project is based on the Google C++ styleguide (link) with the following variations:I The base indentation is 4 spacesI System header includes come before local header includes.You are expected to follow your own style guide (as will anyoneextending your project).Config file IThe 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 coordinateI Stickman’s starting velocityI Background imageI Anything else you want, that’s not specified in later stages.Marking guidelines I50%: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 sizesI the background moves not the stickmanMarking guidelines II25%:I appropriate use of a creational design pattern, with commentsto explain its use;I sensible error checking, e.g., for missing or incorrectconfiguration files;I clear code using meaningful variable and method names aswell as informative commenting and documentation;Marking guidelines III10%:I memory, and other resources, are handled efficiently;I clear code structure, that will be simple to maintain andextend;Marking guidelines IVThe 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 stickmanfrom within the program and then save the changes to a newconfiguration file,I pause and resume play (must not use the space bar or left andright keys, they are reserved for Stage 2 and 3);I animating the stickman (giving them a unicycle to rideperhaps)I Documention of the extensions. e.g. README.txt to describethe features, and inline comments for developers tounderstand them.5% penalty for each feature implemented from later stages.Stage 2What’s required for Stage 21. One to two A4 pages typed review of the Stage 1 code youreceived. Portable Document Format (pdf) only. Thiscomponent is worth 5%.2. Extensions of the Stage 1 code. This component is worth10%.Marking guidelines IStage 2 is worth 15% to your final grade.The first part is 5% and is a one-to-two page review of the codeyou received.Don’t skimp on the writing.Illustrate using standard UML if you believe it will help.Marking guidelines IIYour review will have 5 sections:Documentation: how well was the code described, either as in-codecomments or if there was separate documentation?Extensibility: how well designed was the code for the extensionsthat you hope to make to it?Design: what design patterns did t代写wikipedia留学生作业、C++编程设计作业调试、代写C++课程设计作业、代做graphics display作he code use? Comment onwhether you think they were good or poor choices,and justify your comments.Implementation: was the coding well done? What would you havedone differently? What was good about theimplementation?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 easilybe made.Marking guidelines IIIMarks will be removed forI poor spelling, grammar and/or punctuation;I bad organisation;I unprofessional terminology such as “the previous guy was anidiot” or “this is rubbish coding”;I incorrect format submission (-1 mark penalty each time).Extending Stage 1 IObstacles:I Obstacles are initially laid out as a sequence according to theconfiguration file. Obstacles are rectangular and their positionis based on the y coordinate.I Obstacles must have configurable size and spacing betweenthem.I The obstacles should move at the same rate as thebackground.I Once the sequence of obstacles defined in the config filefinishes it should restart from the beginning (the game neverends).Extending Stage 1 IIMovement:I When the stickman hits an obstacle the background andobstacles should stop moving.I The stickman should be able to jump over obstacles usingspace bar. Once they have jumped above an obstacle, theobstacles and background should resume moving.I A test mode exists that replaces the graphical interface with atest interface for automated testing. The tests will includethat collisions stop movement, and that jumping over anobstacle resumes movement.Marking scheme IThe 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 thestickman and the obstacles on the screen;I crash safety: the program will not crash given invalidconfiguration files;Marking scheme II15%:I intersection code works as expected and is extensibleI clear code using meaningful variable and method names aswell as informative commenting and documentation;Marking scheme III10%:I correctly deals with overlapping items: later obstacles cannotbe placed over existing obstacles (and should be abandoned)I different coloured obstacles as specified in the config file;Marking scheme IV15%, more sophisticated extensions:I obstacles which move along the y axis at a specified rateI double jumpI obstacles can have different shapes, as specified in the configfile.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 3For your extension of Stage 2 : It’s finally a gameI Just code: extend Stage 2 to complete the Flying Stickmangame. 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 youto move both backwards and forwards.2. The ability to lose. Crashing into obstacles now will result inthe 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 levelsand then to finally win.4. An ability to provide a score to the user.5. Finally there should be powerups. The powerups shouldtransform the stickman into their four personas each whichshould provide a possible advantage.Marking Scheme50%:I it must compile and run in the lab (but this time you may useyour laptop)I preserve the previous two stage’s functionalityI appropriate use of a behavioural design patternI clear code using meaningful variable and method names aswell as informative commenting and documentationI the stickman must have a configurable number of livesI When the stickman intersects with an obstacle they lose a lifeand restart the levelI a score must be displayed, showing how well the player isdoing (this could be as simple as a timer or as complex as youlike)Credit15%:I user control over the stickman. The left and right keys willcontrol the character which will then in turn move thebackground and the obstaclesI there must be levels (at least 2) and therefore must becheckpoints that you can reach in each level to move you onto the nextI a memory efficient design;Distinction10%:I include power-ups: the power-ups should alternate thestickman between their four states. Tiny mode should permityou to walk underneath some obstacles, large should permityou to jump higher than normal mode, and giant mode shouldmake 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 Distinction15%, add some cool extensions, such as:I further power-upI infinite levelsI a scoreboard that persists between games!I more things with exclamation marks!!Make sure you discuss your extension idea(s) with your tutorbefore you go ahead with them.转自：http://www.7daixie.com/2019042422487567.html
网友评论