联系方式

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

您当前位置:首页 >> Python编程Python编程

日期:2019-10-29 09:41

Software Design Phase

Problem Description

Your final assignment will be to extend an existing implementation of 'Stickman' (that is not your own) to add

features, leveraging your knowledge of OOP and design patterns. This will then drive your written code review

of the existing implementation.

Implementation Details

Prior to beginning on this phase you will be sent an implementation of Stickman Stage 2. This implementation

may be from a student of this or a different semester, or may be from the teaching team (for privacy reasons

no names or identification will be given). Your goal is to extend andmaintain this implementation. What this

means is to add features to the existing implementation without breaking the implementation (it runs - rule #1

is don't break working code) or using unnecessary 'hacks', by using OO design best practices and appropriate

patterns throughout. Some of the feedback you will have received in earlier phases will be relevant to

identifying what is or is not best practice, but you will need to apply this to the new context of somebody else's

code.

You are not required to correct the existing design of the implementation - you must retain the existing design

wherever changes are not required and will be penalised should this be changed without cause (for example,

replacing the given implementation with your own phase 2 code). The idea here is that you work with the

existing design rather than against it and minimise required changes to the existing structure (reasonable,

limited scope refactoring to support extensions is encouraged).

There are 3 features you must implement:

Level Transition - moving from level 1 to n as the hero achieves the goal (finish line crossed) then

showing 'Winner' when level n is completed. These levels can either be contained within the same

configuration file, or you can use multiple configuration files.

Score - The game must record and display on the screen an updating score. Levels have a target time

(set in the configuration file) - for every 1 second below this time there is 1 point, for every 1 second over

this time there is -1 point. There are +100 points per enemy defeated. Losing a life does not impact

points. The minimum level score is 0. You must display the current level's score on screen during the

level (which will visibly be counting down to 0), as well as the total score for all previous levels.

Save and Load - the player must be able to save the state of the game (quicksave), then reload that

saved game at any point in time (quickload). The full state of the game must be reverted to the saved

state at that time (including Level, Score, and all Entities). This must be a single saved state that is not

written to disk, and each subsequent quicksave overwrites the existing saved state. Quickload reverts

the game state to the single saved version. This should be controlled using keyboard keys (e.g. q and s).

Demo Details

You are required to demonstrate your implemented features to your tutor. In order to keep a level playing field

with the different tutorial times and days this must be based on code you submit on the Monday of Week 13 -

the submission box will close at 11:59pm on Monday night and no further submissions can be accepted

without Special Consideration or Academic Plans. As there is no direct mark weight to this part of the

assessment the usual 5% late penalty format cannot be applied.

Your code must run on the university lab machines without editing. The specific process will be the tutor

observing you downloading the zip folder of your code onto a lab machine (not your own), unzipping this

folder, and using gradle run. Your code must run without modification or IDE to be accepted. You should test

this prior to the demo day! Your tutor will then test out the extensions you have implemented.

Please note that these features are all or nothing: 3 partially working features = 0 features. For this reason you

should work on them in sequence before moving on to the next feature.

If you wish to demo your code in Week 12 this is also acceptable (and highly recommended).

Submission Details

Please refer to the Assessment Information page on Canvas for report due dates and submission instructions.

Marking Criteria (15%)

There are no marks awarded for the coding portion of this assignment- the coding portion qualifies you

to write a review of your given codebase and your changes which is where marks will be earned. You are

required to demo these features in the Week 13 tutorial. Please note there is no late demo possible with

the exception of Special Consideration or Academic Plans.

Your marks are 'capped' based on your successfully demoed features: 3 features = max of 15/15, 2

features = max of 12.5/15, 1 feature = max of 10/15, no features = max of 7.5/15 Note this is a cap, not

a penalty - a report that would have earned 12/15 with only 1 feature demoed will receive 10/15.

15 Marks for the final report, being a review of your provided codebase, and a description and review of

your extensions

6 marks: For the existing codebase you must analyse:

The use of OOP design principles

The use of design patterns

The code style and documentation

How easy or difficult the above made it to achieve your required functionality and why

6 marks: For your additional features you must

Describe your extensions (only discuss extensions that were actually present in your

demo)

Highlight your application of OO design principles in your extensions, explain what they

motivated you to do and why

Document any design patterns used and rationalise their usage.

Provide a UML Diagram that highlights the updated code and design patterns.

Reflect on your extension design, highlighting any outstanding issues and improvements

that can be made.

3 marks:

Your report must be written clearly and concisely

Warning: Any attempts to deceive or disrupt the marking system will result in an immediate zero for the entire

assignment. Negative marks can be assigned if you do not properly follow the assignment specification, or

your code is unnecessarily or deliberately obfuscated.

Academic Declaration

By submitting this assignment you declare the following:

I declare that I have read and understood the University of Sydney Student Plagiarism: Coursework Policy and

Procedure, and except where specifically acknowledged, the work contained in this assignment/project is my

own work, and has not been copied from other sources or been previously submitted for award or

assessment.

I understand that failure to comply with the Student Plagiarism: Coursework Policy and Procedure can lead to

severe penalties as outlined under Chapter 8 of the University of Sydney By-Law 1999 (as amended). These

penalties may be imposed in cases where any significant portion of my submitted work has been copied

without proper acknowledgement from other sources, including published works, the Internet, existing

programs, the work of other students, or work previously submitted for other awards or assessments.

I realise that I may be asked to identify those portions of the work contributed by me and required to

demonstrate my knowledge of the relevant material by answering oral questions or by undertaking

supplementary work, either written or in the laboratory, in order to arrive at the final assessment mark.

I acknowledge that the School of Computer Science, in assessing this assignment, may reproduce it entirely,

may provide a copy to another member of faculty, and/or communicate a copy of this assignment to a

plagiarism checking service or in-house computer program, and that a copy of the assignment may be

maintained by the service or the School of Computer Science for the purpose of future plagiarism checking.


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