Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Team Project/Team Project AI
Assessment
Introduction
This document describes the assessment for the Team Project and Team Project AI modules. You must also have read
the Task Description document for the relevant module that is on Canvas.
The assessment has the following components:
The progress check (Week 3, 5% of the marks).
The prototype demo (Week 7, 10% of the marks).
The final presentation (Week 12, 5% of the marks).
The final report, other documentation and the product (Week 12, 80% of the marks).
The general principles of the assessment (which are based on the learning outcomes) are as follows:
Product.
Presentation.
Software Engineering.
Documentation.
Teamwork.
Project Management.
Individual Contributions.
All of the assessment components above reflect this list of principles.
The Product is the game that you are creating which must implement all of the required elements, be in working order
and bug-free. Presentation refers to the way in which your team presents your work at the final submission stage. You
must present your work fully, appropriately and in an engaging manner. You must also present it realistically. Software
engineering refers to the application of software engineering principles to your development process and the product
itself. You must apply the processes that you have learned about on your course to the development of the product.
Documentation refers to the documents you must create as part of the process and the submissions. These are described
in this document. Teamwork refers to how your team works together to create the product. Project Management
refers to how the project is managed by the team in terms of roles and responsibilities and also code management. Each
student will also produce a document that describes their Individual Contribution to the team, and each team must
also agree the proportion of the work that was undertaken by each individual team member.
Each team and each individual member will be assessed on their underlying level of insight into the product, the process
and their own contribution. You are not creating marketing documents but software documents based on clear-sighted,
realistic assessment of the product, etc. This does not mean to say you should be overly-negative either, just realistic. A
lack of insight into our own work is one of the key causes of poor performance.
The progress check (Week 3) [5% of the marks]
Each team will undergo a progress check during week 3. Clearly, at that stage, you will not have completed a large
amount of the project. However, we expect you to have a clear idea about the game you are implementing by then
and to have started the implementation. Team roles should be clearly defined by this point (although team roles can
and probably will change). During the progress check we will also be looking for the level of integration of the various
components that are in development and the plan for the next stage of the project.
During the progress check we will look at:
The team’s level of organisation and sense of teamwork.
The specificity of the game idea and proposed game behaviour.
1
The current progress towards implementation.
The plan for the prototype demo.
The plan for the rest of the implementation.
The current level of code integration.
The prototype demonstration (Week 7) [10% of the marks]
In week 7 your whole team will be expected to demonstrate your game to the module leader and TA. You do not need
to create an actual (e.g. Powerpoint) presentation for this. This assessment will simply involve you demonstrating the
current state of your game to the module leader and TA and answering their questions.
Clearly, at this stage, your game will not be finished. The following will be assessed at this stage:
(1) General progress: the project needs to be roughly ‘halfway’ (or a little further) through. This will mean different
things for each team but, in general, around half of the functionality should exist. It may be that some teams have
done a little less than half due to the ‘start up costs’ that all projects encounter. However, no team should have made
significantly less than half of the progress they need to.
(2) All of the required components must exist in the product. They may all be unfinished but they must be there and
must be more than just ‘stubs’. All must be ‘on track’. In terms of the overall progress, it may be that some components
are more developed than others but no component should have been thoroughly neglected.
(3) All components of the software must be integrated. There must be no part of the product that is still in ‘standalone
mode’. No team member’s work should be separate and non-integrated.
The assessment of this demonstration will be based solely on the progress made in creating the game, according to the
above criteria.
The final presentation (Week 12) [5% of the marks]
In the final week you must do a presentation on your game. This will be done via video.
All team members must contribute1. The presentation will involve an actual presentation (with slides) and a final demon-
stration of the game. The formal presentation part will last a maximum of 10 minutes leaving 15 minutes for the game
demo and questions.
For this component of the assessment, you need an actual presentation (i.e. slides). Do not create too many slides,
however. You have a maximum of 10 minutes to talk to slides. If a team prepares too many slides, their presentation
will be shortened on the spot (by the module leader). This will lead to a lower mark for misjudgement of the time available.
For the presentation, you must consider the following scenario: you are a games development house that has developed
a complete game. You now want to sell that game to a publisher. Create a presentation that attempts to persuade the
publisher that they should buy your game. Any marketing content in your presentation must be 100% supportable by
the product itself. Do not make claims that you know are incorrect or exaggerated.
You presentation will be assessed against the following criteria:
The structure and length of the presentation.
The appropriateness of the content. Should you be talking about what you are talking about? Are you not talking
about things you should be talking about.
The clarity of the presentation. Can a person who was not in team follow your presentation easily?
The pacing of the presentation. Are you going too fast, too slow, or a mixture of both, or are you proceeding at an
appropriate pace.
Teamwork: is the presentation clearly a team effort? Was each member fully involved2?
The aesthetics of the presentation.
1Unless they have been excused by the module leader.
2ditto.
2
You wouldn’t expect a publishing house to be too concerned with the teamwork aspects but those must be evident in
your presentation. However, you must not do a presentation along the lines of: “person X did A”, “person Y did B”,
“person Z did C”, etc. A publishing house would have literally no interest in that.
The product itself will not be assessed as part of this component of the assessment. You must demonstrate it though,
as stated above.
Final report, other documents, final product (Week 12) [80% of the marks]
At the end of the module you must submit the following:
Final code base via the Git repository and via the Canvas link (one per team).
Test report (one per team).
Your final presentation (slides).
An email listing which team member submitted which document.
Your video presentation.
For the final code base you must submit your source code via the Git repo for your team (i.e. you will simply leave
it on repo) and via the Canvas upload that will be provided. Your source code must include all JUnit test classes too.
You must also submit all images and other resources that are required for your product. The folder structure you submit
must be correct, i.e. your marker will not move files around to get the product to work.
Your source code must be fully annotated with Javadoc comments.
The final report must document the development of your product. You can structure the document as you see fit but
it should include at least the following sections:
Introduction.
Requirements.
Software design: description of the software architecture of your system, any design patterns used, justification for
the selected architecture and patterns. UML diagrams should be included. In the main body of the report place
an overall UML diagram for the system. Subsystem UML diagrams should be included as an appendix.
Interface design: discuss the HCI design used, any principles behind it, HCI considerations.
Software engineering: any software engineering processes and principles used and adopted, development methodol-
ogy used.
Risk analysis: analysis of the risks associated with the chosen development methodology, software engineering
practices, software design, etc.
Evaluation: an evaluation of the project - strengths and weaknesses. What has been learned, what could have been
done better.
Summary.
Teamwork: An evaluation of how well the team worked together must be provided.
Individual contributions: Each team member must submit an quantified evaluation of the contributions of all team
members (including themselves). See below for more about this.
Individual reflections: Each team member must write one side of a4 with their own reflections on the team and on
their own contribution. These must all be included in the report.
Compulsory appendix: the coding standards adopted by the team.
The test report must include the test plan and the test results. The main body of this document should outline the
testing strategy, the principles used, the test results, and any other relevant discussion about the testing. The test report
should be included as an appendix to the main report. The name of each JUnit test class should be provided in a list
and included as an appendix. The main body of the document should also include details of the user testing undertaken,
and the results of the user testing should be included as an appendix. The test report must also include evidence of the
coverage achieved by the tests.
3
Final report and game marking
The marking for the final game and report works as follows.
The module team will award an overall mark for the game and the report: one mark. This will largely be based on the
existence (or otherwise) and quality of the core components, as required in the specification, and the contents of the report.
Each of you will also submit (jointly or individually) a personal assessment of the contribution of yourself and the other
members of your team.
Each of you should also have been submitting to Gitlab.
The module team will then decide the individual mark each team member will get. For this we will use all of the
evidence available to us. The individual assessments of the contributions of each team member are only one piece of
evidence. We will corroborate that evidence against the Git repos, the views of the TAs, our own knowledge of what has
gone on, the final presentation, etc. We do not take any statement by a student about another student literally. We do
not even take it literally if all of the team members say it. The individual mark be based on the overall mark awarded
for the game. This means that some students might get a lower mark than the overall mark and some might get a higher
mark. For some teams, the whole team will be awarded the overall mark. It depends on the team and how it functioned.
It may be necessary for the module team to meet an individual or an entire team to gain more information about the
work that has been done.
In the past we have had the situation where students have their work deleted by someone else in the team. We will look
carefully at such situations to assess why this was the case. Please be aware that if you delete other people’s work but
have not discussed it with them and agreed it, you risk getting a poor individual mark due to your lack of team ethic.
Individual contributions
As stated above, each team member must submit a document (template on Canvas) that quantifies the relative input of
each individual team member (including themselves) for each of the components of the product as a ‘percentage involve-
ment’ (the contributions to each component must sum to 100%). These documents are to submitted as appendices to
the main report.
We need you to state a global percentage for each team member, i.e. their contribution to the whole game, not their
contribution to individual components alone.
This will clearly be a personal assessment and may not accord with other team members’ perceptions of who did what. It
may not accord with the TA’s views or the module leader’s either. This document will be treated as a source of possible
information not taken literally.
If a team agrees a single document, i.e. agrees to the same contributions (not necessarily equal contributions) then the
team can submit only one document with a statement that all team members agree to it.
Where team members disagree about the apparent contributions then each individual should submit (as part of the
appendix) a separate report.
Occasionally, team members do not wish their team mates to see the contribution document they have completed. In
this case, the document can be submitted individually via Canvas but please make the module leader aware that this is
what you are doing.
Tips
Integration!
Integrate! Integrate! Integrate!
Make sure you are bringing the work of your team members together in a single ‘master’ version (on gitlab) as early as pos-
sible and, at the latest, by week 3. Waiting longer than that is a recipe for failure. The longer you leave it the worse it gets.
Integrate!