INM379 Computer Games Architecture: Coursework Specification
Daniil Osudin (Examiner)
Synopsis
The aim of the coursework is to give you experience of using a deployment-ready production framework
to produce a fully functional game demonstrating sound architectural principles in separating game
engine and game logic code. Your code should employ design patterns and a data/event-driven
architecture to produce loosely coupled code.
You will be developing a game demo using C# and MonoGame with Visual Studio.
The coursework is a single piece of individual work, worth 100% of the final course module mark.
Task
You are to produce a demo of a casual game of your choice in 2D, 2.5D (2 dimensional game-play with
3D rendering), or 3D. You may choose from the following game genres (other game types may be
implemented with written permission from the module leader):
1) Top-down racing game
2) Fast-paced space or flight shooter (side scrolling)
3) Mario-style platform game
4) Side-scrolling fighting game
5) Sports related simulation
The game will be a demo in the sense that it should demonstrate key features of both your game engine and
the game you wish to create but need not be ready for release or feature-complete.
The demo will be built in three coding-based parts, with implementation and documentation receiving equal
marks for each section. There is an additional fourth part which is marked on documentation only.
Part 1 (28%, 7% for each section):
1) Load appropriate assets for the game type using a resource management strategy.
2) Control of the game character or first-person view using keyboard, joystick, mouse or touch
control. An event-driven architecture should be used to separate input hardware from the
responding code.
3) Collision detection or alternative hit detection using basic brute force techniques.
4) Moving and animated game elements, demonstrating frame-rate independent game loop control.
Part 2 (28%, 7% for each section):
1) Configurable game world with positions/attributes of game elements/opponents demonstrating a
data-driven approach.
2) Removal of game elements based on collision response, showing separation of collision
detection and collision response code.
3) Scoring system demonstrating use of event listeners.
4) High-score table demonstrating use of serialization or an alternative approach to provide a game
state load/save mechanism.
Part 3 (28%, 7% for each section):
1) Start-screen (containing intro and keyboard controls) and game over screen (with score and
restart options) demonstrating use of state pattern and FSM with game loop.
2) Power-ups demonstrating use of event-listeners and re-use of a base-class for game objects.
3) NPC opponents demonstrating FSM control of game objects.
4) Overall game-play and presentation, including use of additional level challenges as necessary
(e.g. timer count-down, lives).
Part 4 (7% documentation only – 500 words maximum)
a) An analysis of improvements to the speed of your algorithms that have been, or could be,
achieved using your knowledge of hardware architecture.
OR
b) A discussion of the use of profiling software to improve the performance of your game engine.
OR
c) Diagrams and supporting documentation showing how your game architecture could be adapted
for use as a network game.
Presentation Viva: 9%
The viva should present:
• The functionality of the demonstration.
• A clear explanation of what was implemented and why.
Deadline and Deliverables
The deliverables are as follows:
• A 10 minute in-class demonstration in the week 11 laboratory session (you can use your own laptop,
if you wish).
o This is worth 9% of the coursework mark.
o Peers will provide additional feedback (on an advisory basis).
• Report of what you did, how and why (online submission).
o This is worth 50% of the coursework mark for parts 1 to 3, and 100% of part 4.
o This should be no longer than twenty five (25) pages of A4 in Microsoft Word format.
o Make your sources clear.
• The working system (online submission).
o This is worth 50% of the coursework mark for parts 1 to 3.
o The complete MonoGame project.
The online deliverable should be submitted as a single ZIP file via Moodle. Note that Moodle has a
maximum submission size of 200MB. You should ensure that your project is cleaned of all unnecessary
build files, pre-compiled header files etc. (remove the .vs directory) and that your assets are of
reasonable size in order to submit the file. Your project must contain all files necessary such that a
simple build and run will allow the code to execute. If you have used external libraries, these should be
included in the submission.
The online submissions should be uploaded to Moodle by 5pm on 14th May 2023.
The in-class demo will take place during the lecture hours (9-12am) on 11th April 2023.
The deadline is hard: no extensions. If you are ill or late, you have to formally submit extenuating
circumstances. See your student handbook for details.
Opportunities for Support and Feedback
If you wish to work on this coursework off-site, you will require a copy of Visual Studio and MonoGame
(links to this are on Moodle).
• Formative feedback is available in the laboratory sessions. Moodle discussion boards can be used
for queries between sessions.
• ‘Office hours’ are also available on a ‘drop-in’ basis if you wish to see me.
• The demonstration will offer opportunities for verbal feedback from me and your peers.
• A written marking scheme with comments for each section of the coursework (where needed) will be
returned via Moodle.
Assessment Criteria
Demonstration [9%]
• Functionality of the demonstration.
• Clear explanation of what was implemented and why.
Report [half of the 84 marks available for each of parts 1-3 (42%), 7% for part 4: totalling 49%]
• A brief ‘instruction manual’ so the marker can easily operate the functionality of the demos.
• Use a combination of formal and informal methods as needed to describe your solution to each part. Note
that each element contains a task to achieve and a games architecture principle that should be
demonstrated.
• Use of design patterns should be documented where appropriate.
• Efforts to separate game-engine and game code should be documented.
• Clear description of how the above was implemented in MonoGame (with rationale).
• Proper handling and acknowledgement of sources.
• Appropriate level of analysis and use of references where appropriate for part 4.
Code [half of the 84 marks for each of parts 1-3: totalling 42%]
• Stability of delivered demonstration (i.e. does it crash, do strange things…?).
• Functionality of delivered system.
• Evidence of good programming practice (comments, formatting, appropriate use of classes,
encapsulation etc.).
• Clarity in detailing which parts of code were your own work, and sufficient acknowledgement of
sources.