School of Computing, Engineering and Mathematics

Assessment Details and Brief

Module Title:	Multiplayer Game Development
Module Code:	CI628
Author(s)/Marker(s) of Assignment	Almas Baimagambetov

Assignment No:	1
Assignment Title:	Multiplayer Game Project
Percentage contribution to module mark:	100%
Weighting of components within this assessment:	Implementation 80% Report 20%
Module learning outcome(s) assessed:	LO1: Apply basic principles of game design to the creation of multiplayer games LO2: Critically evaluate alternative implementation architectures for multiplayer games LO3: Develop multiplayer games applying development techniques and tools guided by the adoption of appropriate professional practices.
The assessment is marked anonymously	No

Assessment Brief and Assessment Criteria:

Develop a multiplayer game client.

Assessment marking criteria/rubric:

See below

Date of issue:	05.10.2020
Deadline for submission:	14.01.2021 by 15:00
Method of submission:	e-submission (online via StudentCentral)
Date feedback will be provided	11.02.2021

1. Requirements

If one or more requirements are not met, the submission will not be accepted or will be penalised.

1. Design and develop a multiplayer game client application by choosing one of:

· (recommended option, most submissions will be of this type) Modify the provided C++ client application

· (can be agreed on individual basis, discuss with tutor first) Develop a Unity-based project that connects to the provided Java server

· (can be agreed on individual basis, discuss with tutor first) Develop an Unreal-based project that connects to the provided Java server

2. Produce a technical report that describes the design and development of the game:

· Introduction (~0.5 page): the brief / idea for the client visual design. Include link to YouTube video (details below).

· Implementation (~2 pages): highlight any technically complex implementation details and how you approached them. Justify the design and implementation choices that were made during the development. Particularly, the focus should be on networking code and tech.

· Critical Review (~1 page): identify three reasons why the design and implementation of the game are good. Further identify three reasons where the implementation could be improved and a summary of how the improvements could be made.

· Conclusion (~0.5 page): what are the main take-away messages – what are the key concepts that you learned during the development.

· Estimated grade: your self-assessed grade based on assessment criteria below. Example: Demo: A, Idea: A, Report: B, Total: A-

· References: include references to existing articles (whether books, research papers, online blogs or educational videos). Clearly identify and reference any 3^rd party tutorials / assets / code used and provide their source and license. Failure to do this is likely to lead to serious consequences, including a 0 mark.

3. Record full gameplay (from game start to game over) using OBS (or similar) and upload to YouTube as “unlisted”.

· Should be at least 720p, high quality and both the server and the client(-s) being played, clearly showing the modifications

· Voice-over (explaining gameplay aspects and implementation details) is recommended but not required

2. Deliverables

1. Full project (source code of the multiplayer game client, including assets).

2. Technical report in PDF format.

3. Submission procedure:

The project must be submitted through the Assessment & Grades area of this module on StudentCentral as a single Zip file.

Note: Students are allowed to submit work within two weeks of the published deadline (or agreed extension date), or the last working day immediately prior to the feedback date if this is shorter than two weeks. Any work submitted later than 15:00 of the date shown on the front page without an approved extension will be treated as late and capped at the pass mark.

By submitting your work you are agreeing to the following statements:

- A copy of your coursework submission may be made as part of the University of Brighton’s and School of Computing, Engineering & Mathematics procedures which aim to monitor and improve quality of teaching. You should refer to your student handbook for details.

- All work submitted must be your own (or your team’s for an assignment which has been specified as a group submission) and all sources which do not fall into that category must be correctly attributed. The markers may submit the whole set of submissions to the JISC Plagiarism Detection Service.

Assessment Criteria

	Unsatisfactory (E/F 0-39%)	Adequate (D 40-49%)	Sound (C 50-59%)	Good (B 60-69%)	Excellent (A 70-79%)	Outstanding *(A+/A 80-100%)**
Game client: (60%) (LO1,3)	Technically too simple for L6 or not compiling / running.	The game is barely playable with major issues, but server updates are handled. No consideration of potential networking issues. Data structures are not used. No 2^nd client is considered. Poor or no handling of server optional messages.	The game works to some extent. No consideration of potential networking issues. Appropriate use of common data structures with no modifications. No 2^nd client is considered. Some optional server messages are handled.	The game largely works. Potential networking issues are considered to a reasonable extent. Appropriate use of common data structures with some adaptation to fit the project. 2^nd client is considered to some extent. Most optional server messages are handled.	The game fully works, and the gameplay is fully functional. Networking issues are handled in a robust manner. Custom made data structures are used in the project. At least 2 clients connected to the same server and all optional server messages are handled.	In addition, the game client is sophisticated to be a publishable game prototype. The code demonstrates use of sophisticated ideas, concepts or algorithms, such as (not limited to) client-side prediction.
Visual design: (20%) (LO1)	Irrelevant, unused or no assets.	Very few assets used. Assets do not fit any specific genre / theme. Visually very simple, e.g. software rendered.	Assets form a single theme and of decent quality. Significant visual improvements can be made.	Assets used are appropriate, include some high quality. Visually, a coherent game.	Full range of assets: images, sounds, fonts, possibly custom formats. An excellent quality of visuals used.	Full range of assets with a professional level of quality, ready to be used in a publishable game.
Report (20%) (LO2)	Completely unsatisfactory and weak in all sections.	A poorly structured report with vague language, may include some typos and require a lot of polishing. Covers key sections but to a poor extent. Weak response to technical content.	A well-structured report, very few typos. Covers most sections but to a poor extent. A sound response to technical content.	A clearly structured well-written report. Covers all sections to a reasonable extent. A good depth and breadth of knowledge are shown.	In addition, uses precise language (terminology) and concise in its narrative. Covers all sections, providing extensive links to other sources of information. Demonstrates clear understanding of the technical details.	In addition, a deep understanding of the problem/solution in the domain is demonstrated, also with alternative solutions discussed. Sophisticated critical reflection. Professionally looking, clearly written report.