Software Design PhaseProblem 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.