Final Report - Hong Kong University of Science and Technology

Transcription

FYP Final Report
Prestissimo
A Multiplayer, Network-based, 3D Game
by
Fong Heung Wah
Lai Man Ting
Lau Pui Yu
Lui Chung Man, Clement
Advised by
Prof. Frederick H. Lochovsky
Submitted in partial fulfillment
of the requirements for COMP 394
in the
Department of Computer Science
Hong Kong University of Science and Technology
Name of Student: Fong Heung Wah
Name of Student: Lai Man Ting
Name of Student: Lau Pui Yu
Name of Student: Lui Chung Man, Clement
Signature:
Signature:
Signature:
Signature:
Date:
Date:
Date:
Date:
Abstract
The goal of this project was to design and implement a 3D, 4-player race game. The game allows
players to race on four tracks: Land, Water, Space and Grand Prix. When the players race on one of
the tracks, they may encounter different kinds of objects. Some objects benefit the players while some
objects hinder them. In addition, players may pick up some items and then use them later to hinder
other players.
In this game, players can experience not only the correct responses to the actions by the characters
they control, such as hitting a wall and jumping, but also instantaneous response when they press the
right key on the keyboard. In other words, the system has to react correctly to players’ input with
reasonable performance.
In this project, an extendible and reusable game engine was developed featuring graphics rendering,
collision detection, physics simulation, input and timer. More specifically, an octree system was built
to facilitate fast and efficient collision detection and visibility determination, which in turn facilitates
efficient polygon rendering.
In addition, by using the game engine implemented, a simple multiplayer race game was successfully
created. The system is able to give correct responses when two entities in the virtual world collide
with each other. Players can also experience realistic responses when the controlled character hits a
wall or jumps. The performance of the game was also kept at an acceptable level.
Multi-player Network-based 3D Game
Table of Contents
1.
Introduction .............................................................................................................. 1
1.1
1.2
1.3
2.
Results ....................................................................................................................... 3
2.1
2.2
2.3
2.4
3.
Summary ...............................................................................................................................
Possible Future Extensions ..................................................................................................
3.2.1 Game Engine ..............................................................................................................
3.2.2 Game Play ..................................................................................................................
23
23
23
23
References ............................................................................................................... 24
4.1
4.2
4.3
5.
Design Phase .......................................................................................................................... 3
2.1.1 System Architecture ..................................................................................................... 3
2.1.2 Game Engine ............................................................................................................... 4
2.1.3 Game Code ................................................................................................................... 9
Implementation Phase .......................................................................................................... 17
2.2.1 Tools Used .................................................................................................................. 17
2.2.2 Octree Rendering ....................................................................................................... 17
2.2.3 Collision Detection between Track and Dynamic Objects ....................................... 18
2.2.4 Visibility Determination ............................................................................................. 18
Testing Phase ........................................................................................................................ 18
2.3.1 Testing Platform ......................................................................................................... 18
2.3.2 Octree Construction ................................................................................................... 19
2.3.3 Collision Detection - Accuracy for Different Depths of Octree Traversal ............... 19
2.3.4 Collision Responses - Changing Angular Velocity in a Collision ............................ 21
2.3.5 Visibility Determination ............................................................................................. 22
Evaluation Phase .................................................................................................................. 22
Conclusions ............................................................................................................. 23
3.1
3.2
4.
Motivation .............................................................................................................................. 1
Project Description ................................................................................................................. 1
Problems ................................................................................................................................. 1
Books .................................................................................................................................... 24
Internet Links ........................................................................................................................ 24
Documentation ..................................................................................................................... 24
Appendices ................................................................................................................. i
Appendix A – Key Contributions ...................................................................................................... i
Appendix B – Player Guide ............................................................................................................ iii
Appendix C - Domain and Use Case Models .................................................................................. v
Appendix D – Analysis Model .................................................................................................... xviii
Appendix E – 3D Models .......................................................................................................... xxviii
Appendix F – Gantt Chart ........................................................................................................... xxxi
Appendix G – Division of Labour ............................................................................................. xxxii
Appendix H – Meeting Minutes ................................................................................................ xxxiii
Multi-player Network-based 3D Game
FYP Final Report
1
1. Introduction
1.1
Motivation
The publication of game titles such as Ultima Online by Origin Systems, Lineage by NCsoft Corp. and
Gulong Online by Gameone System Ltd. shows that multiplayer, online entertainment is gaining
popularity nowadays. In these games, players can manipulate many things: weapons, magic, items,
characters’ characteristics and characters’ actions. In addition, they can either cooperate or fight with
each other in the game to get benefits like money or experience.
While such games are interesting to some players, they are too complex for other players who want to
have fun but do not want to manipulate so many things. These players want to start playing the game
as soon as possible without having to tune the characteristics of the characters. They also do not want
to either maintain or enhance their status through many actions when playing the game. It is the
responsibility of game developers to create games that satisfy the need of these players; that is what
this project was intended to do.
1.2
Project Description
This goal of this project was to design and implement a 3D, 4-player race game. The game allows
players to race on four tracks: Land, Water, Space and Grand Prix. When the players race on one of
the tracks, they may encounter different kinds of objects. Some objects benefit the players while some
objects hinder them. In addition, players may pick up some items and then use them later to hinder
other players.
In this game, players can experience not only the correct responses to the actions by the characters
they control, such as hitting a wall and jumping, but also instantaneous response when they press the
right key on the keyboard. In other words, the system has to react correctly to players’ input with
reasonable performance.
1.3
Problems
In order to achieve the response correctness mentioned every entity in the virtual world of the game
has to behave reasonably correctly when they are hit by something or they hit something. For
example, when a character is hit by a bomb, it is expected that the bomb explodes and the character is
thrown away in one direction. This is where game logic comes into play to handle the interaction
among the entities in the virtual world.
No matter how accurate the behavior of the entities in the virtual world, it is useless if the entities
cannot be displayed on the screen. 3D models of the entities therefore have to be designed. Although
technologies such as 3D modeling software packages and 2D image editors allow easy construction of
3D models, loading them into the system so that they can be displayed when necessary requires some
work.
Since this is a multiplayer game, network communication is essential to allow players to play
together. In addition, synchronization is important in keeping the consistency of the virtual world in
different machines.
Even if all of the above are achieved, it is meaningless if the system does not interact with players.
The system should therefore be capable of capturing players’ input and updating the state of the
virtual world accordingly. In addition, it has to distinguish the validity of players’ input so that no
work is done when a player presses a wrong key.
Given the functional requirements stated above, the system has to achieve them with reasonable
performance. Each of the first three tasks mentioned has its own latency, which is significant in
affecting the overall performance of the whole system.
The latency of the game logic mainly comes from collision detection. Collision detection involves
determining which pairs of objects collide with each other; this, in turn, involves checking whether a
Multi-player, Network-based, 3D Game
FYP Final Report
2
pair of polygons intersects with each other. If the brute-force approach is used, i.e., comparing the
polygons one by one, the running time complexity is O(n2). A typical scene consists of thousands of
polygons. Obviously, today’s hardware is not capable of performing collision detection on such a
scene using the brute-force approach and giving real-time results.
The latency of displaying 3D models mainly comes from the great number of polygons entering the
graphics pipeline that are not included in the final image. Such polygons are transformed and lit at the
early stages in the graphics pipeline. However, they are rejected at later stages before rasterization so
that they are not drawn on the screen. The unnecessary work done at the early stages wastes
processing time and thus performance is affected.
The latency of network communication depends on the size of a packet and the network bandwidth
available. The greater the size of a packet or the narrower the network bandwidth, the longer it takes
to send or receive a packet. Therefore, the amount of information in a packet and the frequency of
packet transmission has to be just enough for synchronization.
FYP Final Report
2.
Results
2.1
Design Phase
3
2.1.1 System Architecture
Since a game is a real-time system, it has to check what the player inputs and update the screen
immediately. To achieve this, the easiest way is to organize all the work in a loop in which an iteration
prepares a frame to be drawn on the screen. The following table shows how the work is organized
inside the loop:
Sequence
1
2
3
4
5
6
7
8
9
10
11
12
13
Tasks
Clear Drawing Buffer
Check Input
Input Responses
Gravity Responses
Collision Detection
Collision Responses
Animate Objects
Receive and Process Network Packets
Send Current State and Events of Last Frame
Visibility Determination
Render 3D Models
Draw 2D
Present Drawing Buffer to Screen
Table 1: Game Loop
From the Game Loop above, the system architecture shown in Figure 1 was derived.
Figure 1: System Architecture
FYP Final Report
4
The system can be divided into two main parts: game engine and game code. An engine is a piece of
software that takes in data and responds with respect to the given data. A game engine is an engine
that is used to assist game development. In this project, the game engine provides services of
rendering graphics, performing collision detection, receiving input from players, performing physics
calculation, handling networking and measuring performance. The game code uses the services
provided by the game engine to perform the game logic, which includes collision responses, input
responses, network message handling and other operations of characters and items.
2.1.2 Game Engine
2.1.2.1 Graphics
This component contains rendering related functionalities for all graphics. It is divided into
Renderable Objects and Non-Renderable Objects.
2.1.2.1.1 Renderable Objects
This is a set of classes to be rendered on the screen. The class diagram of this component and
descriptions of its major classes are shown below:
Figure 2: Class diagram of Renderable Objects
2.1.2.1.1.1
CPRESBITMAP
This class loads a bitmap image from a bitmap file and draws the image on the screen. It also supports
color-keying, which is useful for removing the background color of an image. It is useful for UI
design.
2.1.2.1.1.2
CPRESXMODEL
This class loads an external 3D model, which is encoded in Microsoft DirectX File Format, and
renders the model on the screen.
CPRESOCTREE
2.1.2.1.1.3
This class implements the octree data structure, which speeds up collision detection and view frustum
culling. It loads pre-compiled octree data stored in a file and renders its polygons on the screen. An
octree is simply a tree with a maximum of eight children at every node. This is an ideal data structure
for representing a 3D model enclosed by bounding cubes. The root of an octree contains a bounding
cube that encloses all the geometry of the model. The children at each node are the eight bounding
cubes of equal size that subdivide the parent into octants. Subdivision stops when either the depth of
the octree or the number of polygons reaches a threshold. The octree construction, rendering and
algorithms for collision detection and view frustum culling will be discussed in later sections.
FYP Final Report
5
2.1.2.1.2 Non-Renderable Objects
This is a set of classes that are not able to be rendered on the screen but are essential in rendering
Renderable Objects correctly. The class diagram of this component and descriptions of its major
classes are shown below:
Figure 3: Class diagram of Non-Renderable Objects
2.1.2.1.2.1
CPRESCOORDFRAME
This class manages coordinate frame information such as position, orientation and transformation of
an object in the scene. Every renderable object has to be contained by an instance of this class in order
to be rendered correctly. In addition, it is able to build a tree of coordinate frames in order to achieve
complex transformations. This has the effect that when the root coordinate frame of the tree is
translated or rotated, all its children will be translated or rotated in the same manner as is their parent.
This class specializes into CPRESLIGHTFRAME, CPRESCAMERAFRAME and CPRESPRIMITIVEFRAME, which
are designated to contain a light source, a camera and a 3D drawing primitive, respectively.
CPRESFONTENGINE
2.1.2.1.2.2
This class uses the functionalities provided by CPRESBITMAP to render 2D bitmap fonts. It is essential
in UI design.
CPRESRENDERDEVICEMGR
2.1.2.1.2.3
This class encapsulates functionalities of initialization of and releasing resources acquired by
Direct3D.
CPRESOCTREECOMPILER
2.1.2.1.2.4
This class takes in a 3D model stored in CPRESXMODEL and compiles the geometry of the model into
an octree. The construction of an octree and the uses of an octree are discussed below.
OCTREE CONSTRUCTION
Firstly, the bounding cube containing all the polygons of the 3D model is determined. This is the root
of the octree that contains the references of all polygons of the model. If the number of polygons in
this node is greater than a threshold, it is subdivided into eight children nodes. The bounding cube of
each child node has a dimension that is half of that of the bounding cube of its parent node. For each
child node, if its bounding cube overlaps with a polygon, then the polygon will be stored in the node.
FYP Final Report
6
There are two issues of storing polygons in a node. One is how to store a polygon. Obviously, it will
be very memory inefficient to store copies of the polygon at every node in the tree. A reference to the
polygon is therefore stored instead of duplicating the polygon. The other issue is what to do when a
polygon spans across node boundaries. One solution is to split the polygon along the boundaries. This
gives a very accurate partition but generates additional polygons. The run-time performance is thus
adversely affected. It was determined that the nodes overlapping with the polygon will store a
reference to the whole polygon. This introduces another problem: when rendering a polygon spanning
across node boundaries, the polygon will be drawn more than once. In order to prevent duplicate
rendering of a polygon, each polygon has a flag indicating whether it is already rendered.
This process is repeated for each child node until the number of polygons in a node reaches a
threshold. In addition, a bounding sphere is added to each node that facilitates further speed-up in
collision detection.
USES OF OCTREE DATA STRUCTURE
An octree is a simple spatial partitioning scheme that provides easy access to a subset of polygons
clustering around a spatial location within the 3D model. Thus it is easy to reject a large amount of
polygons that are unimportant when performing visibility determination and collision detection.
Hence, it speeds up performance significantly.
CPRESVISIBILITYMGR
2.1.2.1.2.5
This class makes use of the octree data structure to determine which polygons of a 3D object are
visible and should be passed into the graphics pipeline for processing. The details of visibility
determination and rendering an octree are discussed below.
VISIBILITY DETERMINATION AND OCTREE RENDERING
Firstly, the view frustum is transformed into the local space of the octree being processed. Then, if the
root node is outside/inside the view frustum, the node is marked as OUTSIDE/INSIDE and the
routine ends. If the node intersects with the view frustum, the node is marked as INTERSECT and the
routine ends if this node is a leaf; otherwise, we proceed to its child nodes and repeat the above
process.
After processing the octree, it is ready to be rendered. Firstly, the traversal starts from the root node. If
it is found that this node is outside the view frustum, then this implies that all the polygons inside it
are outside the view frustum and there is no need to pass them to the graphics pipeline. If the node is
found to be inside the view frustum, then this implies that all the polygons inside it are inside the view
frustum and thus are passed to the graphics pipeline. If the node intersects the view frustum, then the
octree will be traversed down and the above process is repeated. If a leaf is found to intersect the view
frustum, then this leaf will be treated the same as that inside the view frustum.
Before passing a polygon into the graphics pipeline, the system checks the polygon’s flag to see
whether it was already rendered. No polygon will be passed to the graphics pipeline more than once
within an iteration of the game loop.
By using this scheme, most polygons that are not included in the final image will be rejected from
entering the graphics pipeline and thus the rendering performance is improved.
2.1.2.2 Collision Detection
As stated in the “Introduction” under “Problems”, every entity in the virtual world of the game has to
behave reasonably correctly when they are hit or they hit something. This subsystem is therefore used
to detect collisions between any two objects in the virtual world.
2.1.2.2.1 Collision Groups
If two objects never collide with each other, there is no need to detect any collision between them. In
order to prevent such unnecessary object-object comparisons, which affect the performance of the
game, objects in the virtual world are organized into groups, as shown in the following table:
FYP Final Report
7
Group Name
Objects Included
Track
All track objects except the floor
Character
All characters
Dynamic
All characters and dynamic items
Static
All static items
Checkpoint
All check points along the track
Table 2: Collision Groups
After putting the objects into groups, collision detection is performed between an object from one
group and an object from another group. The interactions of collision groups are shown below:
Group – Group Collisions
Track vs. Dynamic
Dynamic vs. Dynamic
Character vs. Static
Character vs. Checkpoint
Table 3: Collision Groups Interactions
2.1.2.2.2 Basic Collision Detection Routine
Since, to give real-time performance, it is impossible to check for the intersection of every pair of
polygons from two objects, the octree data structure is used to speed up collision detection.
Performance is improved by performing a box-box intersection test, to eliminate a large portion of the
polygons from consideration, before performing a polygon-polygon intersection test, which is more
expensive. The 2D version of the basic routine of detecting a collision between a pair of objects after
they are transformed to the same coordinate space is shown below:
Object conditions
1
2
3
4
Explanations
The octree of an object is represented as follows:
Polygons: 1,2,3,4
R
Polygons: 1
Polygons: 2
Polygons: 3
t
Polygons: 4
Level 1
When another object approaches, the octree of both objects are traversed.
As the bounding boxes of both roots intersect, octree 1 is traversed down a
level while octree 2 stays on root level.
Check for intersections between each bounding box of level 1 nodes and
the bounding box of the root of octree 2. In this case, polygons from three
children in level 1 of octree 1 are ignored as their bounding boxes do not
intersect with the bounding box of the root of octree 2. Continue traversing
downwards in octree 1 and repeat the above process until leaf level is
reached or the bounding boxes of all children intersects with the bounding
box of the root in octree 2.
FYP Final Report
8
In this case, level 1 of octree 1 is ready the leaf level; therefore, downward
traversal of octree 2 starts. Polygons from three children of octree 2 are
ignored as their bounding boxes do not intersect with the bounding box of
the right-bottom leaf of octree 1. Finally, only the polygons in one leaf
from each octree are compared in order to determine whether two objects
collide.
Table 4: Collision detection routine using octree data structure
After determining which pair(s) of polygons intersects with each other, the normals of both polygons
are returned. The collision responses subsystem then uses these normals for further processing.
2.1.2.2.3 Dynamic Collision Detection Routine
The above routine is useful for collision detection between a dynamic object and a track object or a
checkpoint, but not for that between any two dynamic objects or between a dynamic object and a
static object. In this project, the size of a track object is large compared to a dynamic object. The size
of the bounding box of a leaf of the octree of a track object is thus large compared to that of a
dynamic object. Hence, no matter how fast the dynamic object is, it is still able to ignore some child
nodes of the track object. The number of polygon-polygon intersection tests can therefore be reduced
by using the basic collision detection routine. On the other hand, a checkpoint only consists of a few
polygons. The number of polygon-polygon intersection tests is still low.
However, the sizes of dynamic objects and static objects are similar. If the speed of a dynamic object
is fast enough, it may penetrate deeper into another object. This incurs a large number of expensive
polygon-polygon intersection tests, thus affecting the performance of the game. Therefore, a dynamic
collision detection routine is applied for detection of collisions between two dynamic objects and
between a dynamic object and a static object.
How the octrees are traversed is similar to the basic routine, except that this routine checks for spheresphere intersection instead of box-box intersection, the maximum depth of traversal is limited and
there is no polygon-polygon intersection test. A sphere-sphere intersection test is used because it is
even simpler and faster than box-box intersection. In addition, the corresponding collision responses
will be simpler to handle, especially when two objects bounce away from each other. A limit on the
depth of traversal is imposed because traversing an octree using a sphere-sphere intersection test is
expensive. This will be explained in “Visibility Determination” in the Evaluation Phase. How deep
the traversal should be will be discussed in “Collision Detection” in the Testing Phase. Since collision
responses using spheres yields good results, there is no need to perform a polygon-polygon
intersection test.
The dynamic collision detection routine does not simply detect whether two spheres intersect. Instead,
it takes the velocities of both objects into consideration and then determines whether a collision
occurs while they are moving. After some geometric calculations, their correct velocities in order not
to penetrate each other are determined. This is illustrated below:
Figure 4: Dynamic collision detection using spheres
2.1.2.3 Input
This subsystem is responsible for determining which key a player presses. It also involves acquiring
system resources when this subsystem is initialized and releasing them when the game shuts down.
FYP Final Report
9
2.1.2.4 Physics
This subsystem handles physics simulations other than collision responses. It provides three effects:
air resistance, walk-on-road and area restriction.
2.1.2.4.1 Air Resistance
This effect reduces the velocity of an object by multiplying it with an air resistance factor, which is
between 0 and 1.
2.1.2.4.1 Walk-on-road
This effect keeps characters walking on the floor. When a character travels up a slope, its position
should be raised as it tries to move forward. When a character travels down a slope or falls down, it
should be moved downwards until it hits the ground.
As only the height of the polygon that the character should stand on is relevant, only the octree of the
track floor needs to be processed. Firstly, the system determines which node of the octree the
character is in. Then, the system searches a polygon in the node under or above which the character is
currently standing. The system then moves the character just above the floor.
2.1.2.4.3 Area Restriction
This effect restricts characters from moving out of the virtual world. It is just for the Space track as
characters can fly anywhere and so they can get lost easily. In other tracks, players cannot fly and they
are bounded by the track objects.
2.1.2.5 Networking
This subsystem provides basic functions for network communication. It provides network services
such as initializing a socket, making or accepting connections, sending or receiving messages and
disconnecting a connection.
2.1.2.6 Timer
This subsystem is used to measure the performance of the system. It works by counting the number of
iterations of the game loop per second. The result is called the frame rate, which is measured in
frames per second (FPS), and is used in synchronization of the velocities of entities in the virtual
world.
Consider that the game is run on two different machines: one has a low frame rate and the other has a
high frame rate. When it is expected to see a character move 10 pixels per second, the character may
move just 1 pixel per second on the machine having a low frame rate while it may move 100 pixels
per second on the machine having a high frame rate. This problem even exists when considering just
one machine. The frame rate may fluctuate throughout the game as the number of polygons passing
through the graphics pipeline varies.
It is not desirable to see players using different machines experiencing different moving speeds. The
velocity of a moving entity in the virtual world is therefore multiplied with a scalar. The scalar is
determined by dividing a defined frame rate, say 60 FPS, by the current frame rate. The multiplied
velocity is then synchronized with that at the defined frame rate, e.g., 10 pixels per second at 60 FPS.
Players are thus able to experience entities moving with a steady velocity at different times in
different machines.
2.1.3 Game Code
2.1.3.1 Geometric Objects
This subsystem is responsible for managing all objects in the game world. The class diagram and
descriptions of its major classes are shown below:
FYP Final Report
10
Figure 5: Class diagram of Geometric Objects subsystem
2.1.3.1.1 CGeometricObject
This class represents an object in the game. It specializes into CTrack, CCharacter and CItem. It
stores the geometric information and parameters of an object in which other subsystems may be
interested.
2.1.3.1.2 CCharacter
This class represents a character in the game. Different from tracks, characters are dynamic objects,
which have animations when they are moving. The animation effect of a character is achieved by
changing its pose when it moves for a certain distance. The poses of a character are actually key
frames of the character’s animation and are stored as octrees.
2.1.3.1.3 CItem
Similar to characters, some items are also dynamic objects, which have animations when they are
moving. The animation effect of an item is achieved in a way similar to that of a character. There are
totally twenty items in this game, contributing eight main item types. The class diagram of items is
shown below:
Figure 6: Class diagram of items
The following table shows the details of each item.
FYP Final Report
11
Track
Item
Land
Animal Trap
Strange Flower
Seed
Cobra
Fossil Fuel
Protective Shell
Grand
Prix
Roadster
Needles
Diaper
Milk Bottle
Mother
Water
Shark
Octopus
Torpedo
Sashimi
Protective Net
Sky
Bird Feces
Tracing Bomb
Typhoon
Rocket Engine
Laser Shield
Details
This item traps the characters stepping on it and makes
them immobile for 3 seconds.
If the character hits this strange flower seed, the victim
will be hindered and blocked by a group of strange
flowers, which lasts for 1 second.
This snake will screw up the victim, stopping the
character from moving for 3 seconds.
When a character encounters this item, the character can
travel faster than other characters. The effect will last for
5 seconds.
When a character encounters this item, the character will
be immune from offensive items used by other
characters. The protection lasts for 10 seconds.
It may come from behind or in front of the characters,
bumping them and making them travel slower for 5
seconds.
This stabs characters’ feet stopping them for 1 second if
they step on it.
This will stop the victim for 3 seconds.
This item increases the character’s speed for 5 seconds.
This item prevents the character from being harmed by
offensive items used by other characters for 8 seconds.
It comes from behind or in front of characters and attacks
them, decreasing their speed for 3 seconds.
It spurts black ink onto a character so that the character
loses its direction for 5 seconds.
The victim is stopped for 3 seconds.
Characters can swim faster for 5 seconds.
Characters will not be affected by any harmful effects
including that from hindering items and offensive items
for 10 seconds.
Reduces a character’s speed by 50% for 10 seconds.
The explosion stops the attacked characters for 3
seconds.
Attacks all other characters and causes them to lose
control for 5 seconds.
Increases the character’s speed by 100% for 8 seconds.
Protects the character from all harmful effects, including
that from hindering items and offensive items for 20
seconds.
Table 5: The details of each item corresponding to each track
Every item belongs to a type. The table below shows the types of all the items. Details of each type
will be discussed in “Character-Item Collision Responses”.
FYP Final Report
12
Beneficial
Type of Item
Accelerate
Protective
Hindering
Decelerate
Offensive
Stop
Avoidable
Nonavoidable
Item
Rocket Engine
Milk Bottle
Fossil Fuel
Sashimi
Mother
Protective Net
Laser Shield
Protective Shell
Torpedo
Bird Feces
Shark
Roadster
Animal Trap
Strange Flower Seed
Needles
Octopus
Single Cobra
Diaper
Tracing Bomb
Global Typhoon
Table 6: Item Types
2.1.3.1.4 CTrack
This class represents a track in the game. A track consists of three parts: track objects, floor and
checkpoints. Track objects include walls, caves, stones and other real objects except the floor. The
floor is the place on which the characters walk. Checkpoints are used to detect whether the characters
follow the track. They are transparent planes located somewhere in a track. They are not rendered, but
are used by the collision detection manager. A track has to be separated into different parts because
different collision detection and physics simulation methods can be applied more easily in order to
achieve high performance of the game.
2.1.3.1.5 CGeometricObjectMgr
This class is responsible for loading and deleting every object in the game.
2.1.3.2 Collision Responses
This subsystem contributes to the main part of the game logic. There are five kinds of collision
responses in the game: character-character, character-track, character-item, item-track and charactercheckpoint collision responses.
2.1.3.2.1 Character-Character Collision Responses
Characters are dynamic objects. As discussed in Section 2.1.2.2, collision detection of two dynamic
objects is based on sphere intersection tests. Their collision responses thus use the results from sphere
intersection tests. The following table shows the flow of a sphere-sphere collision:
FYP Final Report
13
Stage 1
Stage 2
There is a collision detected
along the expected
movements of two balls.
The two balls are assigned
velocities so that they stop
where they collide with each
other.
Stage 3
After that, they move in new
directions.
Table 7: Character-character collision responses
2.1.3.2.2 Character-Track Collision Responses
The following table shows the ideal collision responses when a character hits a wall:
Stage 1
Stage 2
Stage 3
A track object
There is a collision detected
along the expected
movements of a character.
The character is assigned a
After that, it moves in a new
velocity so that it stops where direction.
it hits the wall.
Table 8: Ideal character-track collision responses
However, such a response is actually impractical because it requires checking each intersecting
polygon between the character and the track to find out how long the character should move before an
intersection occurs. As a result, the performance will be affected. Instead, it was decided to change the
velocity of a character to the new direction directly after a collision is detected. The new direction is
determined as follows:
Figure 7: Determining the new direction of a character on collision with a track object
2.1.3.2.3 Character-Item Collision Responses
The following table shows what each type of items will do on the character if a character-item
collision occurs:
FYP Final Report
Item type
Beneficial
Hindering
Offensive
14
Effects on the character in a character-item collision
The character’s speed will increase by a factor according to its
current speed by using the accelerate function of the character
with a positive factor.
Protective
The character will be protected from all unfavorable items
attacking it by adding a model (for example, Mother) surrounding
the character and setting the bit of checking collision with other
hindering and offensive items (thrown by other players) to be
false.
Decelerate
The character’s speed will decrease by a factor according to its
current speed by using the accelerate function of the character
with a negative factor.
Stop
The character will be forced to stop at its current position by
setting the velocity of the character to be zero.
When this kind of item collides with the character the first time, this means the
item is kept by that character and it will appear in the character’s item list. If a
second collision is detected, this means the user having this item uses it to attack
other players.
Avoidable
This kind of item is avoidable, which means that the player can
dodge and avoid being attacked by the item.
This kind of item is non-avoidable, which means that the player
Noncannot dodge and avoid being attacked by the item. Once the
avoidable
player uses this kind of item, all the other players or the specified
target will be attacked.
Single
The target for this item is one, that is, only one
character will be attacked for one use of this kind of
item. Once the user wants to use this kind of item, it is
required to specify the target.
Global The target for this item is all other players.
Accelerate
Table 9: Responses taken when different kinds of items collide with the characters
After the collision occurs, the items will not be rendered in the next frame to show that they disappear.
2.1.3.2.4 Item-Track Collision Responses
Initially, the items are placed on the floor of the track. There are no collision responses as there is no
collision between the track and items.
When a player plays the game, beneficial items and hindering items only potentially collide with
characters. Therefore, there are still no collision responses between the track and such items.
However, offensive items, such as tracing bombs, may move in any direction after they are used by
players. Collisions may occur between these items and the track. The collision responses in this case
will be rendering some animations showing explosions or just making them invisible.
2.1.3.2.5 Character-Checkpoint Collision Responses
In order to check whether a character follows a track, there is a number that shows the ID of the next
checkpoint the character has to reach. When the character collides with a correct checkpoint, the
number will be updated to the ID of a new checkpoint; otherwise, nothing happens and this implies
that the character is going the wrong way.
2.1.3.3 Input Responses
This subsystem uses the services provided by the Input subsystem in the game engine and does
appropriate processing of a player’s inputs. The following tables show different responses to different
keys pressed in different circumstances.
FYP Final Report
15
Input key from keyboard
“y” / “n”
Numbers
Enter
Escape
Response
Choose to be a server (y) or a client (n)
Number of laps chosen
Start the game
Quit the game
Table 10: Input responses before the game starts
Input key from keyboard
“a”
“z”
“s”
Number “1”
Number “2”
Number “3”
Number “4”
Number “5”
Up arrow
Down arrow
Left arrow
Right arrow
Escape
Response
Move forward or accelerate
Move backward or decelerate
Jump / Sink
Choose an item to use
Face up
Face down
Turn left
Turn right
Quit the game
Table 11: Responses to keyboard input during the game
2.1.3.4 Network Messages
This subsystem is responsible for handling the message exchange among player machines. There are
two approaches to handle the information exchange in a multiplayer, network game: the client-server
model and the peer-to-peer model. In the client-server model, there is a server to which clients are
connected. Clients communicate with each other through the server. In the peer-to-peer model, there
is no dedicated server. Instead, a connection is established between every pair of clients. The
following figures show the differences between the two models.
(a) Client-Server model
(b) Peer-to-Peer model
Figure 8: Two communication models
In the end, the client-server model was chosen in this project. A great number of connections have to
be established for all machines in the peer-to-peer model while only one connection has to be
established for all clients in the client-server model. Resources consumption in the client-server model
is thus more efficient.
There are two kinds of messages in the game: data messages and control messages. Data messages
contain information of characters such as positions and velocities while control messages contain
FYP Final Report
16
information controlling the flow of the game. For example, after a client successfully connects to the
server, it signals the server that it is ready to play the game by sending a control message. After such
control messages from all clients are received, the server broadcasts that the game starts.
This subsystem uses the networking functions provided in the game engine to achieve the sending and
receiving of messages. There are some differences between the functionalities of this subsystem in the
server and the clients. For the server, this subsystem maintains one listen socket and one to three
active sockets. The listen socket is used to accept new incoming clients while the active sockets are
used to send and receive messages from existing clients. For the clients, each of them has only one
active socket for exchanging information with the server. When the server receives a data message
from a client, it broadcasts the message to all other clients, thus keeping the game state of every client
synchronized.
2.1.3.5
Other Design Issues
2.1.3.5.1 Placing Items on Tracks
The exact locations of items must be known so that the items are placed in appropriate locations along
the track where characters are able to acquire them easily. A small system was therefore built to
collect such information. It consists of a character with a camera behind and a track, with the
character being able to move around the track. The user moves the character around to find a suitable
location on the track for an item to be placed. The user presses a particular key to inform the system
to output the information in a text file when he finds a suitable location. With the information from
the text file, items can be placed on the track appropriately.
2.1.3.5.2 Lap Counting
In order to win the game, a player has to finish the required number of laps in the shortest time. A
simple mechanism was used to count the number of laps a character already finished. It works by
placing some checkpoints throughout the tracks. A checkpoint is actually an invisible plane model
which cuts across the track. Although it is invisible, a collision response results when it is hit by a
character.
Once the player is detected to pass through a checkpoint, the character is expected to pass through the
next checkpoint on the track, as discussed in “Character-Checkpoint Collision Responses”. The
number of laps that a character has traveled can be determined by counting the number of times that
the character has passed through the last checkpoint on the track. When it is found that a character has
passed through the last checkpoint for the required number of times, the winner can be determined
and the game ends.
2.1.3.5.3 User Interface
The user interface was designed to display game information to players. Such information includes
speed, the counting of laps, timing, item list and a map showing their locations on the track.
The interface is displayed by rendering bitmap images. The interface was created as several bitmap
images and rendered using the Font Engine in the Graphics subsystem. The background color of the
images, which is magenta, is removed when rendering the images. This is achieved by copying the
images to the back-buffer pixel by pixel except the pixels of the background color, which is magenta
in this case. Magenta was chosen to be the background color because it is uncommon among the
interface bitmap images.
Figure 9 shows a screenshot of the user interface of the game.
FYP Final Report
17
Figure 9: User interface of the game
2.2
Implementation Phase
2.2.1 Tools used
In this project, C++ was chosen as the programming language as its object-oriented properties makes
it easy to maintain the code. DirectGraphics and DirectInput of DirectX 8.0a were chosen to be the
graphics and the input API’s, respectively, as DirectX 8.0a provides useful utility functions. This
saves time in implementing and debugging such functions. In addition, Winsock 2.0 was chosen to be
the network API and 3D Studio Max was used to create 3D models.
2.2.2 Octree Rendering
When rendering an octree, the number of polygons passing into the graphics pipeline is different from
frame to frame because of visibility constraints. An STL vector data structure was used to store
polygons. If a new polygon that has to be passed into the graphics pipeline is found, it is pushed onto
the end of the vector.
The performance of rendering an octree using this scheme was not satisfactory as the frame rate of
rendering all polygons in the octree root node was lower than that of rendering the corresponding 3D
model using an instance of CPRESXMODEL. It was found that it was the great amount of memory
manipulation of the vector that drained performance. When pushing polygons onto the back of the
vector, the operating system allocated memory dynamically to the vector so that the vector had
enough space to store the polygons. After rendering the octree, the vector returned all its memory to
the operating system. There was so much expensive memory manipulation within an iteration of the
game loop that performance was adversely affected.
Instead of using an STL vector to store the polygons, a large chunk of memory is statically allocated
for every octree before the game loop is entered. Every octree has enough memory to store its
polygons that have to be passed into the graphics pipeline. As there is no significant memory
FYP Final Report
18
manipulation during rendering an octree, performance is significantly improved.
2.2.3 Collision Detection between Track and Dynamic Objects
Since the leaves of a track octree are generally large, their bounding boxes can usually contain a large
portion or even the whole dynamic object. This results in low efficiency as most polygons of the
dynamic object are compared with those in the track octree leaves. The intersection test between the
polygons in the track octree leaves and the node of the dynamic object is performed before testing
polygon-polygon intersection. This approach eliminates some nodes of the dynamic object from
consideration when their bounding boxes do not intersect with the polygons in the track octree leaves.
2.2.4 Visibility Determination
Originally, the bounding spheres in the nodes of an octree were used in visibility determination, as a
sphere-frustum intersection test is far simpler and faster than a box-frustum intersection test.
However, the trade-off for such simplicity is performance. The radius of a bounding sphere was
chosen so that the sphere could contain the bounding cube of a node. A 2D version illustration is
shown below:
Figure 10: Bounding spheres containing bounding cubes
The shaded area is where bounding spheres overlap with each other. Suppose the view frustum only
contains the lower left bounding box but not the upper bounding box. In other words, only the lower
left node has to be further processed during visibility determination. If the view frustum intersects
with the shaded area within the lower left node, the upper left bounding sphere will be considered as
intersecting the view frustum; hence, the upper left node will be further processed. This wastes much
time in traversing nodes which are not necessary.
The problem was solved by using the bounding cubes of the nodes instead of the bounding spheres in
visibility determination as bounding cubes provide boundaries that are more clear-cut. Nodes that are
outside the view frustum can be determined more quickly and thus there are fewer node traversals. By
using this implementation scheme, the performance was found to improve significantly.
2.3
Testing Phase
2.3.1 Testing Platform
An assigned machine in CS FYP Lab was used for testing purposes. It consists of an Intel Pentium III
1GHz CPU, 256MB RAM, nVidia GeForce2 MX400 with 32MB video memory display card and
DirectX 8.0a runtime library.
FYP Final Report
19
2.3.2 Octree Construction
Efforts were made to output the octree data to a text file so that investigation of the partition
information is possible. However, a typical 3D model can be partitioned into hundreds to thousands of
nodes. It is tedious to investigate the correctness of every piece of information inside the text file. To
facilitate fast testing of the correctness of octree construction, the octree data has to be converted to
another human readable form, which is efficient, complete and clear. The physical meaning of an
octree serves this purpose well: it is a tree of bounding cubes containing polygons. A routine drawing
the bounding cubes of an octree was therefore implemented. Below is a screenshot of the octree of a
character model with a threshold of 30 polygons per node:
Figure 11: A screenshot of the octree of a character with a threshold of 30 polygons per node
By observation, space with more polygons resulted in more and smaller bounding cubes. This implies
that the octree was deeper. Space with no polygons did not have further partitions, which implies that
the octree reached a leaf quickly at that space. Therefore, the correctness of the octree construction
was confirmed.
It was found that loading the game was extremely slow because compilation of 3D models into
octrees takes time. The problem is worse if the 3D models are composed of many polygons. It is
annoying if players have to wait for several minutes before playing the game. In order to shorten the
game loading time, functions of outputting octree data to a file in binary format and loading binary
data from the file to an octree were implemented. The correctness of such functions was also tested by
drawing the bounding cubes on the screen for observation. The time of loading the game was found to
improve significantly.
2.3.3 Collision Detection - Accuracy for Different Depths of Octree Traversal
The following pictures show different collision events between two characters. The left one is
Magician while the right one is Monster. The first picture shows the beginning status of the characters
while the other pictures show where Magician stopped when a collision was reported, which was
visualized as Monster moving backwards. The wireframes represent the bounding boxes of the octree
leaves of the characters.
FYP Final Report
20
Figure 12: Two characters that are static at the beginning of the test
Figure 13: Maximum depth of octree traversal = 0
FYP Final Report
21
These pictures show that by increasing the maximum depth of octree traversal for collision detection,
the objects can get closer to each other before a collision is reported. The accuracy is thus improved.
The maximum depth was decided to be four octree levels.
2.3.4 Collision Responses - Changing Angular Velocity in a Collision
The purpose of this test was to test the character-track collision responses. It was found that the
system works well if the character just moves forward or backward in a tunnel. However, if a
character stands near the walls and changes its orientation, the following problem occurs:
Figure 16: Problem of character-track collision responses
It was found that the collision responses do not change the angular velocity of the character when a
collision is detected. The character is still able to rotate such that its polygons penetrate into the track
although the collision is detected. The angular velocity of the character is therefore inversed to solve
the problem, as shown in the following table:
FYP Final Report
22
Stage 1
A track object
There is a collision
detected along the
expected movements
of a character.
Stage 2
A track object
The angular velocity
is inversed.
Table 12: Corrected character-track collision responses
2.3.5 Visibility Determination
The purpose of visibility determination is to reduce the number of polygons that are not included in
the final image passing into the graphics pipeline. The performance gained in rendering polygons
should be greater than the overhead induced by visibility determination so that there is a net gain in
the overall performance. It was found that the overall performance dropped when an octree that is
small enough to be contained in the view frustum intersects with the view frustum. This is
unacceptable as fewer polygons were drawn but poorer performance resulted. This implies that the
overhead of traversing the octree outweighs the performance gained in rendering fewer polygons.
A functionality allowing programmers to indicate whether an octree is a small one or a large one was
added to the system. If an octree is a small one, then the system will only check whether the bounding
sphere of the octree root node is outside the view frustum. If it is, then no polygons will be passed into
the graphics pipeline; otherwise, all the polygons will be rendered. If an octree is a large one, then the
normal visibility determination routine will be used.
2.4
Evaluation Phase
A homepage (http://ihome.ust.hk/~eg_lpyaa/) for the game was built to get feedback and evaluation
from the public. The game demo, the game description, the game play, details of characters, details of
items, details of tracks and screenshots of the game demo were included in the homepage. A
questionnaire was also included to collect suggestions and comments. The things to be evaluated
include quality of graphics, speed of the game, gameplay, easy of control and user interface. From the
evaluation results, it was found that over 90% of the players think that the graphics are excellent.
Over 85% of the players think that the speed of the game is good. About 70% of the players admitted
that the game play is good. However, only 50% of the players think that the game is easy to control.
80% of the players thought that the game has a good user interface.
FYP Final Report
23
3. Conclusions
3.1
Summary
In this project, an extendible and reusable game engine was achieved featuring graphics rendering,
collision detection, physics simulation, input and timer. More specifically, an octree system was built
to facilitate fast and efficient collision detection and visibility determination, which in turn facilitates
efficient polygon rendering. In addition, by using the game engine implemented, a simple multiplayer
race game was successfully created. The system was able to give correct responses when two entities
in the virtual world collide with each other. Players can also experience realistic responses when the
controlled character hits a wall or jumps. The performance of the game was also kept at an acceptable
level.
3.2
Possible Future Extensions
3.2.1 Game Engine
Although the game engine is suitable for the problems in this project, it can be further improved. One
functionality that can be added to the game engine is playing sound. If the game plays relevant sound
when a character hits with another entity in the virtual world, the collision response will be more
realistic.
In this project, animation of characters was achieved by rendering key frames at different times. In
other words, different poses of a character were captured as individual 3D models. Each model was
rendered one by one to achieve the animation effect. Skeletal animation is an alternative to achieve
precise animation. It works by moving one or more parts in the model to obtain different poses that
achieve the animation effect. For example, if it is expected to see a character raising its arm, the keyframe approach is to create some models each of which shows the pose of the character at the time
between the starting and the stopping of the arm’s motion. This results in several 3D models. If the
skeletal animation approach is used, just a single model will be used and the animation effect is
achieved by just rotating the arm. Therefore, memory efficiency will be improved.
When a bomb hits a character or a track, it explodes. A particle system can be implemented to draw
the fragments of the exploded bomb. This improves the quality of the graphics and realism of the
game.
Besides the quality or realism of the game, performance can be further improved. In this project,
visibility determination of an object is only limited to the spatial relationship between the object and
the view frustum. Suppose there are two objects inside the view frustum, one is large while another
one is small. The small object is behind the large object with respect to the eye point of the view
frustum. The final image will then be just the large object. Therefore, there is no need to pass the
polygons of the small object into the graphics pipeline. This technique of culling away objects which
are blocked from the viewer by larger objects in front of them is called occlusion culling.
3.2.2 Game Play
The number of tracks can be increased so that players have more choices. This also allows more items
to be created to suit different backgrounds of the tracks. In addition, the condition for a player to win
can be modified by imposing a time limit on the race. Once a character passes through some
checkpoints along a track before the timer expires, the time limit will be expanded. When the timer
expires, the ranking for every character and thus the winner will be determined. This increases the
challenge of the game.
FYP Final Report
24
4. References
4.1
Books
1. Barron, T., Multiplayer Game Programming. Prima Tech, 2001.
2. Deloura, M., Game Programming Gems, Vol. I. Charles River Media, 2000.
3. Moller, T., and Haines, E., Real-Time Rendering. A.K. Peters Ltd., 1999.
4. Walsh, P., The Zen of Direct3D Game Programming. Prima Tech, 2001.
5. 3DS MAX R4 ____ _______
6. 3DS MAX R4 ____ _______
7. ______(________)
8. 3DS MAX R4 ___ - _____ (__________)
9. 3DS MAX R4 ___ - _____(__________)
10. __3D Studio Max R3.X
4.2
Internet Links
1. Hanjnoczi, S., WinSock 2 for games,
http://www.gamedev.net/reference/articles/article1059.asp
2. Jackson, M., Heuvel, J. v. d., Pool Hall Lessons: Fast, Accurate Collision Detection between
Circles or Spheres, http://www.gamasutra.com/features/20020118/vandenhuevel_01.htm
3. Kelleghan, M., Octree Partitioning Techniques,
http://www.gamasutra.com/features/19970801/octree.htm
4. Lander, J., Crashing into the New Year: Collision Detection,
http://www.gamasutra.com/features/20000210/lander_01.htm
5. Lander, J., When Two Hearts Collide: Axis-Aligned Bounding Boxes,
http://www.gamasutra.com/features/20000203/lander_01.htm
4.3
Documentation
1. Character Studio 3 Online Reference
2. Microsoft DirectX 8.0a SDK Documentation
Key Contributions of Lui Chung Man, Clement
i
Key Contributions of Fong Heung Wah
I designed some of the tracks, characters and items and created the 3D models in 3D Studio Max. This
part provides the appearance of each object, which is one of the basic elements for a game.
1.2.5 3D Modelling
This part stores the information and state of each object and provides operations, such as move, jump
and turn, for the objects.
1.2.4 Geometric Object – Character and Track
This part handles the network initialization and data exchanges in this 4-player network game. This
part is indispensable for a multiplayer network game. It maintains the synchronization between
several player machines.
1.2.3 Network and Network Message Handling
The physics system simulates real world physical effects such as gravitation effect and air resistance.
It improves the realism of the game.
1.2.2 Physics
Collision detection checks whether two objects collide with each other. Collision responses involve
triggering different kinds of responses when collisions occur. The collision system is the basis of real
world collision events simulation. It maintains the correct flow and improves the realism of the racing
game. This part contributes to most of the game logic.
1.2.1 Collision Detection and Collision Responses – Character-Track and Character-Character
1.2
This system provides performance measurement and synchronization on the velocities of entities in
the virtual world. It is important in the development of the game, especially where performance is
critical. In addition, it provides players with steady movement of characters.
1.1.4 Timer
The octree system helps speed up collision detection and visibility determination. It is the main source
of performance speed up in the game.
1.1.3 Octree System
This part includes implementation of objects that are both renderable and non-renderable. In addition,
visibility determination is included. This part is important for visualizing the state of the game and for
interacting with players.
1.1.2 Graphics Engine
This is important for the correctness and the performance of the game.
1.1.1 Design of System Architecture
1.1
1. Individual Key Contributions to the Project
Appendix A – Key Contributions
5. Appendices
FYP Final Report
Key Contributions of Lau Pui Yu
ii
Key Contributions of Lai Man Ting
2. Dependency Graph of Key Contributions
Collision responses for Item-Character and Item-Track are effects that act on both collided objects.
Different items invoke different responses to collisions with the characters and the track. This part
contributes to the game logic.
1.4.3 Collision Responses – Item
This part contains the functionality of all kinds of items. The Geometric Object system for Item
includes the basic settings for all the items. It helps further development according to different
features of each item.
1.4.2 Geometric Object – Item
The input system involves detection of keys pressed on the keyboard while the input responses system
handles the effects that act on the characters and items. The input system performs an important role
throughout the game as it is the main channel for the player to interact with the game.
1.4.1 Input and Input Responses
1.4
I designed some of the tracks, characters and items and created the 3D models in 3D Studio Max.
Models are the basic element for a 3D game. They help to improve the visual quality of the game
environment.
1.3.2 3D Modelling
I designed and created the user interface of the game in order to show game information for each
player. The interface displays some game information including speed, lap counting, timing, location
and items that a player has. The user interface is essential to a player to make appropriate decisions
when playing the game.
1.3.1 User Interface Design
1.3
FYP Final Report
Protects the player from all harmful effects, including that from hindering items and
offensive items. Duration: 20 seconds.
It comes from behind players and attacks them, decreasing their speed for 3
seconds.
Reduces a player’s speed by 50%. Duration: 10 seconds.
Shark
Bird Feces
The explosion stops the attacked players for 3 seconds.
Tracing Bomb
Fossil Fuel
Beneficial Items
When a player acquires this item, the player will travel faster than other players
will. The effect will last for 5 seconds.
Along each track, there are different kinds of items that interact with you. Some items benefit you
while some hinder you. In addition, you can keep some items and then use them to hinder other
players.
Encountering Items
Use the arrow keys to turn left, turn right, turn up or turn down. Besides that, there are some special
movements in each track. Press “s” to jump in the tracks on Land or to sink in the Water. Press “a” to
accelerate and “z” to decelerate.
To quit the game, choose QUIT GAME in the main menu.
Quitting the game
At the bottom of the screen, you will see a list of offensive items you have collected along the track.
Press 1, 2, …, 5 to use item 1, 2, …, 5. If the item has a target, then you have to specify a victim by
pressing 1, 2, 3 or 4.
Using Offensive Items
Attacks all other players and causes them to lose control. Duration: 5 seconds.
Torpedo
When a game session is launched, you will be directed to the first track selected. The following
explains how to play the game.
Typhoon
It spurts black ink onto a player, making him lose his direction and move
backwards for 5 seconds.
Playing the game
Move/Change Direction
Octopus
This stabs players’ feet stopping them for 1 second if they step on it.
The victim will be screwed up by this snake, stopping the player from moving for 3
seconds.
Cobra
Needles
If this item hits a victim, the victim will be hindered by a group of strange flowers.
The flowers will last for 1 second.
Strange Flower
Seed
Diaper
Choose HELP to check the default keyboard configuration of the game.
Getting Help
If you want to join a game session that is setup somewhere, then choose “Join Game Session”. You
will be prompted to enter the IP address or the host name of the game server. After entering it, the
tracks selected by the game server and the corresponding number of laps will be displayed. Press
ENTER to confirm joining the game session or press ESCAPE to quit to the main menu.
Offensive Items
It may come from behind players, bumping them and making them run slower for 5
seconds.
Roadster
Joining a game session
This obstacle traps players stepping on it and makes them immobile for 3 seconds.
Animal Trap
After entering the game, you will see the main menu. If you want to be the server of this game, then
choose “Setup Game Session”. After that, you have to choose the tracks to play on and enter the
number of laps for each track. Wait until other players join your game session. When a player joins
your game session, you can either launch the game by pressing ENTER or wait for another two players
to join. If you want to quit to the main menu, press ESCAPE.
Hindering Items
Increases the player’s speed by 100%. Duration: 8 seconds.
Setting up a game session
Playing Prestissimo
The winner is the one who wins the greatest number of races. If there is a draw, then all players will
play an additional track until a winner can be determined.
Laser Shield
Players can swim faster for 5 seconds.
Sashimi
Magician, Robot, Tarzan and Monster are competing for the honour of “The Prestissimo in the
Universe”, which means the fastest mover in the Universe. Now, they are polishing their favorite
traveling tools to get ready for the competitions on Land, in the Water and in the Sky.
Rocket Engine
This item prevents the player from being harmed by offensive items used by other
players for 8 seconds.
Mother
Players will not be affected by any harmful effects including that from hindering
items and offensive items for 10 seconds.
This item increases the player’s speed for 5 seconds.
Milk Bottle
Introduction
Protective Net
When a player acquires this item, the player will be immune from offensive items
used by other players. The protection lasts for 10 seconds.
Protective Shell
Appendix B – Player Guide
In this game, you are going to be one of the mentioned characters to race on the tracks on Land, in the
Water and in the Sky. Along each track, there are items that either benefit or hinder you. In addition,
you can keep some items and then use them to hinder other players.
iv
iii
FYP Final Report
FYP Final Report
Common Class Descriptions
1.2
Attributes
1.2.1.2
1.2.2.1
Description
This class stores information of a player.
1.2.2 CCharacter
1.2.1.2.3 Private Vector m_vtOrientation
This stores the orientation the geometric object is facing in the world.
1.2.1.2.2 Private Point m_ptLocation
This stores the current location of the geometric object in the world.
1.2.1.2.1 Private Polygon m_pPolygonList
This is the list of polygons that are to be rendered and drawn on the screen.
Description
This class is the base class of all objects that are renderable and drawable on the screen.
1.2.1.1
1.2.1 CGeometricObject
Common Class Diagram
1.1
Each track will feature the classes stated below. The class diagram shown below can be viewed as a
hierarchy tree. Each leaf will further specialize into different subclasses in each track. Detailed classes
of items, which are visible to players, will be described later.
Attributes
1.2.3.2
Description
This class of items hinders the players along the track of a race. It further specializes into
CDecelerate and CStop.
Attributes
1.2.5.2
Description
This class of items stops the player from moving.
Description
This class of items benefits the player along the track of a race. It further specializes into
CAccelerate and CProtective.
Attributes
1.2.8.2
1.2.8.2.1 Private Float m_fDifference
This determines the extent the player is accelerated.
Description
This class of items makes the player travel faster than others.
1.2.8.1
1.2.8 CAccelerate
1.2.7.1
1.2.7 CBeneficial
1.2.6.1
1.2.6 CStop
1.2.5.2.1 Private Float m_fDifference
This determines the extent the player is decelerated.
Description
This class of items makes the player travel slower than others.
1.2.5.1
1.2.5 CDecelerate
1.2.4.1
1.2.4 CHindering
1.2.3.2.1 Private Integer m_iDuration
This determines how long the item will affect the players.
Description
This is the class that stores information of an item that interacts with players. It specializes
into CHindering, CBeneficial and COffensive.
vi
1.2.3.1
1.2.3 CItem
1.2.2.2.3 Private Offensive m_pOffensiveItems
This is the list of offensive items that are used by a player to hinder other players.
1.2.2.2.2 Private Char m_cID
This identifies the player uniquely in a multiplayer environment.
1.2.2.2.1 Private Float m_fSpeed
This stores the current speed of the player.
1. Domain Model
Attributes
FYP Final Report
1.2.2.2
v
Appendix C - Domain and Use Case Models
FYP Final Report
CAvoidable
CNonAvoidable
CSingle
CAvoidable
1.3.2.3
CStop
1.3.1.2
CAvoidable
1.3.3.3
1.3.1.5
CGlobal
None
1.3.1.4.1 CCobra
seconds.
1.3.3.3.1 COctopus
The octopus spurts black ink onto a player making him lose his direction and move
backwards for 5 seconds.
CStop
None
CSingle
1.3.3.2
CDecelerate
1.3.1.4
1.3.3.1
1.3.3 Track 3 – Water
1.3.3.1.1 CShark
The shark attacks players from behind decreasing their speed for 3 seconds.
CAvoidable
CProtective
1.3.2.7.1 CMother
This item prevents the player from being harmed by offensive items used by other players
for 8 seconds.
1.3.2.7
1.3.1.3.1 CStrangeFlowerSeed
If this item hits a victim, the victim will be hindered by a group of strange flowers. The
flowers will last for 1 second.
1.3.1.3
1.3.1.2.1 CAnimalTrap
This obstacle traps players stepping on it immobilizing them for 3 seconds.
CDecelerate
None
1.3.1.1
1.3.1 Track 1 – Land
CAccelerate
CGlobal
None
1.3.2.6.1 CMilkBottle
1.3.2.6
1.3
Item Descriptions for Each Track
CSingle
1.3.2.4.1 CDiaper
1.3.2.4
1.3.2.3.1 CNeedles
This stabs players’ foot stopping them for 1 second if they step on it.
CStop
None
1.3.2.2
1.3.2.5
CGlobal
CDecelerate
1.3.2.1.1 CRoadster
The roadster may come from behind the players bumping them and making them run
slower for 5 seconds.
1.3.2.1
1.3.2 Track 2 – Grand Priz
1.2.14.1 Description
This class of items will affect all other players when used by a player.
1.2.14
This class of items requires a target victim to be selected so that the victim will experience
the effects of the items.
1.2.13
This is a class of items whose effects are not avoidable in any circumstances by a victim. It
specializes into CSingle and CGlobal.
1.2.12
This is a class of items whose effects may be avoided by a victim.
1.2.11
CProtective
1.3.1.7.1 CProtectiveShell
When a player acquires this item, the player will be immune from offensive items used by
other players. The protection lasts for 10 seconds.
1.3.1.7
COffensive
1.2.10
This is the class of items that can be kept by the player and then used to hinder a victim. It
specializes into CAvoidable and CNonAvoidable.
1.3.1.6.1 CFossilFuel
When a player acquires this item, the player will travel faster than other players will. The
effect will last for 5 seconds.
Description
This class of items protects the player from being offended by offensive items.
viii
1.2.9.1
CAccelerate
FYP Final Report
1.3.1.6
vii
1.2.9 CProtective
FYP Final Report
CSingle
CAccelerate
1.3.3.6
CProtective
ix
CDecelerate
CAvoidable
None
CSingle
1.3.4.3
1.3.4.4
CGlobal
System Use Cases
Post Conditions
The Player is directed to the main menu of the game.
2.1.1.6
Basic Path
1. The use case starts when the Server Player selects the option – Setup Game Session.
2 . The system prompts the Server Player to select the tracks among the four tracks
provided.
3. The Server Player selects the tracks to play on.
4 . The system prompts the Server Player to enter the number of laps for each track
selected.
5. The Server Player enters the number of laps for each track selected.
6. The Server Player is assigned a particular character and is prompted to wait for Client
Players to join this game session until he wants to quit or the number of players reaches
the maximum or he chooses the option to launch the game. (A1)
7. The use case ends.
2.1.2.3
1.3.4.7.1 CLaserShield
Preconditions
The Server Player is already in the main menu of the game.
2.1.2.2
1.3.4.7
CProtective
Actors
This use case is invoked by Server Player.
This use case shows how a player sets up a game server to create a multiplayer environment.
2.1.2 Setup Game Session
Alternate Paths
None
2.1.1.5
Subflows
None
Basic Path
1. The use case starts when the Player selects the option – Help.
2. The system displays the rules of the game and the default keyboard configuration.
3. The system waits for the Player to select the option to quit to the main menu of the
game.
2.1.1.3
2.1.1.4
Preconditions
The Player is already in the main menu of the game.
Actors
This use case is invoked by Player.
2.1.1.2
2.1.1.1
This use case shows how a player asks the system for the rules of the game and how to control the
character assigned to them.
2.1.1 Help
2.1
2.1.2.1
CAccelerate
x
A use case is a function provided by a system that yields a visible result for actors. In this game, there
are three kinds of actors: Player, Server Player and Client Player, in which Player specializes into the
latter two. In addition, there are totally 12 use cases, i.e., operations for the players. Some operations
are available for all tracks while some are for a specific track only; some operations have to be done
before playing the game while others constitute the game play.
2. Use Case Model
FYP Final Report
1.3.4.6.1 CRocketEngine
1.3.4.6
1.3.4.5.1 CTyphoon
1.3.4.5
1.3.4.4.1 CTracingBomb
CStop
None
1.3.4.2
1.3.4.1.1 CBirdFeces
1.3.4.1
1.3.4 Track 4 – Sky
1.3.3.7.1 CProtectiveNet
Players will not be affected by any harmful effects including that from hindering items and
offensive items for 10 seconds.
1.3.3.7
1.3.3.6.1 CSashimi
CGlobal
None
1.3.3.5
1.3.3.4.1 CTorpedo
1.3.3.4
FYP Final Report
Alternate Paths
A1: If no Client Players have joined the game and the Server Player chooses to launch the
game, an error message will be printed on the screen and the system will return to
step 6 of the Basic Path.
Post Conditions
The Server Player is directed either to the main menu of the game or to the start of the
game.
2.1.2.5
2.1.2.6
Preconditions
The Client Player is already in the main menu of the game.
Basic Path
1. The use case starts when the Client Player chooses the option – Join Game Session.
2. The system prompts the Client Player to enter the IP address/host name of the game
server. (A1)
3. The system displays the tracks and the corresponding number of laps chosen by the
Server Player of the game server. The system prompts the Client Player to confirm to
join this game session.
4. The Client Player confirms to join this game session.
5. The Client Player is assigned a particular character and is prompted to wait for the
Server Player to launch the game until he wants to quit.
Subflows
None
Alternate Paths
A1: If the server with the entered IP address/host name cannot be reached, an error
message will be printed and the Client Player is prompted to enter a valid IP
address/host name or to terminate the use case.
Post Conditions
The Client Player is directed either to the main menu or to the start of the game.
2.1.3.2
2.1.3.3
2.1.3.4
2.1.3.5
2.1.3.6
Preconditions
The Player is already in the main menu of the game.
Basic Path
1. The use case starts when the Player chooses the option – Quit Game.
2. The system releases all resources acquired.
2.1.4.2
2.1.4.3
Actors
2.1.4.1
This use case shows how the Player quits the game.
2.1.4 Quit Game
Actors
This use case is invoked by Client Player.
2.1.3.1
This use case shows how a player connects to a game server to play the game.
2.1.3 Join Game Session
Subflows
None
xi
2.1.2.4
FYP Final Report
Subflows
None
Alternate Paths
None
Post Conditions
The game shuts down.
2.1.4.4
2.1.4.5
2.1.4.6
FYP Final Report
xii
Common Track Use Cases
Preconditions
The game has already started.
Basic Path
1. The use case starts when the Player chooses the option – Accelerate.
2. The system increases the Player’s speed by a particular amount. (A1)
3. The system renders the updated character.
Subflows
None
Alternate Paths
A1: If the increased speed of the Player exceeds the maximum speed allowed, the speed is
truncated to the maximum speed allowed.
Post Conditions
None
2.2.1.2
2.2.1.3
2.2.1.4
2.2.1.5
2.2.1.6
Preconditions
Basic Path
1. The use case starts when the Player chooses the option – Decelerate.
2. The system decreases the Player’s speed by a particular amount. (A1)
Subflows
None
Alternate Paths
A1: If the decreased speed of the Player exceeds the minimum speed allowed, the speed is
truncated to the minimum speed allowed.
Post Conditions
None
2.2.2.2
2.2.2.3
2.2.2.4
2.2.2.5
2.2.2.6
2.2.3.1
Actors
This use case shows how players change their orientation.
2.2.3 Change Orientation
Actors
2.2.2.1
This use case shows how players decelerate their characters.
2.2.2 Decelerate
Actors
xiii
2.2.1.1
This use case shows how players accelerate their characters.
2.2.1 Accelerate
2.2
FYP Final Report
Post Conditions
None
2.2.3.6
Post Conditions
None
2.2.4.6
Alternate Paths
A1: If the victim is protected by CProtective items, then the victim is not affected by the
offensive item.
xiv
2.2.4.5
Subflows
None
Basic Path
1. The use case starts when the Player chooses the offensive item to use. (A1)
2. The system prompts the Player to specify the victim if the item is CSingle.
3. The item is triggered by the Player.
4. The item exhibits its effect. (A1)
2.2.4.3
2.2.4.4
Preconditions
The Player is already in the game and the Player already possesses at least one item.
Actors
2.2.4.2
2.2.4.1
This use case shows how a player uses offensive items to hinder other players.
2.2.4. Use Offensive Items
Alternate Paths
None
Subflows
None
Basic Path
1. The use case starts when the Player chooses the option – Change Orientation.
2. The system changes the Player’s orientation by a particular value of degrees.
Preconditions
2.2.3.5
2.2.3.4
2.2.3.3
2.2.3.2
FYP Final Report
Preconditions
Basic Path
1. The use case starts when the Player chooses the option – Sink.
2. The system translates the Player’s position down by a particular amount.
3. The system translates the Player’s position up to the water level after some time.
Subflows
None
Alternate Paths
None
Post Conditions
None
2.4.1.2
2.4.1.3
2.4.1.4
2.4.1.5
2.4.1.6
Preconditions
Basic Path
1. The use case starts when the Player chooses the option – Jump.
2. The system translates the Player’s position up by a particular amount.
3. The system translates the Player’s position down to the ground after some time.
Subflows
None
Alternate Paths
None
Post Conditions
None
2.3.1.2
2.3.1.3
2.3.1.4
2.3.1.5
2.3.1.6
Actors
2.4.1.1
Actors
2.3.1.1
This use case shows how players sink temporarily in water.
Use Cases for Track 3 – Water
2.4.1. Sink
2.4
FYP Final Report
This use case shows how players jump
Use Cases for Track 1 & 2 – Land & Grand Priz
xv
2.3.1. Jump
2.3
FYP Final Report
xvi
Use Cases for Track 4 – Sky
Preconditions
Basic Path
1. The use case starts when the Player chooses the option – Fly.
2. The system translates the Player’s position up by a particular amount.
Subflows
None
Alternate Paths
None
Post Conditions
None
2.5.1.2
2.5.1.3
2.5.1.4
2.5.1.5
2.5.1.6
Preconditions
Basic Path
1. The use case starts when the Player chooses the option – Land.
2. The system translates the Player’s position down by a particular amount.
Subflows
None
Alternate Paths
None
Post Conditions
None
2.5.2.2
2.5.2.3
2.5.2.4
2.5.2.5
2.5.2.6
Actors
2.5.2.1
This use case shows how players land from the sky.
2.5.2. Land
Actors
2.5.1.1
This use case shows how players fly in the sky.
2.5.1. Fly
2.5
FYP Final Report
xvii
System Architecture
xviii
The game loop results in the following system architecture:
Since a game is a real-time system, it has to check what the player inputs and update the screen
immediately. To achieve this, the easiest way is to organize all the work in a loop in which each
iteration prepares a frame to be drawn on the screen. The following shows how the work is organized
inside a loop:
A. Clear Drawing Buffers
B. Check Input
C. Input Responses
D. Animate Objects
E. Gravity Responses
F. Collision Detection
G. Collision Responses
H. Receive and Process Network Packets
I.
Send Current State & Events of Last Frame
J.
Visibility Determination and Render 3D
K. Draw 2D
L. Swap Buffers
1
Appendix D – Analysis Model
FYP Final Report
Collision Detection
Game Engine
2.2.1 Class Diagram
Renderable Graphics Objects
CPresCollisionGroup
This class keeps a list of objects in the scene that may collide with each other.
2.1.2.2
2.2
CPresCollisionDetectionMgr
This class contains the collision detection routine that determines which pairs of objects
collide and the pairs of intersecting triangles.
xix
2.1.2.1
2.1.2 Class Descriptions
2.1.1 Class Diagram
2.1
2
FYP Final Report
CPresXModel
This class manages an external 3D model that is encoded in Microsoft DirectX File Format.
2.2.2.4
CPresLightFrame
This class manages coordinate frame information specifically for light sources.
CPresCameraFrame
This class manages coordinate frame information specifically for camera.
2.3.2.2
2.3.2.3
CPresCoordFrame
This class manages coordinate frame information such as position, orientation and
transformation of an object in the scene.
2.3.2.1
2.3.1 Class Diagram
Non-Renderable Graphics Objects
CPresBitmap
This class manages information stored in a bitmap image.
2.2.2.3
2.3
CPresPrimitive
This is the interface of the fundamental 3D object in the graphics engine.
CPresGeoObject
This is the interface of the fundamental class in the graphics engine.
xx
2.2.2.2
2.2.2.1
FYP Final Report
CPresGeometricObject
This class manages an object’s geometric information.
CPresOctreeRenderer
This class contains the routine of rendering an octree.
CPresOctreeCompiler
This class contains the routine of building an octree.
CPresMaterial
This class manages information of materials and textures.
CPresRenderDeviceMgr
This class encapsulates functionalities of initialization of and releasing resources acquired
by Direct3D.
2.3.2.5
2.3.2.6
2.3.2.7
2.3.2.8
2.3.2.9
Timer
Input
CPresTimer
This class encapsulates the functionalities provided by the high precision 64-bit hardware
timer.
Physics
CPresInput
This class encapsulates the functionalities provided by DirectInput.
2.6.1.1
CPresPhysicsMgr
This class contains the physics routines to apply gravity on geometric objects.
2.6
2.5.1.1
2.5
2.4.1.1
2.4
2.3.2.15 SPresOctreeNode
This is the data structure of an octree node.
2.3.2.14 SPresOctree
This is the data structure of an octree.
2.3.2.13 SPresBoundingBox
This is the data structure of a bounding box.
2.3.2.12 CPresLight
This class manages information of a light source.
2.3.2.11 CPresFontEngine
This class is responsible for rendering 2D bitmap fonts.
2.3.2.10 CPresCamera
This class encapsulates the view matrix.
CPresPrimitiveFrame
This class manages coordinate frame information specifically for primitives.
xxi
2.3.2.4
FYP Final Report
Networking
2.7.1.1
CPresNetwork
This class encapsulates the functionalities provided by Winsock.
2.7
FYP Final Report
xxii
Object Animation
Collision Responses
CObjectAnimator
This class manages the animation state of geometric objects in the scene.
4.
3.
1.
2.
xxiii
CCollisionResponsesMgr
This class is responsible for invoking collision response routines of geometric objects in the
scene.
The System asks CCollisionResponsesMgr to update the state of geometric objects.
The CCollisionResponsesMgr asks CPresCollisionDetectionMgr to return a list of objects
in collision and the intersecting triangles for each pair.
2.1 The CPresCollisionDetectionMgr asks CPresCollisionGroup to return geometric
objects repeatedly for each collision group.
2.2 The CPresCollisionDetectionMgr checks for objects in collision and determine the
intersecting triangles.
If a collision pair contains an item, CCollisionResponsesMgr gets the attribute values from
that item and update the state of the item.
The CCollisionResponsesMgr asks CCharacter to update its states such as position,
orientation and animation.
3.2.2 Collaboration Diagram
3.2.1.1
3.2
3.1.1.1
3.1
3. Game Code
FYP Final Report
Geometric Objects
CItem
This class stores information of an item that interacts with players. It specializes into
CHindering, CBeneficial and COffensive.
CHindering
This class of items hinders the players along the track of a race. It further specializes into
CDecelerate and CStop.
CDecelerate
This class of items makes the players travel slower than others.
CStop
This class of items stops the player from moving.
CBeneficial
This class of items benefits the players along the track of a race. It further specializes into
3.3.2.4
3.3.2.5
3.3.2.6
3.3.2.7
3.3.2.8
CCharacter
This class stores information of a character.
CGeometricObject
This class is the base class of all objects in the scene. It contains information directly related
to the game play.
3.3.2.2
3.3.2.3
CGeometricObjectMgr
This class is responsible for creating and destroying all objects in the scene.
xxiv
3.3.2.1
3.3.2. Class Descriptions
3.3.1 Class Diagram
3.3
FYP Final Report
CAccelerate
This class of items makes the players travel faster than others.
xxvi
3.3.2.31 CBirdFeces
3.3.2.14 CSingle
This class of items requires a target victim to be selected so that the victim will experience
the effects of the items.
3.3.2.25 CMother
This item prevents the player from being harmed by offensive items used by other players
3.3.2.24 CMilkBottle
3.3.2.23 CDiaper
3.3.2.22 CNeedles
This stabs players’ foot stopping them for 1 second if they step on it.
3.3.2.21 CRoadster
It may come from the back of the players, bumping them and make them run slower for 5
seconds.
3.3.2.20 CProtectiveShell
When a player acquires this item, the player will be immune from offensive items used by
other players. The protection lasts for 10s.
3.3.2.19 CFossilFuel
When a player acquires this item, the player will travel faster than other players will. The
effect will last for 5 seconds.
3.3.2.18 CCobra
seconds.
3.3.2.17 CStrangeFlowerSeed
If this item hits a victim, the victim will be hindered by a group of strange flowers. The
flowers will last for 1 second.
3.3.2.16 CAnimalTrap
This obstacle traps players stepping on it and makes them immobile for 3 seconds.
Input Responses
3.4.1.1
CInputResponsesMgr
This class contains the routines of handling player’s input.
3.4
3.3.2.35 CLaserShield
3.3.2.34 CRocketEngine
3.3.2.33 CTyphoon
3.3.2.32 CTracingBomb
3.3.2.30 CProtectiveNet
Players will not be affected by any harmful effects including that from hindering items and
offensive items for 10 seconds.
3.3.2.13 CNonAvoidable
This is a class of items whose effects are not avoidable in any circumstances by a victim. It
specializes into CSingle and CGlobal.
3.3.2.15 CGlobal
This class of items will affect all other players when used by a player.
3.3.2.29 CSashimi
3.3.2.12 CAvoidable
This is a class of items whose effects may be avoided by a victim.
3.3.2.27 COctopus
It spurts black ink onto a player, making him lose his direction and move backwards for 5
seconds.
3.3.2.26 CShark
It comes from the back of players and attacks them, decreasing their speed for 3 seconds.
for 8 seconds.
FYP Final Report
3.3.2.28 CTorpedo
xxv
3.3.2.11 COffensive
This class of items can be kept by the players and then used to hinder a victim. It specializes
into CAvoidable and CNonAvoidable.
3.3.2.10 CProtective
This class of items protects the players from being offended by offensive items.
3.3.2.9
CAccelerate and CProtective.
FYP Final Report
Network Messages
3.5.1.1
CPresNetworkMessagesMgr
This class contains the routines of handling network messages.
3.5
3.4.2 State Chart Diagram
FYP Final Report
xxvii
Monster Models
Appendix E – 3D Models
FYP Final Report
xxviii
Taizhan Models
FYP Final Report
xxix
A Track Model
Robot Models
Magician Models
FYP Final Report
xxx
Requirement and Analysis
Player Guide
System Design
Artwork
3D Modelling
User Interface Design
Timer
Rendering Routines
Octree Implementation
Collision Detection
Input
Networking
Geometric Objects
Collision Responses
Network Messages
Input Responses
Proposal Report
Progress Report
Unit Testing
System Testing & Debugging
Evaluation
Final Report & Poster
Project Presentation
Appendix F – Gantt Chart
FYP Final Report
2001
2002
Duration
(in Weeks) Jun Jul Aug Sept Oct Nov Dec Jan Feb Mar Apr
9w
2w
17w
12w
24w
4w
1w
12w
4w
4w
4w
4w
2w
8w
10w
6w
6w
2w
2w
24w
4w
4w
4w
2w
xxxi
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Lau
Pui Yu
X
Fong
Heung Wah
X
X
X
X
X
X
X
X
X
Lui Chung Man,
Clement
X
X
X
Requirement and Analysis
Player Guide
System Design
Artwork
3D Modelling
User Interface Design
Timer
Input
Graphics Rendering Routines
Octree Implementation
Physics
Collision Detection
Networking
Geometric Object
Collision Responses
Network Messages
Input Responses
Proposal Report
Progress Report
Unit Testing
System Testing & Debugging
Evaluation
Final Report & Poster
Project Presentation
Tasks
Appendix G – Division of Labour
FYP Final Report
X
X
X
X
X
X
X
X
X
X
X
Lai
Man Ting
X
X
xxxii
June 2, 2001
5:00 p.m.
Room 3464, HKUST
Clement Lui, Connie Lau, Mandy Lai, Fong Heung Wah, Prof. Lochovsky and
other groups of this project
None
Mandy Lai
4. Meeting Adjournment
The meeting was adjourned at 5:30 p.m.
3.5 Time of next meeting
The next meeting will be at 5 p.m. in Room 3464 on 4 August 2001.
3.4 Administrative information
Prof. Lochovsky said that the proposal report is to be submitted in the 3rd week of September. In
addition, there will be practice presentations in October 2001, February 2002 and May 2002. The
first presentation will last for 10 minutes; the second presentation will last for 15 minutes. The
final project presentation will last for 20 minutes at the maximum.
Although there will be a demo of this project, it will not count towards the final grade. Instead, it
will help the graders to grade this project.
3.3 Requirements in this project
Although the requirements of this project are stated in the handout, there are a few things worth to
notice. Firstly, Prof. Lochovsky said that a database design is not necessary as a typical DBMS is
too slow for a game. Secondly, from experience in the FYP of past years, most groups
implemented their games in C++ with DirectX as well as TCP/IP.
3.2 Meetings
Each group has to meet Prof. Lochovsky at least twice a month, in which there is a meeting for all
groups. A group can meet Prof. Lochovsky besides the required meetings. However, minutes of
each meeting, which are to be included in the FYP report, have to be submitted.
3.1 Beginning
Prof. Lochovsky distributed handouts to all groups of this project and explained the project
requirements.
3. Discussion Items
2. Report on Progress
Since this is the first meeting, there is no progress to be reported.
1. Approval of Minutes
Since this is the first meeting, there is no approval of minutes of previous meeting.
Absent:
Recorder:
Date:
Time:
Place:
Attending:
Group 4
xxxiv
4 August 2001
5:00 p.m.
Room 3464, HKUST
Connie Lau, Mandy Lai, Fong Heung Wah, Prof. Lochovsky and other groups
of this project
Clement Lui
Mandy Lai
2.2 Implementation platform
Prof. Lochovsky asked all groups of this project to state what platform will be used for
implementing the game.
2.2.1 Group 1
DirectX, Visual C++, TCP/IP
2.2.2 Group 2
DirectPlay
2.2.3 Group 3
DirectX, Visual C++, TCP/IP
2.2.4 Group 4
DirectX, Visual C++, TCP/IP, 3D Studio Max
2.1 Games designed
Prof. Lochovsky asked all groups of this project to state what kind of game was designed.
2.1.1 Group 1
Robots go to disable all the bombs in the shortest time.
2.1.2 Group 2
There will be a platform for players to compete with each other. If the health points
value of a player is zero, the character for that player will die and the game terminates.
2.1.3 Group 3
It is a racing game.
2.1.4 Group 4
There are four tracks for players to race. Some items will be placed on the tracks. There
are three kinds of items: one is beneficial to players, one hinders players and one will
be kept by players and used to hinder other players. The one who wins the greatest
number of races will be the winner.
The minutes of the first meeting were submitted for approval.
Absent:
Recorder:
Date:
Time:
Place:
Attending:
Group 4
th
Minutes of the 1st Group Meeting
Final Year Project: Multi-player, Network-based, 3D Game
FYP Final Report
Minutes of the 2nd Group Meeting
xxxiii
Appendix H – Meeting Minutes
FYP Final Report
xxxv
There will be two PC’s assigned to each group for testing in the FYP lab. The first one
will be assigned during September while the second one will be assigned later.
3.2.2 Demonstration
Lastly, Prof. Lochovsky reminded the groups that the first demonstration will be at the
end of September to the beginning of October. Each group is expected to use a few
slides to give a brief presentation.
3.2 Additional information
3.2.1 Software sponsorship
Student Fong Heung Wah in Group 4 asked whether there would be software
sponsorship for each group. Prof. Lochovsky claimed that there were five copies of 3D
Studio Max. If a group needed to ask for software, it should make a list of software and
send email to Prof. Lochovsky requesting for specific software sharing. As Prof.
Lochovsky was not sure what software was installed in the FYP lab, groups who need
software sponsorship should send email directly to the CS Department. Requests should
be made early as it takes about three weeks for approval of software sponsorship.
Prof. Lochovsky also reminded us that the project proposal has to be due in the 3rd or 4th week of
September. It was stated that the project proposal should include lists of hardware and software
environment needed for the project. There should be reasons specified for each choice of software
used. An Appendix, which includes a draft of the player guide, should be placed in the project
proposal.
3.1 Items that need to be handed in at the next meeting
Prof. Lochovsky said that the next meeting would be at 5 p.m. in Room 3464 on 1st September
2001. In the next meeting, minutes of this meeting should be handed in. As Prof. Lochovsky will
be away from 7th-17th September, if a group wants feedback from Prof. Lochovsky about the
project proposal, a draft should be handed in at the next meeting. In addition, Prof. Lochovsky
had given us a guideline to the project proposal in the web page http://www.cs.ust.hk/ug/fyp.
3. Discussion Items
FYP Final Report
September 1, 2001
5:00 p.m.
Room 3464, HKUST
Clement Lui, Prof. Lochovsky and other groups of this project
Connie Lau, Mandy Lai, Fong Heung Wah
Clement Lui
xxxvi
3.3 Communication tutors
Prof. Lochovsky said that besides giving him reports for proof reading, all groups should seek
advice on their reports from the communication tutors.
There will be no meetings in December as all groups have final examinations.
3.2 Demonstrations in the following meetings
Prof. Lochovsky proposed the dates of monthly group meetings. The first meeting will be on
26/9/01, the second meeting will be on 31/10/01 and the third meeting will be on 28/11/01.
During these meetings, all groups have to demonstrate their work according to the schedule set at
the beginning. All groups have to demonstrate moving a graphical object in a machine. In
addition, in the second demonstration, they have to demonstrate controlling a graphical object in a
machine whose movement is shown in both machines. Besides that, in the third demonstration,
they have to be able to control graphical objects whose movement is shown in both machines.
3.1 FYP machine
Prof. Lochovsky said that all groups should ask CS System to assign them FYP machines for
demonstrations in the following meetings. All groups should discuss the hardware and software
configurations with CS System.
3. Discussion Items
The draft of the proposal report and the minutes of the second meeting were submitted.
The minutes of the first meeting were approved by Prof. Lochovsky.
Date:
Time:
Place:
Attending:
Absent:
Recorder:
Group 4
Minutes of the 3rd Group Meeting
FYP Final Report
1.4 Requirement of next meeting
In the next meeting, a demo rendering and controlling a simple geometric object locally and
remotely will be required with two computers being able to communicate in one-way connection.
The next meeting will be at 7:00pm in the FYP lab on October 31, 2001.
1.2 Demonstration
Prof Lochovsky asked the four groups to demonstrate their project progress in the FYP lab. The
requirement of the demonstration was to render and control a simple geometric object locally in a
3D environment.
1.1 Beginning
Prof. Lochovsky asked the four groups to give their presentations of their proposal reports.
1. Discussion Items
Absent:
Recorder:
September 26, 2001
7:00 pm
Room 2464 and FYP lab
None
Mandy Lai
October 31, 2001
7:00 pm
CS lab 4
None
Mandy Lai
xxxviii
1.3 Requirement of the next meeting
In the next meeting, a demo rendering and controlling a simple geometric object locally and
remotely is required with two computers being able to communicate in two-way connection, i.e.,
the object can be controlled in both machines and simultaneously can be viewed by the two
machines.
The next meeting will be at 7:00 p.m. in the FYP lab on 28 November 2001.
1.1 Demonstration
In CS lab 4, Prof. Lochovsky asked the four groups to demonstrate the progress of rendering and
controlling a simple geometric object locally while the other machine can synchronize the
information received from the first machine.
1. Discussion Items
Absent:
Recorder:
Date:
Time:
Place:
Attending:
Group 4
Group 4
Date:
Time:
Place:
Attending:
Minutes of the 5th Group Meeting
FYP Final Report
xxxvii
FYP Final Report
1.2 Time of Next Meeting
The next meeting will be at 6 p.m. in FYP Lab, Room 4210, on 6th March 2002
1.1 Presentations
Each group presented the progress of their projects.
1.1.1 Group 1
Robots try to disable all bombs in the shortest time. Bounding spheres are used for
collision detection.
1.1.2 Group 2
Separated the game engine into several parts. Rendering and networking have been
concentrated on so far and more time will be spent on creation of models.
1.1.3 Group 3
Their game is a racing game for different kinds of balls. Another software is used to
export a max file to a file format that can be loaded by the Genesis3D engine.
1.1.4 Group 4
Classes for physics and animation were added to the system. The game now supports 2way communication for the networking part. Different animations can be loaded and
rendered. Finite state machine (FSM) is used to handle input response. The Octree data
structure is used for collision detection and view frustum culling.
1. Discussion Items
Absent:
Recorder:
February 6, 2001
7:00 p.m.
Room 2302, HKUST
Connie Lau, Mandy Lai, Andy Fong, Prof. Lochovsky and other groups of this
project
Clement Lui
Andy Fong
March 6, 2001
6:00 p.m.
Room 4210, FYP Lab, HKUST
Connie Lau, Mandy Lai, Andy Fong, Clement Lui, Prof. Lochovsky and other
groups of this project
None
Andy Fong
xl
1.2 Time of Next Meeting
The next meeting will be at 6 p.m. in the FYP Lab, Room 4210, on 10th April 2002
1.1 Demonstrations
In the FYP Lab, Prof. Lochovsky asked the four groups to demonstrate their progress on the
different parts of the games such as rendering, networking and collision detection.
1.1.1 Group 1
Supports 2-player network game. Players can pick up a bomb.
1.1.2 Group 2
Cannot provide a demo because of problems with the machines in the FYP Lab.
1.1.3 Group 3
Supports 2-player game. The ball can move along the track. Collision detection is
handled. The visibility of walls are checked before rendering. It also supports chatting
between two players.
1.1.4 Group 4
Characters can run and jump in the game with different animations. Gravity effect is
added. Moving on non-smooth surface and collision detection between character and
track are supported using the Octree method.
1. Discussion Items
Absent:
Recorder:
Date:
Time:
Place:
Attending:
Group 4
Group 4
Date:
Time:
Place:
Attending:
FYP Final Report
xxxix
FYP Final Report

Final Report - Hong Kong University of Science and Technology

Transcription

Similar documents

Untitled - West Ham United

ExamView Player

the program flyer

Is your player Tour Series ready?

board games online

CUSL Roster Instructions

Step by step instructions for players registering for Pelada FA

Land Before Time Make A Match Rules

GestureXtreme

Looking to Hire the Very Best?