Assignment 3 - Developing a Game
Weight 30% - 23/10/2020
To reflect on your contribution to the development of a game with emphasis on the programming and technical development.
Having developed a game with a cross-disciplinary group you will document and analyze your code contribution. This requires understanding the relationship between your code and the code created by other members of the group and included from tutorials or online resources. You will reflect on the quality of the code and discuss the complexity of constructing the game.
RequirementsYou need to be able to document the parts of the project you worked on. This included giving an indication of the blueprints/code that you were responsible, see below, and an understanding of the code. This includes what parts of the project you are proud of, what parts were the most complex and which part you would change/ represented rushed or poor code. For the poor code you can refer to any part of the project including work done by other developers. You need to submit documentation either as a markdown (.md) file in a git repo, or as a PDF with links to code.
The individual submission on the ECS submission system will have either a pdf or a link in a pdf to the individual markdown file with username.md eg “mccallsi.md” in the game repo. This allows you to reflect on the project and what you have learnt from the project without being able to update the code that was submitted in Assignment 2. If you are submitting a link comments which you would prefer not to be seen by other group members can be included during submission in the pdf file before the link.
Each individual will submit:
- Header information
- Project role
- Animal role (if used)
- Code discussion
- A description of the parts of the project you worked on, including a level of input: [ All | Most | Half | Some | Touched ]. Only mentioned touched if your involvement was important to the project overall.
- A video of you discussing the critical aspects of the code you developed in Unreal - 3-5 minutes
- A description and link to the most interesting part of code/blueprint written by you - the link can include a line number reference by adding #L2-20 on the end of the git url. or images of the blueprint
- Identification of the section of code/blueprint/Behaviour tree/... you are most proud of - and why you feel that this is particularly good code. (this could be the same as above)
- Identification of a section of code/blueprint you see as bad code/blueprint and why it represents hard to understand or poorly written code/blueprint
- Learning reflection (can be technical or personal reflections)
- Reflection on what you have learnt and how you have developed as a programmer in this project
- A description of the most important thing you will use from this project in future projects.
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”