Name
Student Number
Project Title
Project Overview / [[Provide a brief one paragraph overview of your project in terms of the overall aims]]
Key Outcomes / [[Briefly outline, using bullet points, the key functional outcomes associated with your project, i.e. what it is that you have accomplished]]
Languages / [[Provide details of the languages, tools or technologies that you used during your project]]
Area / Mark allocation
Organisation and Approach / 10
Complexity of Development / [[10-40]]
Quantity of Development / [[10-40]]
Code Architectural Quality / [[10-40]]
Code Performance Quality / [[10-40]]

The ‘Organisation and Approach’ section is fixed at 10 marks. The remaining sections are project dependent, with a minimum of 10 assigned marks and a maximum of 40 assigned marks. The total number of assigned marks across all five sections must sum to 100.

The following sets of assessment criteria assume that a quantity of 30 marks has been allocated to the particular section (this does not apply to the Organisation and Approach section which is worth a fixed number of marks).

Allocating less than 30 marks to a particular section will entail that it is easier to score a high conceptual mark. Allocating more than 30 marks to a particular section entails that it is more difficult to score a high conceptual mark.

This section is concerned with how you approach the project. In other words, the extent to which you approached the project in a manner that helped you succeed and make progress within your project.

Mark Category / Description
1st [70-100] / Worked with exceptional effort through-out sprints. Demonstrated excellent planning skills. Demonstrated excellent reflection within sprints.
2.1 [60-70] / Worked with strong effort through-out sprints. Demonstrated good planning skills. Demonstrated good reflection within sprints.
2.2 [50-60] / Worked with acceptable effort through-out sprints. Demonstrated acceptable planning skills. Demonstrated acceptable reflection within sprints.
3rd [40-50] / Worked with acceptable effort in most sprints. Demonstrated acceptable planning skills. Demonstrated insufficient reflection within sprints.
Fail [0-40] / Worked with acceptable effort in few sprints. Demonstrated unacceptable planning skills. Demonstrated insufficient reflection within sprints.

This section is concerned with the algorithmic complexity of your development. Was the development complex in the sense of being mathematically or computationally rich? Being able to tackle a complex development demonstrates not only that you can conceptually handle the complexity but also that you can develop and debug software that deals with such complexities. Complexity within this section will be measured against the following intertwined metrics:

·  Mathematical complexity (does your development involve significant mathematical modelling).

·  Algorithmic complexity (does your development involve significant algorithmic computational complexity, this might be in terms of a highly parallelised algorithm, complex internal logic, etc.).

·  Hardware complexity (does your development involve complex hardware interaction, e.g. utilising hardware such as a GPU/PPU).

Mark Category / Description
1st [70-100] / Project assessed to have very high complexity
2.1 [60-70] / Project assessed to have high complexity
2.2 [50-60] / Project assessed to have reasonable complexity
3rd [40-50] / Project assessed to have borderline complexity
Fail [0-40] / Project assessed to have insufficient complexity

This section is concerned with the size of your development (crudely as measured in terms of LOC). It is important to stress that a project which offers a small set of features may still be considered a large development (measured used a LOC metric).

It is also important to stress that artificially inflating a project’s LOC count (to include inefficient code and/or irrelevant functionality) will not count towards this section.

The baseline of comparison is that which could be reasonably expected of a Level 3 student (where the student has been assumed to be working on the project design, code development and code debugging for an average of six hours/week over a twelve week period).

Mark Category / Description
1st [70-100] / Project assessed to strongly exceed base expectations
2.1 [60-70] / Project assessed to comfortable exceed base expectations
2.2 [50-60] / Project assessed to match base expectations
3rd [40-50] / Project assessed to fall short of base expectations
Fail [0-40] / Project assessed as inadequate against base expectations

This section is concerned with the quality of your architectural design. In particular, have you designed your game component so that it can be easily integrated with other components, or easily utilised by an end-developer, or easily extended/modified to incorporate new behaviour or change existing behaviour.

Mark Category / Description
1st [70-100] / High extensible and customisable component design that can be readily and flexibly integrated into a wider game engine and offers ease of use to end developers.
2.1 [60-70] / Extensible and customisable component design that can be readily integrated into a wider game engine and offers ease of use to end developers.
2.2 [50-60] / Extensible component design that can be integrated with some effort into a wider game engine.
3rd [40-50] / Component design with limited extensibility / customisation that can be integrated into a wider game engine with some dependencies/assumptions.
Fail [0-40] / Component design with inadequate extensibility / customisation that could not be readily integrated into a wider game engine.

This section is concerned with the performance quality of your code. In particular, have you written your game component in a manner that is likely to be fast/efficient – measured in terms of execution time, memory footprint, cache usage, etc. To score high marks you should be able to demonstrate the coding standards and practices you have adopted to maximise code performance.

To score highly in this section every line of code need not have been written to maximise performance, although, you should have been able to identify execution critical sections which have then been optimised.

Mark Category / Description
1st [70-100] / Comprehensive approach adopted towards identifying critical code regions, coupled with excellent high performance optimisation.
2.1 [60-70] / Comprehensive approach adopted towards identifying critical code regions, coupled with appropriate high performance optimisation.
2.2 [50-60] / Partial approach adopted towards identifying critical code regions, coupled with mostly appropriate high performance optimisation.
3rd [40-50] / Limited (scattergun) approach adopted towards identifying critical code regions, coupled with some regions of mostly appropriate high performance optimisation.
Fail [0-40] / No approach adopted towards identifying critical code regions, coupled with some few regions of mostly appropriate high performance optimisation.