PA199 – Advanced Game Development
Project Assignment
Semester: Autumn 2022
document revision: 1.1 (15th
September 2022)
The aim of the assignment is twofold:
● develop a core of a game engine in C++ including basic graphics and physics
components, and
● develop a simple game using your own engine.
The engine should cover the general motion of rigid bodies in three-dimensional space,
including the collision of objects and their subsequent movement.
1. Game Engine
You should implement a small game engine from scratch (based on our framework ;) that
should provide the following features to the developers:
● Creating geometry and rendering the 3D scene of the game.
● Providing necessary physics simulations usable in various computer games.
To achieve the goals here is the specification of the minimal functionality of the engine:
● 4D vector class (optional: vectors of other dimensions)
o Unit vector
o Magnitude of a vector
o Opposite vector
o Add, subtract two vectors
o Dot product
o Cross product
o Create at least one unit test for each operation.
● 4x4 matrix class (optional: matrices of other ranks)
o Multiplication
o Transpose
o Multiplication by a vector.
o Conversion of a rotation matrix to an orthonormal basis.
o Conversion of an orthonormal basis to a rotation matrix.
o (optional) Inverse
o Create at least one unit test for each operation.
● AxisAngle class - represents a rotation about a given unit axis by a given angle
o Conversion to a quaternion.
o Create at least one unit test for each operation.
● Quaternion class
o conjugation
o length
o inverse
o dot product
o normalise (to unit length)
o slerp
o Conversion to AxisAngle.
o Conversion to rotation matrix.
o Create at least one unit test for each operation.
● Polar coordinates (r,a), where “r” is a radius and “a” is an angle:
o Normalisation, i.e., the clipping of the “angle” coordinate to the range [0,2𝛑).
o Conversion to and from 2D Cartesian coordinate system (obtained from 3D
coordinate system where the “up” axis coordinate is ignored).
o Create at least one unit test for each operation.
● Collision system:
o In 3D/4D Cartesian system:
▪ Create an algorithm computing a closest point X on a given line AB to
a given point P.
o In polar coordinates:
▪ Create an algorithm deciding whether a point (r’,a’) is “on the left” (in
the grey area) or “on the right”(in the white area) of the point (r,a). [In
the figure, the point is “on the left”].
▪ Create an algorithm computing a minimal distance (difference)
between two angles in the range [0,2𝛑). For example, the result for
angles 𝛑/4 and 7𝛑/4 is 𝛑/2.
o Create at least one unit test for each algorithm.
● Physics:
o Recovery from collision - a simple bounce of a sphere from a static
(kinematic) object, as shown in the slides “PA199 Collision detection in the
assignment.pdf”.
o An ODE solver (see lectures); implement at least two methods (e.g. Euler and
Midpoint).
Usage of 3rd party libraries: You are only allowed to use 3rd party libraries automatically
installed when building the project template (available as a ZIP file in the study materials of
the course). Usage of any advanced libraries such as Ogre, Havok or OptiX is not allowed.
The purpose of the assignment is to learn how to write maths, physics and rendering on
your own.
2. The Game
2.1. Motivation – Breakout game
Your goal will be to implement a “circular” variant of a classic breakout game – the goal of
the game is to break all bricks in the level using a ball(s), influenced by in-game physics and
paddle(s). The movement of paddle(s) is controlled by the player.
Basic rules:
● The ball starts near the paddle, after launch, the ball moves at a constant speed.
● When the ball collides with a brick, the ball bounces and the brick is damaged or
destroyed.
● If the ball leaves the game area, the player loses one life. If any lives are left, the ball
is respawned near the paddle, otherwise, the game ends.
Typical extensions in real games:
● There can be multiple balls in the game at the same time. The player stays alive as
long as at least one ball is inside the area.
● The paddle can change its size.
● The speed of the ball(s) is increasing over time.
● Various types of bricks exist, with various properties (durability, power-up drops,
etc.)
2.2. Game specification
You should develop a “circular” breakout 3D game.
● The bricks will be arranged in a cylindrical wall in the centre of the circular play area.
Wall will have several rows, and each row will contain at least 12 bricks. When a
brick in the bottom row is destroyed, bricks above it will fall down.
● The player will be controlling three curved paddles positioned near the outer edge of
the play area.
● All paddles move simultaneously – the player can rotate them in CW and CCW
directions.
2.3. Minimum functionality
All of the following have to be fulfilled to receive at least an E grade.
● Game mechanics
o The player can control the paddles using ”Left” and “Right” arrow keys and
launching the ball by the spacebar.
▪ Make sure the motion of paddles is smooth, i.e., they will move with a
constant angular velocity which must be independent of the frame
rate and key repeating.
HINT: Use the events from the keyboard (key press/repeat) to track
the “pressed state” of an arrow key in a boolean variable. Move the
paddles in each game round (frame), when the variable is true.
o “Game over”, “You win” and “Pause” messages will be shown at appropriate
times:
▪ When the ball leaves the play area, the “Game over” message is
shown and the game waits for the player’s input.
▪ When all bricks of the wall are destroyed, the “You win” message is
shown and the game waits for the player's input.
▪ During the “playtime” (ball is moving), the player can pause the game
using the “P” key. When paused, the movement of the ball and the
paddles are stopped and the “Pause” message is shown. The game can
be resumed by pressing the same key again.
o Camera switching between "perspective" and "top" views via “1” and “2”
keys, respectively. The default (initial) is the "perspective" view.
● Graphics
o Construct the geometry of level from scratch, including:
▪ ball,
▪ paddles,
▪ wall made of individual bricks, (brick and paddle could have the same
shape, just different sizes).
▪ play area ground.
All geometries must be constructed procedurally:
▪ The ball and the ground must be parameterized by the radius.
▪ A brick and a paddle will be parametrized by width, height, and the
angle representing the length.
▪ Each geometry should further be parametrized by a “level of details”.
E.g., the ball could be parametrized by angle between two vertices in
horizontal and vertical direction.
o Add colours to the ball, paddles, bricks; (optionally, use textures)
▪ Choose a fixed ambient colour and fixed diffuse and specular
coefficients and the specular exponent.
o Add texture to the ground
o Camera in “perspective” and “top” views:
▪ “Perspective”: The perspective projection must be used. Choose an
appropriate angle between the up-direction of the camera and the
normal of the play area - aka “pitch” rotation (hint: 45 degrees works
well). The camera should not be “rolled” - i. e. the right-direction of
the camera must be parallel with the play area.
▪ “Top”: The orthographic projection must be used and the camera
must look at the play area from the top. The projection plane must be
parallel with the play area.
▪ Both views: The camera always looks at the centre of the circular play
area. The distance between the centre of the camera and the centre of
the play area must be adjusted so that the rendered scene fits the
window. After resizing the window, the camera should be adjusted so
the whole play area still fits the window and the scene is not stretched,
i.e. a sphere won't be deformed to an ellipsoid.
o Lighting:
▪ ambient, diffuse and specular light based on the Gouraud model
o Rendering the “Game over”, “You win”, and “Paused” messages: Prepare
textures with the messages and render them using a quad (or a pair of
triangles). Using a font-based approach is basically a no-go, as there is no
library to work with fonts in the framework.
● Physics – real-time simulation of the ball movement, based on collision detection and
reaction:
o Ball – paddle (the curved shape of the paddle matters)
o Ball – brick (the curved shape of the brick matters)
o Ball – invisible outer edge of the play area. If the ball hits this, the “Game
over” message is shown.
2.4. Above minimum functionality
Implementation of each of the below defined “extensions” will increase grade by one level.
Therefore, for an A grade, you need to implement four of the following extensions:
● Extension 1: life counting and scoring system:
○ gameplay-wise:
■ Counting the players’ lives. The player will start with three lives. Each
time the ball hits the outer edge of the play area, the player will lose
one life, and the ball will be respawned to an initial position.
■ Counting score - e.g. +1 point per brick hit.
■ If the player manages to clear the whole level, the wall of bricks will
be restarted; the number of remaining lives and the score will not be
restarted.
○ graphics-wise:
■ Render lives at one corner of the window in the form of images (e.g.
heart), for each live one image is shown.
■ Render score in another corner of the window. Prepare 10 textures,
one for each digit 0, 1, 2, ..., 9 and render the score number as the
corresponding sequence of the images. Hint: you should write a
function converting an integer number (score) to individual digits.
● Extension 2: the durability of bricks:
○ gameplay-wise:
■ some bricks will be more durable. The ball must hit them more than
once before they break up.
■ optional - the more durable brick, the more score will the player
receive
○ graphics-wise:
■ a durable brick will change colour (or texture) each time it is hit
● Extension 3: “power-ups” mechanics
○ gameplay-wise:
■ after breaking some bricks (could be predefined bricks or simply, e.g.
each fifth brick), a power-up will appear at the position of the
destroyed brick and will start moving toward the outer edge of the
play-area.
■ If the player is able to “catch” the power-up by any paddle, it will be
applied. Otherwise, the power-up will just vanish.
■ Possible power-ups (implement at least two types):
- Extra life (this power-up should appear only rarely). This is
dependent on “extension 1”.
- Extra score. This is also dependent on “extension 1”.
- Increase or decrease the speed of the ball.
- Increase and decrease the size of paddles.
○ graphics-wise:
■ rendering power-ups as simple coloured spheres is acceptable.
Different power-ups must have different colours ;)
■ optional - use textures
■ optional - use more complicated geometry (with sphere “collider”)
● Extension 4: “advanced” graphics (all of the following have to be implemented):
○ Rendering of bricks - when the ball is “behind” the wall, occluding bricks will
be rendered as a wireframe (optional - use semi-transparency instead of
wireframe) - so the ball is always visible.
○ Lighting - use the Phong model instead of Gouraud.
○ Simple casted shadow of the ball on the ground - blob shadow or other “fake”
technique is also acceptable.
● Extension 5: “advanced” physics (all of the following have to be implemented):
○ Constantly increasing the ball’s speed (e.g. speed will increase by 25% each
minute).
○ Include the speed of the paddle into calculations of collisions with the ball.
I.e. if the paddle is moving at the time of the collision, the ball will bounce in
a different direction than in the case of the static paddle. The speed of the ball
will not change. This is not precise from a physics point of view, but the
gameplay is more important at this point than accuracy.
○ “speed-up” area - if the ball reaches the centre of the game field (i.e. inside the
brick wall), it will noticeably (by, e.g. 50%) increase its speed. After leaving
this area, the speed will decrease to the previous speed. The changes in speed
will not be instantaneous - the ball will be increasing/decreasing its speed
smoothly in a reasonable timeframe, e.g. one half of a second.
3. Milestone
Create a tag named “Milestone” to the commit in your repository which will be considered
as the final version for the milestone. Expected functionality:
● “Math” section
● camera class
● procedural generation of geometry
● textures, lighting
No submission or a submission serious issues or missing functionality will result in lowering
the final grade by one level.
4. Final Game
Executable version of game must fulfil these conditions:
● Be runnable on Windows OS.
● Have “reasonable” difficulty (not extra low nor high) - you should be able to play
your game and win the level.
● Provide “reasonably” fast rendering. When run on “decent” HW (e.g. NVIDIA GTX
1070 or newer), the game should be rendered at least 30 FPS at FullHD resolution.
● FPS independent rendering - the speed of gameplay (speed of movement of the ball
and paddles) should be independent to FPS of rendering.
5. Repository, Devlog
Similar to other GameDev courses, a mandatory parts of the project are:
● Use GIT repository we created for you at
https://gitlab.fi.muni.cz/gamedev/2022/pa199
● weekly updated devlog.md text file:
o short summary of work done during the week
o (optional) time spent on the project per week
6. Deadlines
● Milestone: 3rd
November 2022 (week 8).
● regular term (“řádný termín” in Czech): 12th
January 2023
● “resit” term (“opravný termín” in Czech): 5th
February 2023
If you are graded F at the regular term, you can use the resit term to submit an
improved version of the project. In this case, we will check and grade this second
version, and you will receive the second grade in IS. So the grading could be, for
example: F, A. There is no possibility to simply “repleace” F grade.
There is also a (somewhat new) option in IS to “improve” existing non-F grades. See
“Studijní řád” for details (English version, Czech version). If you will be considering
this option, please consult with teachers in advance to avoid possible confusion or
delay in grading.
7. Submission
Create a folder: “PA199 Project - [your-surname-name your-first-name]” and put the
following into this folder:
● Folder “dist”, containing the runnable version of the project.
o Make sure that both executables (the game and the tests) are present in the
“dist” directory.
● Folder “src”, containing all source codes, project file, etc. I.e., the content of the folder
"./courses/PA199/project".
● File “readme.txt” containing a short description of the extensions you have
implemented.
Pack the folder into a .zip archive and upload this archive into the homework vault in IS.