Assignment 2 - Game PrototypeWeight 40% Due 15/10/2020
To develop skills in working in a cross-disciplinary team to create a computer game.
Working with a team to create a game in Unreal Engine.
Your group will develop a game from the concept selected into a playable game.
The assessment of the computer programming part of this assignment will be on both process documentation and the quality of the code produced. By quality, we refer to both functional requirements and non-functional requirements.
Thus your code needs to work as intended but also accurately communicate the intent of the code when read by an experienced programmer.
You will use a git version control system, github and gitlab are both acceptable systems. You must use the issue tracker and link issues to code committed using smart commits (#1).
The description of an Issue will include:
- Title of issue
- Appropriate labels so you can group issues by type
- Milestones associated with the issues (eg sprints for Scrum, or tasks in Kanban ...)
- An assignee who has primary responsibility for closing the issue. This is not necessarily the person solving the problem as you can work together to solve problems.
- Commits style:
- The majority of commits will be smart commits. These will include the #n (tag) of the issue which is associated with the code being committed.
- Commit messages should be short, no more than about 15 - 20 words. Longer commits should have the text added to the issue they are associated with.
- Comments should assist other developers in understanding the justification for a particular set of lines of code. This can be seen using “blame/annotate” to see where code comes from.
The group submission will include
- Playable executable exported from the Unreal application. Mac and PC, ( or Android or iOs by negotiation ) compatible.
- Git repository link for the Unreal project
- Gameplay Documentation Video – Link to content or uploaded in repo. This edited video will contain highlights of gameplay, particularly complex levels or particular moments that you want to highlight in the game.
- Code Documentation Video - Link to content or uploaded in repo. This video will be a video documentation of the code that you were actively involved in developing.
- Process documentation will be using git issues with associated git commits and attached comments per commit. This will use smart commits with “#num” style smart comments.
- Readme.md in the root of the repo – Brief description outlining the architecture of the game in terms of level structure and game loop. This will include:
- links to any libraries or asset origin.
- installation and setup instructions
- instructions on how to play/demonstrate the game.
You will also select a marking rubric weighting for the group.
|Presentation||The overall presentation of the project including naming things, placing links in clear places, naming files, correct submission||5||10||15|
|Video||The gameplay video linked in the submission or preferably in the repo. Shows what it needs to, but is not too long||5||10||15|
|Video||The code explanation video - this is for the group - there will be an individual video in Ass3||5||10||20|
|Process Docs||The git commits and the comments in the code. Documenting process and sharing tasks and organizing the development of the project||5||10||15|
|Game Architecture||The structure of the game. Use of blueprints/C++ code. The complexity of technology. Use of appropriate language features.||15||25||35|
|Code Quality||General quality of the code written/ blueprints created. How easy would it be to maintain and find bugs or update features||15||25||35|
|General||Overall impression of the game||5||10||20|
If you do no select a weighting you will get the Default weighting.
When referring to the code you have worked on you can claim
- All - you developed all the in this area - no one else can claim more than touching the code
- Most - you did the majority of the development, other developers can claim "some" or "touched"
- Half - you did about half the work in developing this section of code
- Some - there are bits of the code that are significant that you updated or created
- Touched - you did some important debugging.
For code involvement the interaction rules are:
- Anyone can claim to have “Touched” code. This would involve as little as single line debugging. You would only mention this if the input was significant for the project, but very small in actual change in code.
- If you claim you did “All” of a part of code no one else can claim “Most”, “Half”, or “Some”, any group member can claim they touched the code.
- If you claim you did “Most” then others cannot claim “All”, “Most”, or “Half” but up to half the group (N/2) can claim “Some” work.
- If you claim “Half” then others cannot claim “All” or “Most”, but one (1) other can claim “Half” and any number of the group (N) can claim “Some” or “Touched”