IN3026: Advanced Games Technology
BSc/MSci Computer Science with Games Technology
Coursework Project: Casual Game in C++ and OpenGL
Synopsis
The aim of this coursework is to give you the opportunity to develop your games programming
experience by using industry-proven languages and toolkits. You will be developing a single
level of a casual game in C++ using Visual Studio and the game template provided on Moodle.
The game will use OpenGL for real-time 3D graphics rendering.
This coursework is an individual work, worth 100% of the final course module mark. There is
no further exam on this module. The project is broken in two milestones, described below.
Submission Details
You must submit your project via Moodle. Submission dates are shown in the submission areas.
As with all modules, this deadline is hard, and extensions may only be requested via the
standard Extenuating Circumstances procedure. Milestone 1 will comprise 25% of the overall
marks for the module, and Milestone 2 will comprise the remaining 75%.
A 3D Computer Game with Varying-Difficulty Gameplay
Taking on the roles of designer, developer and tester, you will create a single level of a 3D
casual game. The core concept will be a game containing:
Easy and hard modes, triggered by in-game actions and consistent with the game
storyline or theme you create.
Gameplay elements (power-ups, obstacles, etc.) that give the player a challenge and
make your game interesting to play.
At least one camera technique.
The theme of this game is open to interpretation, but the game should provide different degrees
of challenge in the level. The game should be aimed at a primary market of players aged 12
and above, with non-complex controls.
Task
Your task is to create a 3D game level, which will include a camera technique, scoring system,
full heads-up display, and variable-difficulty gameplay. Some ideas consistent with the task
include:
A rail game, where the player is constrained to a specific path, or an area around a path.
Examples of this include racing games and Temple Run.
A land-based game where the player moves relative to the terrain (planar or height-
map). Examples of this include first and third person shooters, marble madness, Super
Mario 3D World.
A flight combat game (air or space), where the camera can freely roam in space.
A 3D platformer game.
The world should contain objects for the player to pick up (collision detection must be
implemented using standard techniques) as well as objects to avoid (such as enemies firing at
your location, mines/obstacles set at coordinates, etc.).
You must demonstrate:
At least one camera-technique beyond the one provided in the template code.
Rendering of enemies.
Points-based objectives to reach, acquired through an appropriate mechanism for your
game (e.g., collecting items, defeating enemies, reaching timed checkpoints).
Use of game audio, physics, and AI.
Technology
You will use C++ for the purposes of this project, as part of Visual Studio (you can obtain this
from Microsoft or use university computers with Visual Studio already installed). You are
expected to make use of external libraries as needed. Computer graphics must be implemented
in OpenGL.
You may NOT use any existing game engines or other templates other than those supplied to
you, unless agreed upon by the Module Leader with a response in writing (which you must
include in your project .zip). However, use of any additional middleware libraries and APIs
(Bullet, PhysX, Havok, ODE, OpenAL, Asset Loaders, Modlib, Freetype, Boost, etc.) are
welcome but must be noted in the submitted documentation. The additions must also be
sufficiently packaged with both the source code (such that it will compile) and the final deployed
executables (such that it will run on any lab machine).
You may wish to begin the project by producing a paper sketch identifying all the objects in the
game, including actions the objects can perform in response to game events.
Milestone 1: Interim Build (25% of Module Marks)
Game level intro screen. Optionally include a listing of keyboard/mouse controls if
known at this stage. (10%)
Inclusion of at least one primitive-based game object, built using basic OpenGL
primitives. For this task, meshes loaded into the game are not accepted. Texture-map
the shape using an appropriate texture and texture coordinates. Use valid vertex
normals to achieve correct lighting. Use appropriate rotation, translation, and scaling to
place multiple instances of this shape into the scene. (20%)
Change the skybox and terrain textures. (10%)
A camera motion technique. Examples include constraining the camera to be “on rails,”
behind the player, or rotatable around the player. Only one technique is required, but
this must involve a significant change to template code. (20%)
Inclusion of at least one mesh-based object: textured, lit, and transformed (rotated,
translated, scaled) into scene. Use appropriate rotation, translation, and scaling to place
multiple instances of this shape into the scene. (10%)
Interim build report. Include a two-page (maximum) report describing your game
concept and for each of the bullet points describing Milestone 1 above, describe what
has been implemented. Also, include a paragraph to explain what your final game will
entail, including gameplay mechanics. (20%)
Source code to be commented and follow a logical design, organisation, and coding
style (i.e., use of classes). (10%)
The total number of marks for Milestone 1 is 100%. This will be scaled by 25% to produce the
overall marks for the module.
Milestone 2: Complete Game and Report
Milestone 2 builds upon Milestone 1 and represents the complete and final game. Milestone 2
also includes a full-length report (described below).
Part 1: Basic Game Modelling (25%)
Final game level intro-screen with a listing of keyboard/mouse controls. (3%)
Inclusion of at least one primitive-based game object, built using basic OpenGL
primitives. The shape from Milestone 1 counts for this task, but at least two more are
required. As before, meshes loaded into the game are not accepted. Repeating the
same shape three times does not count. The shapes must be different, but you are
welcome to repeat them as often as you like. Texture-map each shape using an
appropriate texture and texture coordinates. Use valid vertex normals to achieve correct
lighting. Use appropriate rotation, translation, and scaling to place the objects in the
scene. Additionally, if you did not change the skybox and terrain textures in Milestone 1
make sure they are changed now. (10%)
Audio. At least three different sounds synchronised to game events, and a change of the
background music/audio. (6%)
Heads up display (HUD) while playing. As a minimum, this should provide a score, but
may also include other gameplay elements including health, lives, time remaining, etc.
depending on the nature of your game. The HUD can be rendered as text or text
combined with graphics. (6%)
Part 2: Camera, Meshes, Lighting, and FX (25%)
Final camera motion technique. Examples include constraining the camera to be “on
rails,” behind the player, or rotatable around the player. Only one technique is required,
but this must involve a significant change to template code. (6%)
Mesh-based objects: textured, lit, and transformed (rotated, translated, scaled) into the
scene. Three different meshes required. Repeating the same mesh four times does not
count. The meshes must be different but you are welcome to repeat them as often as
you like. Meshes used in Milestone 1 count towards this requirement. (7%)
Lighting. At least two lights are required in the scene. You may want to program
different light types (point light, spotlight, and directional) and have one of them moving
in your scene. (6%)
Special effects that demonstrate creative uses or techniques appropriate for gameplay,
such as: camera jitter; crossfading; blending; fog, transparency (alpha); explosions; and
particle effects (two techniques required). (6%)
Part 3: Physics, AI, and Gameplay (25%)
Use of game physics, such as gravity, velocity, momentum, resistance, acceleration,
drag, friction and bounce that lead to a creative look and feel for the level (three
techniques required). (7%)
Non-player characters (NPCs) and artificial intelligence (AI). Include at least four NPCs
in the game. Program them so that they have some intelligence, based on at least one
of the following techniques: finite state machines (at least four states), steering
behaviours, pathfinding, decision trees (at least two levels deep), flocking. NPCs should
influence the gameplay (enemies causing obstruction/damage, or agents helping the
player achieve objectives). (8%)
Gameplay elements in line with the game theme. Implement at least two of the
following: (10%)
1. Power-ups. Power-ups must give some advantage to the player that affects
gameplay (examples: special powers, increased health, ammo, additional time,
less damage when hit, inability to get hurt, switches to activate different parts of
the level, etc.).
2. Combos. Combos must provide a way for the player to score additional points
through gameplay (examples: defeating an enemy with a special attack that
scores more points than a standard attack, defeating multiple enemies in rapid
succession to score more points than defeating each more slowly, etc.)
3. Timers. A timer might count down the remaining time left in the game, or count
how long the player has survived, etc.
o You are welcome to implement any three of the above, including two of the same
type (e.g., two power-ups and no combos or timers for example) depending on
the style and genre of your game.
Part 4: Project Report and Source Code (25%)
You are to provide a 7-15 page report documenting your project. Do not exceed 15 pages. The
report should provide:
An overview, including asset listing and additional libraries (5%)
o An overview of the project, including the game’s title, description of the theme,
genre of game implemented, and description of basic gameplay objectives and
mechanics.
o Complete listing of all assets (meshes, images, textures, sounds, etc.) and
external libraries used to make the game, including:
If downloaded, the URL where downloaded, date of download, AND
license for use;
If produced, the software used and a short description of how the asset
was created.
o Complete listing of any additional libraries added to the project.
For each of Parts 1, 2, and 3 above: (10%)
o A description of features implemented to satisfy requirements. If you chose to
skip implementation or partially implement a requirement, state this.
o For implemented features: design, implementation, and results.
Use of UML (or alternative) diagrams where appropriate (e.g. use cases,
class diagrams, state machine diagrams).
Pseudo-code or small sections of source code (code snippets) with
commentary describing important algorithms developed.
Research conducted to implement your game.
Screenshots showing the game and game elements (no more than two
pages of screenshots).
Discussion section reflecting on the project. Consider the strengths and weaknesses of
the game level implemented and what you have accomplished in the time provided.
Also, discuss what would be required to expand the project into a complete game. (5%)
Source code to be commented and follow a logical design, organisation, and coding
style (i.e., use of classes). (5%)
The total number of marks for Milestone 2 is 100%. This will be scaled by 75% to produce the
overall marks for the module.
Deliverables
Each milestone is to be submitted via Moodle as a .zip file. This file should contain two folders:
1. Documentation folder including report in Word or PDF format.
2. Folder of archived source code. This must be at a stage where a simple ‘compile and
run' (F5) will start your application. Failure to have a compile and run working project
will result in a FAIL.
Your source code and solution files must be submitted in a form such that a simple “build
and execute” will build without errors on the university machines. Before submission you
should:
o Perform a clean in both Debug and Release modes.
o Delete the contents of .vs\engine\v16 directory, apart from the .sou file (required
to tell VS to keep the additional projects unloaded).
WARNING: Failure to clean your project in this way may result in it being too large to
submit via Moodle.
You may need to enable hidden items under the view menu in explorer to see the .vs
directory:
Any additional libraries used, must have their license open for educational usage, and
deployed with the working system without re-configuration.
You will submit this documentation electronically as a Word or PDF document in the zip
file (in a folder named documentation).
Important note: only assets (images, meshes and audio) that are free for
individual/educational use may be used in your game (this includes freeware, open-
source, GNU, GPL, BSD license).
Final Game Presentation in Class (5 minutes)
You are to present your final game in class on the last lecture/lab session of term.
Clear explanations of your implementation will be expected. This is your opportunity to
show everyone what you have accomplished and should be a fun experience for all.
o Presentation should be a live demo in class.
Failure to present in class will result in a 10% reduction in the total mark (for example, a
project that would score a mark of 60% would be automatically reduced by 6% to receive
a score of 54%).
Support and tips
Attend all lab sessions and complete all the lab tasks. The labs are designed to help you
develop skills and practice techniques needed for developing your game.
Students who do well on this task are invariably those that have good time management.
Dedicate sufficient time to this module each week so that you make steady progress. By
Reading Week, you should have several of the basic elements of your game coming together as
an early-stage prototype, delivered in Milestone 1.
There are a large number of demos and materials available on Moodle to get you started. You
are welcome to use the existing template provided or build your own as long as the rendering
uses OpenGL.
Remember, this is an individual project. You are encouraged to help each other research
techniques. Your final submission must be entirely your own work.
Do not spend a long time on the creative aspect of the project. This is a programming module,
and you are not being marked on game design or artistic merit.
This coursework should be used as a syllabus guide of things that you need to cover as a game
developer. You should be continuously reading up on related topics throughout the term.
Google any term you are unfamiliar with (e.g. including the keywords “OpenGL tutorial”). Put
aside time each week to cover material and please practice coding frequently. Be sure to
complete each lab, as the labs have been designed to reinforce concepts in class and help you
with the coursework. As a class, you are a games development studio for the duration of this
module.