Program Consoles (CT5PROGC)
Module Code: M20199
GENERAL ASSESSMENT INFORMATION
Assessment 1 (100%): Individual or Group (your choice), Mandatory Video plus Optional Report
• Assessment length depends on size of group.
• Submit Online. Submission box and dates are on Moodle.
• This coursework qualifies for the 48hr assessment extension.
Short Description:
The coursework is either completed individually or as a group and consists of a video, plus an optional report, which combine to demonstrate and evaluate your artefact, and reflect on your progress in the module.
This coursework constitutes 100% of your marks for this module and will assess Learning Outcomes 1-4 of the module description.
Second Attempt: Repeat the above coursework.
|
MODULE ABSTRACT, LEARNING OUTCOMES AND KEY DATES
|
|
|
Program Consoles (CT5PROGC)
|
|
Abstract
|
|
The primary aim of this module is to expose you to various aspects of current-gen console development, including the hardware considerations and the programming issues associated with consoles, as well as how to improve the performance of software.
The module adopts a problem-based learning approach - you will often find yourself in unfamiliar,
unspecific or difficult territory as this is a common occurrence in professional games development
situations. Do not expect to be told exactly what to do, or how to do it - as second year university students you need to be working towards becoming independent learners. Your analytic and problem-solving skills will be put to the test, as will your patience, but with regular attendance, effort and cooperation with
peers you will no doubt succeed.
|
|
Learning Outcomes
|
|
On successful completion of this module, students should be able to:
|
|
LO 1
|
Work within the practical restrictions of software creation for consoles.
|
|
LO 2
|
Implement a software artefact capable of executing on a development console.
|
|
LO 3
|
Utilise a methodical approach to improve the performance of software artefacts.
|
|
LO 4
|
Utilise industry-standard tools and documentation effectively.
|
|
Key Dates
|
|
Formative Peer Review of your Work in Progress:
You will be using the taught sessions to show your coursework progress so far. You will be getting formative feedback on your work almost every week.
Assessment 1 (100%): Video and/or Report
Due in near the end of the module. Details and online submission via port.ac.uk/moodle
|
ASSESSMENT 1 BRIEF
Your task is as follows:
For this coursework you can choose to work on any current-gen console tech that we have available. We have lots of PS5 and Switch devkits, so you should choose one of these platforms. The taught materials provided on Moodle will focus primarily on PS5 though, so if you are not particularly confident then we suggest you choose PS5. There will be some Switch guidance too, and some of the PS5 discussion is applicable to Switch, but for a more hand-holding approach please choose PS5.
New for this year: We have been given a specific project idea from Sony for students to use! You are not required to do this, but any students/groups using the Sony brief will have the opportunity for their work to be sent to Sony for viewing and feedback at the end of the project. The brief can be found on Moodle, and please note all of the assessment information in this document still applies.
Either individually or in groups (your choice), you should create a small demo that shows your confidence with the tools and a number of libraries from your chosen platform’s SDK. The scale and scope of the demo (number of tools/libraries etc) should depend on the number of people involved in the submission, for example:
|
Size of Group
|
Number of Libraries
|
|
1
|
2 to 3
|
|
2
|
2 to 3 (in depth)
|
|
3
|
3 to 4
|
|
4
|
3 to 4 (in depth)
|
|
5
|
3 to 4 (excellent)
|
Note that the above numbers are suggestions for targets and are for indication only, it all depends on your own ability and the quality and depth of the specific implementation – you can ask for feedback on this as the module progresses. The artefact does not need to be a full game, just a demonstration that you have got different libraries working together harmoniously in some way, and are capable with the various tools provided. You can either create something from scratch or take an existing sample file and migrate features into this. Both options are challenging for different reasons, and it is going to take around 8 hours per week of effort from each team member in order to produce something of the appropriate standard. You are free to work with people who are not in the same timetabled session as you but it will be up to you to coordinate this as a group and you MUST attend your own timetabled session at the very least, or you will be noted down as absent.
You are not required to submit the actual demo code. You are required to submit a video, and if you would prefer to do the evaluation / reflection part in writing, a report too.
So this means that you can do EITHER:
• A short video demonstrating the artefact in action plus a substantial report containing all of the required discussion.
OR
• A longer video demonstrating the artefact and also presenting the required discussion via voiceover and slides.
Either way your sources need to be referenced in APA format, and either way the submission should cover the following topics:
• LO1: Discuss the practicalities of working with devkits and how you worked well (or not) to overcome any associated problems. Comparing with other platforms we have available (i.e. PS5 vs Switch) would be a big advantage – were the issues you had representative of “typical” console development?
• LO2: Demonstrate the artefact and show how well (or not) it makes use of the various libraries in the chosen platform’s SDK. You should screencap and submit some video footage from the devkit using the tools provided, even if you are submitting a report-based analysis.
• LO3: Show a methodical, quantitative approach to how you have made the code perform. better – how you define “better” is up to you, but you should base this on actual numerical evidence e.g. capture it through profiling tools, gathering data before and after optimisation.
• LO4: Evaluate your understanding and performance with regard to the documentation and tools available, demonstrating how it helped you succeed (or not). Again, evidence of specific comparison with equivalent platforms would be advantageous.
The required length for the video/report (+/- 10%) is as follows:
|
Size of Group
|
Length of Video (minutes)
|
|
Length of Report (words)
|
|
1
|
7
|
|
1500
|
|
2
|
10
|
OR
|
2000
|
|
3
|
13
|
|
2500
|
|
4
|
16
|
|
3000
|
|
5
|
20
|
|
3500
|
Important note about group work:
If you are working as a group you will need to let the lecturer know (by email: [email protected]) the names and student numbers of all people in the group. Similarly, if anyone joins/leaves the group you need to let us know – marks for groups will only be awarded according to group info we have received by email. If we haven’t been informed of you joining a group we will assume you are submitting individually.
If you are working as a group of 3 or more, the overall score for your group will be subject to a peer review process to determine individual marks for group members based on relative contribution to the project. Expectations for achievement will also be scaled to reflect the number of members in the group, and therefore the greater amount of person-hours available.
ASSESSMENT 1 SUBMISSION DETAILS
The hand-in information is as follows:
The following items should be uploaded to the dedicated drop box on Moodle before the date and time specified.
1. Your video – unzipped, no bigger than 1080p in resolution, saved in a format/codec (e.g. mp4) that can be run in Windows Media Player without any additional downloads/plugins. Remember that even if you are submitting a report, we still need you to upload a video of your demo running!
2. Your report (if applicable), in Word or PDF format.
3. Peer review forms from each group member, if you are in a group of 3 or more.
You can follow the handy guides here for help with recording and editing your video:
https://www.youtube.com/watch?v=eyF99uVXRTQ
Please be sure to TEST your video to make sure the audio quality is appropriate – If I can’t hear you, I can’t mark the work!
Labelling Your Work: Your lecturers will see hundreds of pieces of assessment work a year. You must make sure your files are labelled clearly, indicating your student number and the contents.
Example of Good Practice for labelling work: StudentNumber_Module_AssessmentName