Assignment 2 - Game Prototype

Weight 40% Due 15/10/2020


Q1: Are the marks in the COMP313 Assignment #2 awarded to the group, or to the individual? It does not seem clear which is which in the outline (e.g. Code Quality)

A1: To the group but each individual will need to describe what parts of the code/blueprints they worked on.

Q2: What is the difference between the videos for Assignment 2 and Assignment 3.

A2: A2 should be more of an overview while for A3 the video can dig into specifics of your own development.

Q3: the readme say that we have to put down instructions for installation of the game. We're gonna build and provide an executable so what exactly do we need to put down for this part

A3: "install and run the executable" might be enough if that is all that needs to happen

Q4: As programmers, should we still document parts of the project that we created? Such as flipbooks and tile maps collision generation where no code is involved but it requires a lot of work?

A4: Yes document it. That is partly why the video might be needed as it can be hard to show the work as code. If you have images that is fine too. Remember that the game code is due at 5pm today, but the group programming documentation is midnight so you have a bit of time to do some documentation after you submit the game code at 5pm to show off some of what you did by midnight

Q5: In terms of what we are actually uploading on the assignment 2 submission page, am I right in saying that it's just the executable file and a txt file with the link to the git repository? Also I assume that everyone in the group does the submitting and it's not just one person who does it?

A5: you only need one of the group to submit the executable as that would be the same across the group. It is good if you all submit the link that way we can get to it regardless of who is the first for us to look at


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.

Process documentation:

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.
  • 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”
All Most Half Some Touched
All 1 0 0 0 0 N
Most 1 0 0 0 N N
Half 2 0 0 1 N N
Some N 0 1 1 N N
Touched N 1 1 2 N N