prestissimo - hkustfred/fyp/...reports/ng-final.pdf · fyp final report 3 multi-player,...

47
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 Signature: Date: Name of Student: Lai Man Ting Signature: Date: Name of Student: Lau Pui Yu Signature: Date: Name of Student: Lui Chung Man, Clement Signature: Date:

Upload: others

Post on 26-Jul-2020

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

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 fulfillmentof the requirements for COMP 394

in the

Department of Computer ScienceHong Kong University of Science and Technology

Name of Student: Fong Heung Wah Signature: Date:Name of Student: Lai Man Ting Signature: Date:Name of Student: Lau Pui Yu Signature: Date:Name of Student: Lui Chung Man, Clement Signature: Date:

Page 2: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

Multi-player Network-based 3D Game

Abstract

The goal of this project was to design and implement a 3D, 4-player race game. The game allowsplayers to race on four tracks: Land, Water, Space and Grand Prix. When the players race on one ofthe tracks, they may encounter different kinds of objects. Some objects benefit the players while someobjects hinder them. In addition, players may pick up some items and then use them later to hinderother players.

In this game, players can experience not only the correct responses to the actions by the charactersthey control, such as hitting a wall and jumping, but also instantaneous response when they press theright key on the keyboard. In other words, the system has to react correctly to players’ input withreasonable 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 builtto facilitate fast and efficient collision detection and visibility determination, which in turn facilitatesefficient polygon rendering.

In addition, by using the game engine implemented, a simple multiplayer race game was successfullycreated. The system is able to give correct responses when two entities in the virtual world collidewith each other. Players can also experience realistic responses when the controlled character hits awall or jumps. The performance of the game was also kept at an acceptable level.

Page 3: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

Multi-player Network-based 3D Game

Table of Contents

1. Introduction .............................................................................................................. 11.1 Motivation .............................................................................................................................. 11.2 Project Description ................................................................................................................. 11.3 Problems ................................................................................................................................. 1

2. Results ....................................................................................................................... 32.1 Design Phase .......................................................................................................................... 3

2.1.1 System Architecture ..................................................................................................... 32.1.2 Game Engine ............................................................................................................... 42.1.3 Game Code ................................................................................................................... 9

2.2 Implementation Phase .......................................................................................................... 172.2.1 Tools Used .................................................................................................................. 172.2.2 Octree Rendering ....................................................................................................... 172.2.3 Collision Detection between Track and Dynamic Objects ....................................... 182.2.4 Visibility Determination ............................................................................................. 18

2.3 Testing Phase ........................................................................................................................ 182.3.1 Testing Platform ......................................................................................................... 182.3.2 Octree Construction ................................................................................................... 192.3.3 Collision Detection - Accuracy for Different Depths of Octree Traversal ............... 192.3.4 Collision Responses - Changing Angular Velocity in a Collision ............................ 212.3.5 Visibility Determination ............................................................................................. 22

2.4 Evaluation Phase .................................................................................................................. 22

3. Conclusions ............................................................................................................. 233.1 Summary ............................................................................................................................... 233.2 Possible Future Extensions .................................................................................................. 23

3.2.1 Game Engine .............................................................................................................. 233.2.2 Game Play .................................................................................................................. 23

4. References ............................................................................................................... 244.1 Books .................................................................................................................................... 244.2 Internet Links ........................................................................................................................ 244.3 Documentation ..................................................................................................................... 24

5. Appendices ................................................................................................................. iAppendix A – Key Contributions ...................................................................................................... iAppendix B – Player Guide ............................................................................................................ iiiAppendix C - Domain and Use Case Models .................................................................................. vAppendix D – Analysis Model .................................................................................................... xviiiAppendix E – 3D Models .......................................................................................................... xxviiiAppendix F – Gantt Chart ........................................................................................................... xxxiAppendix G – Division of Labour ............................................................................................. xxxiiAppendix H – Meeting Minutes ................................................................................................ xxxiii

Page 4: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 1

Multi-player, Network-based, 3D Game

1. Introduction

1.1 Motivation

The publication of game titles such as Ultima Online by Origin Systems, Lineage by NCsoft Corp. andGulong Online by Gameone System Ltd. shows that multiplayer, online entertainment is gainingpopularity 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 witheach 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 tohave fun but do not want to manipulate so many things. These players want to start playing the gameas soon as possible without having to tune the characteristics of the characters. They also do not wantto either maintain or enhance their status through many actions when playing the game. It is theresponsibility of game developers to create games that satisfy the need of these players; that is whatthis 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 allowsplayers to race on four tracks: Land, Water, Space and Grand Prix. When the players race on one ofthe tracks, they may encounter different kinds of objects. Some objects benefit the players while someobjects hinder them. In addition, players may pick up some items and then use them later to hinderother players.

In this game, players can experience not only the correct responses to the actions by the charactersthey control, such as hitting a wall and jumping, but also instantaneous response when they press theright key on the keyboard. In other words, the system has to react correctly to players’ input withreasonable performance.

1.3 Problems

In order to achieve the response correctness mentioned every entity in the virtual world of the gamehas to behave reasonably correctly when they are hit by something or they hit something. Forexample, when a character is hit by a bomb, it is expected that the bomb explodes and the character isthrown away in one direction. This is where game logic comes into play to handle the interactionamong the entities in the virtual world.

No matter how accurate the behavior of the entities in the virtual world, it is useless if the entitiescannot be displayed on the screen. 3D models of the entities therefore have to be designed. Althoughtechnologies such as 3D modeling software packages and 2D image editors allow easy construction of3D models, loading them into the system so that they can be displayed when necessary requires somework.

Since this is a multiplayer game, network communication is essential to allow players to playtogether. In addition, synchronization is important in keeping the consistency of the virtual world indifferent 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 thevirtual world accordingly. In addition, it has to distinguish the validity of players’ input so that nowork is done when a player presses a wrong key.

Given the functional requirements stated above, the system has to achieve them with reasonableperformance. Each of the first three tasks mentioned has its own latency, which is significant inaffecting the overall performance of the whole system.

The latency of the game logic mainly comes from collision detection. Collision detection involvesdetermining which pairs of objects collide with each other; this, in turn, involves checking whether a

Page 5: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 2

Multi-player, Network-based, 3D Game

pair of polygons intersects with each other. If the brute-force approach is used, i.e., comparing thepolygons one by one, the running time complexity is O(n2). A typical scene consists of thousands ofpolygons. Obviously, today’s hardware is not capable of performing collision detection on such ascene 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 thegraphics pipeline that are not included in the final image. Such polygons are transformed and lit at theearly stages in the graphics pipeline. However, they are rejected at later stages before rasterization sothat they are not drawn on the screen. The unnecessary work done at the early stages wastesprocessing time and thus performance is affected.

The latency of network communication depends on the size of a packet and the network bandwidthavailable. The greater the size of a packet or the narrower the network bandwidth, the longer it takesto send or receive a packet. Therefore, the amount of information in a packet and the frequency ofpacket transmission has to be just enough for synchronization.

Page 6: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 3

Multi-player, Network-based, 3D Game

2. Results

2.1 Design Phase

2.1.1 System Architecture

Since a game is a real-time system, it has to check what the player inputs and update the screenimmediately. To achieve this, the easiest way is to organize all the work in a loop in which an iterationprepares a frame to be drawn on the screen. The following table shows how the work is organizedinside the loop:

Sequence Tasks1 Clear Drawing Buffer2 Check Input3 Input Responses4 Gravity Responses5 Collision Detection6 Collision Responses7 Animate Objects8 Receive and Process Network Packets9 Send Current State and Events of Last Frame10 Visibility Determination11 Render 3D Models12 Draw 2D13 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

Page 7: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 4

Multi-player, Network-based, 3D Game

The system can be divided into two main parts: game engine and game code. An engine is a piece ofsoftware that takes in data and responds with respect to the given data. A game engine is an enginethat is used to assist game development. In this project, the game engine provides services ofrendering graphics, performing collision detection, receiving input from players, performing physicscalculation, handling networking and measuring performance. The game code uses the servicesprovided by the game engine to perform the game logic, which includes collision responses, inputresponses, network message handling and other operations of characters and items.

2.1.2 Game Engine

2.1.2.1 GraphicsThis component contains rendering related functionalities for all graphics. It is divided intoRenderable Objects and Non-Renderable Objects.

2.1.2.1.1 Renderable ObjectsThis is a set of classes to be rendered on the screen. The class diagram of this component anddescriptions 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 supportscolor-keying, which is useful for removing the background color of an image. It is useful for UIdesign.

2.1.2.1.1.2 CPRESXMODEL

This class loads an external 3D model, which is encoded in Microsoft DirectX File Format, andrenders the model on the screen.

2.1.2.1.1.3 CPRESOCTREE

This class implements the octree data structure, which speeds up collision detection and view frustumculling. It loads pre-compiled octree data stored in a file and renders its polygons on the screen. Anoctree is simply a tree with a maximum of eight children at every node. This is an ideal data structurefor representing a 3D model enclosed by bounding cubes. The root of an octree contains a boundingcube that encloses all the geometry of the model. The children at each node are the eight boundingcubes of equal size that subdivide the parent into octants. Subdivision stops when either the depth ofthe octree or the number of polygons reaches a threshold. The octree construction, rendering andalgorithms for collision detection and view frustum culling will be discussed in later sections.

Page 8: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 5

Multi-player, Network-based, 3D Game

2.1.2.1.2 Non-Renderable ObjectsThis is a set of classes that are not able to be rendered on the screen but are essential in renderingRenderable Objects correctly. The class diagram of this component and descriptions of its majorclasses 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 ofan object in the scene. Every renderable object has to be contained by an instance of this class in orderto be rendered correctly. In addition, it is able to build a tree of coordinate frames in order to achievecomplex transformations. This has the effect that when the root coordinate frame of the tree istranslated 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, whichare designated to contain a light source, a camera and a 3D drawing primitive, respectively.

2.1.2.1.2.2 CPRESFONTENGINE

This class uses the functionalities provided by CPRESBITMAP to render 2D bitmap fonts. It is essentialin UI design.

2.1.2.1.2.3 CPRESRENDERDEVICEMGR

This class encapsulates functionalities of initialization of and releasing resources acquired byDirect3D.

2.1.2.1.2.4 CPRESOCTREECOMPILER

This class takes in a 3D model stored in CPRESXMODEL and compiles the geometry of the model intoan 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 rootof the octree that contains the references of all polygons of the model. If the number of polygons inthis node is greater than a threshold, it is subdivided into eight children nodes. The bounding cube ofeach child node has a dimension that is half of that of the bounding cube of its parent node. For eachchild node, if its bounding cube overlaps with a polygon, then the polygon will be stored in the node.

Page 9: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 6

Multi-player, Network-based, 3D Game

There are two issues of storing polygons in a node. One is how to store a polygon. Obviously, it willbe very memory inefficient to store copies of the polygon at every node in the tree. A reference to thepolygon is therefore stored instead of duplicating the polygon. The other issue is what to do when apolygon spans across node boundaries. One solution is to split the polygon along the boundaries. Thisgives a very accurate partition but generates additional polygons. The run-time performance is thusadversely affected. It was determined that the nodes overlapping with the polygon will store areference to the whole polygon. This introduces another problem: when rendering a polygon spanningacross node boundaries, the polygon will be drawn more than once. In order to prevent duplicaterendering 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 athreshold. In addition, a bounding sphere is added to each node that facilitates further speed-up incollision detection.USES OF OCTREE DATA STRUCTURE

An octree is a simple spatial partitioning scheme that provides easy access to a subset of polygonsclustering around a spatial location within the 3D model. Thus it is easy to reject a large amount ofpolygons that are unimportant when performing visibility determination and collision detection.Hence, it speeds up performance significantly.

2.1.2.1.2.5 CPRESVISIBILITYMGR

This class makes use of the octree data structure to determine which polygons of a 3D object arevisible and should be passed into the graphics pipeline for processing. The details of visibilitydetermination 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 theroot node is outside/inside the view frustum, the node is marked as OUTSIDE/INSIDE and theroutine ends. If the node intersects with the view frustum, the node is marked as INTERSECT and theroutine ends if this node is a leaf; otherwise, we proceed to its child nodes and repeat the aboveprocess.

After processing the octree, it is ready to be rendered. Firstly, the traversal starts from the root node. Ifit is found that this node is outside the view frustum, then this implies that all the polygons inside itare outside the view frustum and there is no need to pass them to the graphics pipeline. If the node isfound to be inside the view frustum, then this implies that all the polygons inside it are inside the viewfrustum and thus are passed to the graphics pipeline. If the node intersects the view frustum, then theoctree will be traversed down and the above process is repeated. If a leaf is found to intersect the viewfrustum, 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 seewhether it was already rendered. No polygon will be passed to the graphics pipeline more than oncewithin an iteration of the game loop.

By using this scheme, most polygons that are not included in the final image will be rejected fromentering the graphics pipeline and thus the rendering performance is improved.

2.1.2.2 Collision DetectionAs stated in the “Introduction” under “Problems”, every entity in the virtual world of the game has tobehave reasonably correctly when they are hit or they hit something. This subsystem is therefore usedto detect collisions between any two objects in the virtual world.

2.1.2.2.1 Collision GroupsIf two objects never collide with each other, there is no need to detect any collision between them. Inorder to prevent such unnecessary object-object comparisons, which affect the performance of thegame, objects in the virtual world are organized into groups, as shown in the following table:

Page 10: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 7

Multi-player, Network-based, 3D Game

Polygons: 1,2,3,4

Polygons: 1 Polygons: 2 Polygons: 3 Polygons: 4R t

Level 1

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 onegroup 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 RoutineSince, to give real-time performance, it is impossible to check for the intersection of every pair ofpolygons 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 thepolygons from consideration, before performing a polygon-polygon intersection test, which is moreexpensive. The 2D version of the basic routine of detecting a collision between a pair of objects afterthey are transformed to the same coordinate space is shown below:

Object conditions ExplanationsThe octree of an object is represented as follows:

When another object approaches, the octree of both objects are traversed.As the bounding boxes of both roots intersect, octree 1 is traversed down alevel while octree 2 stays on root level.

Check for intersections between each bounding box of level 1 nodes andthe bounding box of the root of octree 2. In this case, polygons from threechildren in level 1 of octree 1 are ignored as their bounding boxes do notintersect with the bounding box of the root of octree 2. Continue traversingdownwards in octree 1 and repeat the above process until leaf level isreached or the bounding boxes of all children intersects with the boundingbox of the root in octree 2.

1 2

3 4

Page 11: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 8

Multi-player, Network-based, 3D Game

In this case, level 1 of octree 1 is ready the leaf level; therefore, downwardtraversal of octree 2 starts. Polygons from three children of octree 2 areignored as their bounding boxes do not intersect with the bounding box ofthe right-bottom leaf of octree 1. Finally, only the polygons in one leaffrom each octree are compared in order to determine whether two objectscollide.

Table 4: Collision detection routine using octree data structure

After determining which pair(s) of polygons intersects with each other, the normals of both polygonsare returned. The collision responses subsystem then uses these normals for further processing.

2.1.2.2.3 Dynamic Collision Detection RoutineThe above routine is useful for collision detection between a dynamic object and a track object or acheckpoint, but not for that between any two dynamic objects or between a dynamic object and astatic object. In this project, the size of a track object is large compared to a dynamic object. The sizeof the bounding box of a leaf of the octree of a track object is thus large compared to that of adynamic object. Hence, no matter how fast the dynamic object is, it is still able to ignore some childnodes of the track object. The number of polygon-polygon intersection tests can therefore be reducedby using the basic collision detection routine. On the other hand, a checkpoint only consists of a fewpolygons. 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 objectis fast enough, it may penetrate deeper into another object. This incurs a large number of expensivepolygon-polygon intersection tests, thus affecting the performance of the game. Therefore, a dynamiccollision detection routine is applied for detection of collisions between two dynamic objects andbetween a dynamic object and a static object.

How the octrees are traversed is similar to the basic routine, except that this routine checks for sphere-sphere intersection instead of box-box intersection, the maximum depth of traversal is limited andthere is no polygon-polygon intersection test. A sphere-sphere intersection test is used because it iseven simpler and faster than box-box intersection. In addition, the corresponding collision responseswill be simpler to handle, especially when two objects bounce away from each other. A limit on thedepth of traversal is imposed because traversing an octree using a sphere-sphere intersection test isexpensive. This will be explained in “Visibility Determination” in the Evaluation Phase. How deepthe traversal should be will be discussed in “Collision Detection” in the Testing Phase. Since collisionresponses using spheres yields good results, there is no need to perform a polygon-polygonintersection 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 collisionoccurs while they are moving. After some geometric calculations, their correct velocities in order notto penetrate each other are determined. This is illustrated below:

Figure 4: Dynamic collision detection using spheres

2.1.2.3 InputThis subsystem is responsible for determining which key a player presses. It also involves acquiringsystem resources when this subsystem is initialized and releasing them when the game shuts down.

Page 12: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 9

Multi-player, Network-based, 3D Game

2.1.2.4 PhysicsThis 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 ResistanceThis effect reduces the velocity of an object by multiplying it with an air resistance factor, which isbetween 0 and 1.

2.1.2.4.1 Walk-on-roadThis effect keeps characters walking on the floor. When a character travels up a slope, its positionshould be raised as it tries to move forward. When a character travels down a slope or falls down, itshould 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 thetrack floor needs to be processed. Firstly, the system determines which node of the octree thecharacter is in. Then, the system searches a polygon in the node under or above which the character iscurrently standing. The system then moves the character just above the floor.

2.1.2.4.3 Area RestrictionThis effect restricts characters from moving out of the virtual world. It is just for the Space track ascharacters can fly anywhere and so they can get lost easily. In other tracks, players cannot fly and theyare bounded by the track objects.

2.1.2.5 NetworkingThis subsystem provides basic functions for network communication. It provides network servicessuch as initializing a socket, making or accepting connections, sending or receiving messages anddisconnecting a connection.

2.1.2.6 TimerThis subsystem is used to measure the performance of the system. It works by counting the number ofiterations of the game loop per second. The result is called the frame rate, which is measured inframes per second (FPS), and is used in synchronization of the velocities of entities in the virtualworld.

Consider that the game is run on two different machines: one has a low frame rate and the other has ahigh frame rate. When it is expected to see a character move 10 pixels per second, the character maymove just 1 pixel per second on the machine having a low frame rate while it may move 100 pixelsper second on the machine having a high frame rate. This problem even exists when considering justone machine. The frame rate may fluctuate throughout the game as the number of polygons passingthrough the graphics pipeline varies.

It is not desirable to see players using different machines experiencing different moving speeds. Thevelocity of a moving entity in the virtual world is therefore multiplied with a scalar. The scalar isdetermined by dividing a defined frame rate, say 60 FPS, by the current frame rate. The multipliedvelocity 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 indifferent machines.

2.1.3 Game Code

2.1.3.1 Geometric ObjectsThis subsystem is responsible for managing all objects in the game world. The class diagram anddescriptions of its major classes are shown below:

Page 13: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 10

Multi-player, Network-based, 3D Game

Figure 5: Class diagram of Geometric Objects subsystem

2.1.3.1.1 CGeometricObjectThis class represents an object in the game. It specializes into CTrack, CCharacter and CItem. Itstores the geometric information and parameters of an object in which other subsystems may beinterested.

2.1.3.1.2 CCharacterThis 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 bychanging its pose when it moves for a certain distance. The poses of a character are actually keyframes of the character’s animation and are stored as octrees.

2.1.3.1.3 CItemSimilar to characters, some items are also dynamic objects, which have animations when they aremoving. The animation effect of an item is achieved in a way similar to that of a character. There aretotally twenty items in this game, contributing eight main item types. The class diagram of items isshown below:

Figure 6: Class diagram of items

The following table shows the details of each item.

Page 14: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 11

Multi-player, Network-based, 3D Game

Track Item DetailsAnimal Trap This item traps the characters stepping on it and makes

them immobile for 3 seconds.Strange FlowerSeed

If the character hits this strange flower seed, the victimwill be hindered and blocked by a group of strangeflowers, which lasts for 1 second.

Cobra This snake will screw up the victim, stopping thecharacter from moving for 3 seconds.

Fossil Fuel When a character encounters this item, the character cantravel faster than other characters. The effect will last for5 seconds.

Land

Protective Shell When a character encounters this item, the character willbe immune from offensive items used by othercharacters. The protection lasts for 10 seconds.

Roadster It may come from behind or in front of the characters,bumping them and making them travel slower for 5seconds.

Needles This stabs characters’ feet stopping them for 1 second ifthey step on it.

Diaper This will stop the victim for 3 seconds.Milk Bottle This item increases the character’s speed for 5 seconds.

GrandPrix

Mother This item prevents the character from being harmed byoffensive items used by other characters for 8 seconds.

Shark It comes from behind or in front of characters and attacksthem, decreasing their speed for 3 seconds.

Octopus It spurts black ink onto a character so that the characterloses its direction for 5 seconds.

Torpedo The victim is stopped for 3 seconds.Sashimi Characters can swim faster for 5 seconds.

Water

Protective Net Characters will not be affected by any harmful effectsincluding that from hindering items and offensive itemsfor 10 seconds.

Bird Feces Reduces a character’s speed by 50% for 10 seconds.Tracing Bomb The explosion stops the attacked characters for 3

seconds.Typhoon Attacks all other characters and causes them to lose

control for 5 seconds.Rocket Engine Increases the character’s speed by 100% for 8 seconds.

Sky

Laser Shield Protects the character from all harmful effects, includingthat from hindering items and offensive items for 20seconds.

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 typewill be discussed in “Character-Item Collision Responses”.

Page 15: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 12

Multi-player, Network-based, 3D Game

Type of Item ItemRocket EngineMilk BottleFossil Fuel

Accelerate

SashimiMotherProtective NetLaser Shield

Beneficial

Protective

Protective ShellTorpedoBird FecesShark

Decelerate

Roadster

Hindering

Stop Animal TrapStrange Flower SeedNeedles

Avoidable

OctopusCobraDiaper

Single

Tracing Bomb

Offensive

Non-avoidable

Global Typhoon

Table 6: Item Types

2.1.3.1.4 CTrackThis class represents a track in the game. A track consists of three parts: track objects, floor andcheckpoints. Track objects include walls, caves, stones and other real objects except the floor. Thefloor is the place on which the characters walk. Checkpoints are used to detect whether the charactersfollow the track. They are transparent planes located somewhere in a track. They are not rendered, butare used by the collision detection manager. A track has to be separated into different parts becausedifferent collision detection and physics simulation methods can be applied more easily in order toachieve high performance of the game.

2.1.3.1.5 CGeometricObjectMgrThis class is responsible for loading and deleting every object in the game.

2.1.3.2 Collision ResponsesThis subsystem contributes to the main part of the game logic. There are five kinds of collisionresponses in the game: character-character, character-track, character-item, item-track and character-checkpoint collision responses.

2.1.3.2.1 Character-Character Collision ResponsesCharacters are dynamic objects. As discussed in Section 2.1.2.2, collision detection of two dynamicobjects is based on sphere intersection tests. Their collision responses thus use the results from sphereintersection tests. The following table shows the flow of a sphere-sphere collision:

Page 16: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 13

Multi-player, Network-based, 3D Game

Stage 1 Stage 2 Stage 3

There is a collision detectedalong the expectedmovements of two balls.

The two balls are assignedvelocities so that they stopwhere they collide with eachother.

After that, they move in newdirections.

Table 7: Character-character collision responses

2.1.3.2.2 Character-Track Collision ResponsesThe following table shows the ideal collision responses when a character hits a wall:

Stage 1 Stage 2 Stage 3

There is a collision detectedalong the expectedmovements of a character.

The character is assigned avelocity so that it stops whereit hits the wall.

After that, it moves in a newdirection.

Table 8: Ideal character-track collision responses

However, such a response is actually impractical because it requires checking each intersectingpolygon between the character and the track to find out how long the character should move before anintersection occurs. As a result, the performance will be affected. Instead, it was decided to change thevelocity of a character to the new direction directly after a collision is detected. The new direction isdetermined 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 ResponsesThe following table shows what each type of items will do on the character if a character-itemcollision occurs:

A track object

Page 17: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 14

Multi-player, Network-based, 3D Game

Item type Effects on the character in a character-item collisionAccelerate The character’s speed will increase by a factor according to its

current speed by using the accelerate function of the characterwith a positive factor.

Beneficial

Protective The character will be protected from all unfavorable itemsattacking it by adding a model (for example, Mother) surroundingthe character and setting the bit of checking collision with otherhindering and offensive items (thrown by other players) to befalse.

Decelerate The character’s speed will decrease by a factor according to itscurrent speed by using the accelerate function of the characterwith a negative factor.

Hindering

Stop The character will be forced to stop at its current position bysetting the velocity of the character to be zero.

When this kind of item collides with the character the first time, this means theitem is kept by that character and it will appear in the character’s item list. If asecond collision is detected, this means the user having this item uses it to attackother players.

Avoidable This kind of item is avoidable, which means that the player candodge and avoid being attacked by the item.This kind of item is non-avoidable, which means that the playercannot dodge and avoid being attacked by the item. Once theplayer uses this kind of item, all the other players or the specifiedtarget 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 ofitem. Once the user wants to use this kind of item, it isrequired to specify the target.

Offensive

Non-avoidable

Global The target for this item is all other players.

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 ResponsesInitially, the items are placed on the floor of the track. There are no collision responses as there is nocollision between the track and items.

When a player plays the game, beneficial items and hindering items only potentially collide withcharacters. 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 byplayers. Collisions may occur between these items and the track. The collision responses in this casewill be rendering some animations showing explosions or just making them invisible.

2.1.3.2.5 Character-Checkpoint Collision ResponsesIn order to check whether a character follows a track, there is a number that shows the ID of the nextcheckpoint the character has to reach. When the character collides with a correct checkpoint, thenumber will be updated to the ID of a new checkpoint; otherwise, nothing happens and this impliesthat the character is going the wrong way.

2.1.3.3 Input ResponsesThis subsystem uses the services provided by the Input subsystem in the game engine and doesappropriate processing of a player’s inputs. The following tables show different responses to differentkeys pressed in different circumstances.

Page 18: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 15

Multi-player, Network-based, 3D Game

Input key from keyboard Response“y” / “n” Choose to be a server (y) or a client (n)Numbers Number of laps chosenEnter Start the gameEscape Quit the game

Table 10: Input responses before the game starts

Input key from keyboard Response“a” Move forward or accelerate“z” Move backward or decelerate“s” Jump / SinkNumber “1”Number “2”Number “3”Number “4”Number “5”

Choose an item to use

Up arrow Face upDown arrow Face downLeft arrow Turn leftRight arrow Turn rightEscape Quit the game

Table 11: Responses to keyboard input during the game

2.1.3.4 Network MessagesThis subsystem is responsible for handling the message exchange among player machines. There aretwo approaches to handle the information exchange in a multiplayer, network game: the client-servermodel and the peer-to-peer model. In the client-server model, there is a server to which clients areconnected. Clients communicate with each other through the server. In the peer-to-peer model, thereis no dedicated server. Instead, a connection is established between every pair of clients. Thefollowing 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 tobe established for all machines in the peer-to-peer model while only one connection has to beestablished for all clients in the client-server model. Resources consumption in the client-server modelis thus more efficient.

There are two kinds of messages in the game: data messages and control messages. Data messagescontain information of characters such as positions and velocities while control messages contain

Page 19: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 16

Multi-player, Network-based, 3D Game

information controlling the flow of the game. For example, after a client successfully connects to theserver, it signals the server that it is ready to play the game by sending a control message. After suchcontrol 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 andreceiving of messages. There are some differences between the functionalities of this subsystem in theserver and the clients. For the server, this subsystem maintains one listen socket and one to threeactive sockets. The listen socket is used to accept new incoming clients while the active sockets areused to send and receive messages from existing clients. For the clients, each of them has only oneactive socket for exchanging information with the server. When the server receives a data messagefrom a client, it broadcasts the message to all other clients, thus keeping the game state of every clientsynchronized.

2.1.3.5 Other Design Issues

2.1.3.5.1 Placing Items on TracksThe exact locations of items must be known so that the items are placed in appropriate locations alongthe track where characters are able to acquire them easily. A small system was therefore built tocollect such information. It consists of a character with a camera behind and a track, with thecharacter being able to move around the track. The user moves the character around to find a suitablelocation on the track for an item to be placed. The user presses a particular key to inform the systemto output the information in a text file when he finds a suitable location. With the information fromthe text file, items can be placed on the track appropriately.

2.1.3.5.2 Lap CountingIn order to win the game, a player has to finish the required number of laps in the shortest time. Asimple mechanism was used to count the number of laps a character already finished. It works byplacing some checkpoints throughout the tracks. A checkpoint is actually an invisible plane modelwhich cuts across the track. Although it is invisible, a collision response results when it is hit by acharacter.

Once the player is detected to pass through a checkpoint, the character is expected to pass through thenext checkpoint on the track, as discussed in “Character-Checkpoint Collision Responses”. Thenumber of laps that a character has traveled can be determined by counting the number of times thatthe character has passed through the last checkpoint on the track. When it is found that a character haspassed through the last checkpoint for the required number of times, the winner can be determinedand the game ends.

2.1.3.5.3 User InterfaceThe user interface was designed to display game information to players. Such information includesspeed, 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 bitmapimages and rendered using the Font Engine in the Graphics subsystem. The background color of theimages, which is magenta, is removed when rendering the images. This is achieved by copying theimages to the back-buffer pixel by pixel except the pixels of the background color, which is magentain this case. Magenta was chosen to be the background color because it is uncommon among theinterface bitmap images.

Figure 9 shows a screenshot of the user interface of the game.

Page 20: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 17

Multi-player, Network-based, 3D Game

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 makesit easy to maintain the code. DirectGraphics and DirectInput of DirectX 8.0a were chosen to be thegraphics and the input API’s, respectively, as DirectX 8.0a provides useful utility functions. Thissaves time in implementing and debugging such functions. In addition, Winsock 2.0 was chosen to bethe 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 fromframe to frame because of visibility constraints. An STL vector data structure was used to storepolygons. If a new polygon that has to be passed into the graphics pipeline is found, it is pushed ontothe end of the vector.

The performance of rendering an octree using this scheme was not satisfactory as the frame rate ofrendering all polygons in the octree root node was lower than that of rendering the corresponding 3Dmodel using an instance of CPRESXMODEL. It was found that it was the great amount of memorymanipulation of the vector that drained performance. When pushing polygons onto the back of thevector, the operating system allocated memory dynamically to the vector so that the vector hadenough space to store the polygons. After rendering the octree, the vector returned all its memory tothe operating system. There was so much expensive memory manipulation within an iteration of thegame loop that performance was adversely affected.

Instead of using an STL vector to store the polygons, a large chunk of memory is statically allocatedfor every octree before the game loop is entered. Every octree has enough memory to store itspolygons that have to be passed into the graphics pipeline. As there is no significant memory

Page 21: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 18

Multi-player, Network-based, 3D Game

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 largeportion or even the whole dynamic object. This results in low efficiency as most polygons of thedynamic object are compared with those in the track octree leaves. The intersection test between thepolygons in the track octree leaves and the node of the dynamic object is performed before testingpolygon-polygon intersection. This approach eliminates some nodes of the dynamic object fromconsideration 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 asphere-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 waschosen so that the sphere could contain the bounding cube of a node. A 2D version illustration isshown below:

Figure 10: Bounding spheres containing bounding cubes

The shaded area is where bounding spheres overlap with each other. Suppose the view frustum onlycontains the lower left bounding box but not the upper bounding box. In other words, only the lowerleft node has to be further processed during visibility determination. If the view frustum intersectswith the shaded area within the lower left node, the upper left bounding sphere will be considered asintersecting the view frustum; hence, the upper left node will be further processed. This wastes muchtime in traversing nodes which are not necessary.

The problem was solved by using the bounding cubes of the nodes instead of the bounding spheres invisibility determination as bounding cubes provide boundaries that are more clear-cut. Nodes that areoutside the view frustum can be determined more quickly and thus there are fewer node traversals. Byusing 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 III1GHz CPU, 256MB RAM, nVidia GeForce2 MX400 with 32MB video memory display card andDirectX 8.0a runtime library.

Page 22: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 19

Multi-player, Network-based, 3D Game

2.3.2 Octree Construction

Efforts were made to output the octree data to a text file so that investigation of the partitioninformation is possible. However, a typical 3D model can be partitioned into hundreds to thousands ofnodes. It is tedious to investigate the correctness of every piece of information inside the text file. Tofacilitate fast testing of the correctness of octree construction, the octree data has to be converted toanother human readable form, which is efficient, complete and clear. The physical meaning of anoctree serves this purpose well: it is a tree of bounding cubes containing polygons. A routine drawingthe bounding cubes of an octree was therefore implemented. Below is a screenshot of the octree of acharacter 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 impliesthat the octree was deeper. Space with no polygons did not have further partitions, which implies thatthe octree reached a leaf quickly at that space. Therefore, the correctness of the octree constructionwas confirmed.

It was found that loading the game was extremely slow because compilation of 3D models intooctrees takes time. The problem is worse if the 3D models are composed of many polygons. It isannoying if players have to wait for several minutes before playing the game. In order to shorten thegame loading time, functions of outputting octree data to a file in binary format and loading binarydata from the file to an octree were implemented. The correctness of such functions was also tested bydrawing the bounding cubes on the screen for observation. The time of loading the game was found toimprove 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 isMagician while the right one is Monster. The first picture shows the beginning status of the characterswhile the other pictures show where Magician stopped when a collision was reported, which wasvisualized as Monster moving backwards. The wireframes represent the bounding boxes of the octreeleaves of the characters.

Page 23: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 20

Multi-player, Network-based, 3D Game

Figure 12: Two characters that are static at the beginning of the test

Figure 13: Maximum depth of octree traversal = 0

Figure 14: Maximum depth of octree traversal = 1

Page 24: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 21

Multi-player, Network-based, 3D Game

Figure 15: Maximum depth of octree traversal = 2

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 thesystem works well if the character just moves forward or backward in a tunnel. However, if acharacter 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 acollision is detected. The character is still able to rotate such that its polygons penetrate into the trackalthough the collision is detected. The angular velocity of the character is therefore inversed to solvethe problem, as shown in the following table:

Page 25: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 22

Multi-player, Network-based, 3D Game

Stage 1 Stage 2

There is a collisiondetected along theexpected movementsof a character.

The angular velocityis 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 inthe final image passing into the graphics pipeline. The performance gained in rendering polygonsshould be greater than the overhead induced by visibility determination so that there is a net gain inthe overall performance. It was found that the overall performance dropped when an octree that issmall enough to be contained in the view frustum intersects with the view frustum. This isunacceptable as fewer polygons were drawn but poorer performance resulted. This implies that theoverhead 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 wasadded to the system. If an octree is a small one, then the system will only check whether the boundingsphere of the octree root node is outside the view frustum. If it is, then no polygons will be passed intothe graphics pipeline; otherwise, all the polygons will be rendered. If an octree is a large one, then thenormal 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 evaluationfrom the public. The game demo, the game description, the game play, details of characters, details ofitems, details of tracks and screenshots of the game demo were included in the homepage. Aquestionnaire was also included to collect suggestions and comments. The things to be evaluatedinclude quality of graphics, speed of the game, gameplay, easy of control and user interface. From theevaluation 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 admittedthat 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.

A track object A track object

Page 26: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 23

Multi-player, Network-based, 3D Game

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 builtto facilitate fast and efficient collision detection and visibility determination, which in turn facilitatesefficient polygon rendering. In addition, by using the game engine implemented, a simple multiplayerrace game was successfully created. The system was able to give correct responses when two entitiesin the virtual world collide with each other. Players can also experience realistic responses when thecontrolled character hits a wall or jumps. The performance of the game was also kept at an acceptablelevel.

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. Onefunctionality that can be added to the game engine is playing sound. If the game plays relevant soundwhen a character hits with another entity in the virtual world, the collision response will be morerealistic.

In this project, animation of characters was achieved by rendering key frames at different times. Inother words, different poses of a character were captured as individual 3D models. Each model wasrendered one by one to achieve the animation effect. Skeletal animation is an alternative to achieveprecise animation. It works by moving one or more parts in the model to obtain different poses thatachieve the animation effect. For example, if it is expected to see a character raising its arm, the key-frame approach is to create some models each of which shows the pose of the character at the timebetween the starting and the stopping of the arm’s motion. This results in several 3D models. If theskeletal animation approach is used, just a single model will be used and the animation effect isachieved 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 drawthe fragments of the exploded bomb. This improves the quality of the graphics and realism of thegame.

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 andthe view frustum. Suppose there are two objects inside the view frustum, one is large while anotherone is small. The small object is behind the large object with respect to the eye point of the viewfrustum. The final image will then be just the large object. Therefore, there is no need to pass thepolygons of the small object into the graphics pipeline. This technique of culling away objects whichare 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 itemsto be created to suit different backgrounds of the tracks. In addition, the condition for a player to wincan be modified by imposing a time limit on the race. Once a character passes through somecheckpoints along a track before the timer expires, the time limit will be expanded. When the timerexpires, the ranking for every character and thus the winner will be determined. This increases thechallenge of the game.

Page 27: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP Final Report 24

Multi-player, Network-based, 3D Game

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 betweenCircles 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

Page 28: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

5.A

ppen

dice

s

App

endi

x A

– K

ey C

ontr

ibut

ions

1.In

divi

dual

Key

Con

trib

utio

ns t

o th

e P

roje

ct

1.1

Key

Con

trib

utio

ns o

f L

ui C

hung

Man

, Cle

men

t

1.1.

1D

esig

n of

Sys

tem

Arc

hite

ctur

e

Thi

s is

impo

rtan

t for

the

corr

ectn

ess

and

the

perf

orm

ance

of

the

gam

e.

1.1.

2G

raph

ics

Eng

ine

Thi

s pa

rt i

nclu

des

impl

emen

tati

on o

f ob

ject

s th

at a

re b

oth

rend

erab

le a

nd n

on-r

ende

rabl

e. I

n ad

diti

on,

visi

bilit

y de

term

inat

ion

is i

nclu

ded.

Thi

s pa

rt i

s im

port

ant

for

visu

aliz

ing

the

stat

e of

the

gam

e an

d fo

rin

tera

ctin

g w

ith p

laye

rs.

1.1.

3O

ctre

e Sy

stem

The

oct

ree

syst

em h

elps

spe

ed u

p co

llisi

on d

etec

tion

and

visi

bilit

y de

term

inat

ion.

It

is t

he m

ain

sour

ceof

per

form

ance

spe

ed u

p in

the

gam

e.

1.1.

4T

imer

Thi

s sy

stem

pro

vide

s pe

rfor

man

ce m

easu

rem

ent

and

sync

hron

izat

ion

on t

he v

eloc

itie

s of

ent

itie

s in

the

virt

ual

wor

ld.

It i

s im

port

ant

in t

he d

evel

opm

ent

of t

he g

ame,

esp

ecia

lly

whe

re p

erfo

rman

ce i

scr

itica

l. In

add

ition

, it p

rovi

des

play

ers

with

ste

ady

mov

emen

t of

char

acte

rs.

1.2

Key

Con

trib

utio

ns o

f F

ong

Heu

ng W

ah

1.2.

1C

ollis

ion

Det

ectio

n an

d C

ollis

ion

Res

pons

es –

Cha

ract

er-T

rack

and

Cha

ract

er-C

hara

cter

Col

lisi

on d

etec

tion

che

cks

whe

ther

tw

o ob

ject

s co

llid

e w

ith

each

oth

er.

Col

lisi

on r

espo

nses

inv

olve

trig

geri

ng d

iffe

rent

kin

ds o

f re

spon

ses

whe

n co

llis

ions

occ

ur.

The

col

lisi

on s

yste

m i

s th

e ba

sis

of r

eal

wor

ld c

ollis

ion

even

ts s

imul

atio

n. I

t m

aint

ains

the

cor

rect

flo

w a

nd i

mpr

oves

the

rea

lism

of

the

raci

ngga

me.

Thi

s pa

rt c

ontr

ibut

es to

mos

t of

the

gam

e lo

gic.

1.2.

2P

hysi

cs

The

phy

sics

sys

tem

sim

ulat

es r

eal

wor

ld p

hysi

cal

effe

cts

such

as

grav

itat

ion

effe

ct a

nd a

ir r

esis

tanc

e.It

impr

oves

the

real

ism

of

the

gam

e.

1.2.

3N

etw

ork

and

Net

wor

k M

essa

ge H

andl

ing

Thi

s pa

rt h

andl

es t

he n

etw

ork

init

iali

zati

on a

nd d

ata

exch

ange

s in

thi

s 4-

play

er n

etw

ork

gam

e. T

his

part

is

indi

spen

sabl

e fo

r a

mul

tipl

ayer

net

wor

k ga

me.

It

mai

ntai

ns t

he s

ynch

roni

zati

on b

etw

een

seve

ral p

laye

r m

achi

nes.

1.2.

4G

eom

etri

c O

bjec

t – C

hara

cter

and

Tra

ck

Thi

s pa

rt s

tore

s th

e in

form

atio

n an

d st

ate

of e

ach

obje

ct a

nd p

rovi

des

oper

atio

ns, s

uch

as m

ove,

jum

pan

d tu

rn, f

or th

e ob

ject

s.

1.2.

53D

Mod

ellin

g

I de

sign

ed s

ome

of t

he tr

acks

, cha

ract

ers

and

item

s an

d cr

eate

d th

e 3D

mod

els

in 3

D S

tudi

o M

ax. T

his

part

pro

vide

s th

e ap

pear

ance

of

each

obj

ect,

whi

ch is

one

of

the

basi

c el

emen

ts f

or a

gam

e.

FYP

Fina

l Rep

ort

i

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

1.3

Key

Con

trib

utio

ns o

f L

au P

ui Y

u

1.3.

1U

ser

Inte

rfac

e D

esig

n

I de

sign

ed a

nd c

reat

ed t

he u

ser

inte

rfac

e of

the

gam

e in

ord

er t

o sh

ow g

ame

info

rmat

ion

for

each

play

er.

The

int

erfa

ce d

ispl

ays

som

e ga

me

info

rmat

ion

incl

udin

g sp

eed,

lap

cou

ntin

g, t

imin

g, l

ocat

ion

and

item

s th

at a

pla

yer

has.

The

use

r in

terf

ace

is e

ssen

tial

to

a pl

ayer

to

mak

e ap

prop

riat

e de

cisi

ons

whe

n pl

ayin

g th

e ga

me.

1.3.

23D

Mod

ellin

g

I de

sign

ed s

ome

of t

he t

rack

s, c

hara

cter

s an

d it

ems

and

crea

ted

the

3D m

odel

s in

3D

Stu

dio

Max

.M

odel

s ar

e th

e ba

sic

elem

ent

for

a 3D

gam

e. T

hey

help

to

impr

ove

the

visu

al q

uali

ty o

f th

e ga

me

envi

ronm

ent.

1.4

Key

Con

trib

utio

ns o

f L

ai M

an T

ing

1.4.

1In

put a

nd I

nput

Res

pons

es

The

inp

ut s

yste

m i

nvol

ves

dete

ctio

n of

key

s pr

esse

d on

the

key

boar

d w

hile

the

inp

ut r

espo

nses

sys

tem

hand

les

the

effe

cts

that

act

on

the

char

acte

rs a

nd i

tem

s. T

he i

nput

sys

tem

per

form

s an

im

port

ant

role

thro

ugho

ut th

e ga

me

as it

is th

e m

ain

chan

nel f

or th

e pl

ayer

to in

tera

ct w

ith th

e ga

me.

1.4.

2G

eom

etri

c O

bjec

t – I

tem

Thi

s pa

rt c

onta

ins

the

func

tion

alit

y of

all

kin

ds o

f it

ems.

The

Geo

met

ric

Obj

ect

syst

em f

or I

tem

incl

udes

the

bas

ic s

etti

ngs

for

all

the

item

s. I

t he

lps

furt

her

deve

lopm

ent

acco

rdin

g to

dif

fere

ntfe

atur

es o

f ea

ch it

em.

1.4.

3C

ollis

ion

Res

pons

es –

Ite

m

Col

lisi

on r

espo

nses

for

Ite

m-C

hara

cter

and

Ite

m-T

rack

are

eff

ects

tha

t ac

t on

bot

h co

llid

ed o

bjec

ts.

Dif

fere

nt i

tem

s in

voke

dif

fere

nt r

espo

nses

to

coll

isio

ns w

ith

the

char

acte

rs a

nd t

he t

rack

. T

his

part

cont

ribu

tes

to th

e ga

me

logi

c.

2.D

epen

denc

y G

raph

of

Key

Con

trib

utio

ns

Page 29: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

ii

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x B

– P

laye

r G

uide

Intr

oduc

tion

Mag

icia

n, R

obot

, Tar

zan

and

Mon

ster

are

com

peti

ng f

or t

he h

onou

r of

“T

he P

rest

issi

mo

in t

heU

nive

rse”

, w

hich

mea

ns t

he f

aste

st m

over

in

the

Uni

vers

e. N

ow,

they

are

pol

ishi

ng t

heir

fav

orit

etr

avel

ing

tool

s to

get

rea

dy f

or th

e co

mpe

titio

ns o

n L

and,

in th

e W

ater

and

in th

e Sk

y.

In t

his

gam

e, y

ou a

re g

oing

to

be o

ne o

f th

e m

entio

ned

char

acte

rs t

o ra

ce o

n th

e tr

acks

on

Lan

d, i

n th

eW

ater

and

in

the

Sky.

Alo

ng e

ach

trac

k, t

here

are

ite

ms

that

eit

her

bene

fit

or h

inde

r yo

u. I

n ad

diti

on,

you

can

keep

som

e ite

ms

and

then

use

them

to h

inde

r ot

her

play

ers.

The

win

ner

is t

he o

ne w

ho w

ins

the

grea

test

num

ber

of r

aces

. If

the

re i

s a

draw

, th

en a

ll p

laye

rs w

ill

play

an

addi

tiona

l tra

ck u

ntil

a w

inne

r ca

n be

det

erm

ined

.

Pla

ying

Pre

stis

sim

o

Sett

ing

up a

gam

e se

ssio

n

Aft

er e

nter

ing

the

gam

e, y

ou w

ill

see

the

mai

n m

enu.

If

you

wan

t to

be

the

serv

er o

f th

is g

ame,

the

nch

oose

“S

etup

Gam

e S

essi

on”.

Aft

er t

hat,

you

have

to

choo

se t

he t

rack

s to

pla

y on

and

ent

er t

henu

mbe

r of

lap

s fo

r ea

ch t

rack

. W

ait

unti

l ot

her

play

ers

join

you

r ga

me

sess

ion.

Whe

n a

play

er j

oins

your

gam

e se

ssio

n, y

ou c

an e

ither

lau

nch

the

gam

e by

pre

ssin

g E

NT

ER

or

wai

t fo

r an

othe

r tw

o pl

ayer

sto

join

. If

you

wan

t to

quit

to th

e m

ain

men

u, p

ress

ESC

AP

E.

Join

ing

a ga

me

sess

ion

If y

ou w

ant

to j

oin

a ga

me

sess

ion

that

is

setu

p so

mew

here

, th

en c

hoos

e “J

oin

Gam

e Se

ssio

n”.

You

wil

l be

pro

mpt

ed t

o en

ter

the

IP a

ddre

ss o

r th

e ho

st n

ame

of t

he g

ame

serv

er.

Aft

er e

nter

ing

it,

the

trac

ks s

elec

ted

by t

he g

ame

serv

er a

nd t

he c

orre

spon

ding

num

ber

of l

aps

wil

l be

dis

play

ed.

Pre

ssE

NTE

R to

con

firm

join

ing

the

gam

e se

ssio

n or

pre

ss E

SCA

PE to

qui

t to

the

mai

n m

enu.

Get

ting

Hel

p

Cho

ose

HE

LP to

che

ck th

e de

faul

t key

boar

d co

nfig

urat

ion

of th

e ga

me.

Pla

ying

the

gam

e

Whe

n a

gam

e se

ssio

n is

lau

nche

d, y

ou w

ill

be d

irec

ted

to t

he f

irst

tra

ck s

elec

ted.

The

fol

low

ing

expl

ains

how

to p

lay

the

gam

e.

Mov

e/C

hang

e D

irec

tion

Use

the

arr

ow k

eys

to t

urn

left

, tu

rn r

ight

, tu

rn u

p or

tur

n do

wn.

Bes

ides

tha

t, th

ere

are

som

e sp

ecia

lm

ovem

ents

in

each

tra

ck. P

ress

“s”

to

jum

p in

the

tra

cks

on L

and

or t

o si

nk i

n th

e W

ater

. Pre

ss “

a” t

oac

cele

rate

and

“z”

to d

ecel

erat

e.

Enc

ount

erin

g It

ems

Alo

ng e

ach

trac

k, t

here

are

dif

fere

nt k

inds

of

item

s th

at i

nter

act

wit

h yo

u. S

ome

item

s be

nefi

t yo

uw

hile

som

e hi

nder

you

. In

add

itio

n, y

ou c

an k

eep

som

e it

ems

and

then

use

the

m t

o hi

nder

oth

erpl

ayer

s.

Ben

efic

ial I

tem

s

Fos

sil F

uel

Whe

n a

play

er a

cqui

res

this

ite

m,

the

play

er w

ill

trav

el f

aste

r th

an o

ther

pla

yers

will

. The

eff

ect w

ill la

st f

or 5

sec

onds

.

FYP

Fina

l Rep

ort

iv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Pro

tect

ive

Shel

lW

hen

a pl

ayer

acq

uire

s th

is i

tem

, th

e pl

ayer

wil

l be

im

mun

e fr

om o

ffen

sive

ite

ms

used

by

othe

r pl

ayer

s. T

he p

rote

ctio

n la

sts

for

10 s

econ

ds.

Milk

Bot

tleT

his

item

incr

ease

s th

e pl

ayer

’s s

peed

for

5 s

econ

ds.

Mot

her

Thi

s it

em p

reve

nts

the

play

er f

rom

bei

ng h

arm

ed b

y of

fens

ive

item

s us

ed b

y ot

her

play

ers

for

8 se

cond

s.

Sash

imi

Play

ers

can

swim

fas

ter

for

5 se

cond

s.

Pro

tect

ive

Net

Pla

yers

wil

l no

t be

aff

ecte

d by

any

har

mfu

l ef

fect

s in

clud

ing

that

fro

m h

inde

ring

item

s an

d of

fens

ive

item

s fo

r 10

sec

onds

.

Roc

ket E

ngin

eIn

crea

ses

the

play

er’s

spe

ed b

y 10

0%. D

urat

ion:

8 s

econ

ds.

Lase

r Sh

ield

Prot

ects

the

play

er f

rom

all

harm

ful e

ffec

ts, i

nclu

ding

that

fro

m h

inde

ring

item

s an

dof

fens

ive

item

s. D

urat

ion:

20

seco

nds.

Hin

deri

ng I

tem

s

Ani

mal

Tra

pT

his

obst

acle

trap

s pl

ayer

s st

eppi

ng o

n it

and

mak

es th

em im

mob

ile f

or 3

sec

onds

.

Roa

dste

rIt

may

com

e fr

om b

ehin

d pl

ayer

s, b

umpi

ng t

hem

and

mak

ing

them

run

slo

wer

for

5se

cond

s.

Shar

kIt

com

es f

rom

beh

ind

play

ers

and

atta

cks

them

, de

crea

sing

the

ir s

peed

for

3se

cond

s.

Bir

d F

eces

Red

uces

a p

laye

r’s

spee

d by

50%

. Dur

atio

n: 1

0 se

cond

s.

Off

ensi

ve I

tem

s

Stra

nge

Flo

wer

If th

is it

em h

its a

vic

tim, t

he v

ictim

will

be

hind

ered

by

a gr

oup

of s

tran

ge f

low

ers.

Seed

T

he f

low

ers

will

last

for

1 s

econ

d.

Cob

raT

he v

ictim

will

be

scre

wed

up

by t

his

snak

e, s

topp

ing

the

play

er f

rom

mov

ing

for

3se

cond

s.

Nee

dles

Thi

s st

abs

play

ers’

fee

t sto

ppin

g th

em f

or 1

sec

ond

if th

ey s

tep

on it

.

Dia

per

Thi

s w

ill s

top

the

vict

im f

or 3

sec

onds

.

Oct

opus

It s

purt

s bl

ack

ink

onto

a p

laye

r, m

akin

g hi

m l

ose

his

dire

ctio

n an

d m

ove

back

war

ds f

or 5

sec

onds

.

Torp

edo

The

vic

tim is

sto

pped

for

3 s

econ

ds.

Trac

ing

Bom

bT

he e

xplo

sion

sto

ps th

e at

tack

ed p

laye

rs f

or 3

sec

onds

.

Typh

oon

Atta

cks

all o

ther

pla

yers

and

cau

ses

them

to lo

se c

ontr

ol. D

urat

ion:

5 s

econ

ds.

Usi

ng O

ffen

sive

Ite

ms

At

the

bott

om o

f th

e sc

reen

, yo

u w

ill

see

a li

st o

f of

fens

ive

item

s yo

u ha

ve c

olle

cted

alo

ng t

he t

rack

.Pr

ess

1, 2

, …

, 5

to u

se i

tem

1,

2, …

, 5.

If

the

item

has

a t

arge

t, th

en y

ou h

ave

to s

peci

fy a

vic

tim

by

pres

sing

1, 2

, 3 o

r 4.

Qui

ttin

g th

e ga

me

To q

uit t

he g

ame,

cho

ose

QU

IT G

AM

E in

the

mai

n m

enu.

Page 30: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

v

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x C

- D

omai

n an

d U

se C

ase

Mod

els

1.D

omai

n M

odel

Eac

h tr

ack

wil

l fe

atur

e th

e cl

asse

s st

ated

bel

ow.

The

cla

ss d

iagr

am s

how

n be

low

can

be

view

ed a

s a

hier

arch

y tr

ee. E

ach

leaf

will

fur

ther

spe

cial

ize

into

dif

fere

nt s

ubcl

asse

s in

eac

h tr

ack.

Det

aile

d cl

asse

sof

item

s, w

hich

are

vis

ible

to p

laye

rs, w

ill b

e de

scri

bed

late

r.

1.1

Com

mon

Cla

ss D

iagr

am

1.2

Com

mon

Cla

ss D

escr

ipti

ons

1.2.

1C

Geo

met

ricO

bjec

t

1.2.

1.1

Des

crip

tion

Thi

s cl

ass

is th

e ba

se c

lass

of

all o

bjec

ts th

at a

re r

ende

rabl

e an

d dr

awab

le o

n th

e sc

reen

.

1.2.

1.2

Attr

ibut

es

1.2.

1.2.

1P

riva

te P

olyg

on m

_pP

olyg

onLi

stT

his

is th

e lis

t of

poly

gons

that

are

to b

e re

nder

ed a

nd d

raw

n on

the

scre

en.

1.2.

1.2.

2P

riva

te P

oint

m_p

tLoc

atio

nT

his

stor

es th

e cu

rren

t loc

atio

n of

the

geom

etri

c ob

ject

in th

e w

orld

.

1.2.

1.2.

3P

riva

te V

ecto

r m

_vtO

rien

tatio

nT

his

stor

es th

e or

ient

atio

n th

e ge

omet

ric

obje

ct is

fac

ing

in th

e w

orld

.

1.2.

2C

Cha

ract

er

1.2.

2.1

Des

crip

tion

Thi

s cl

ass

stor

es in

form

atio

n of

a p

laye

r.

FYP

Fina

l Rep

ort

v

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

1.2.

2.2

Attr

ibut

es

1.2.

2.2.

1P

riva

te F

loat

m_f

Spee

dT

his

stor

es th

e cu

rren

t spe

ed o

f th

e pl

ayer

.

1.2.

2.2.

2P

riva

te C

har

m_c

IDT

his

iden

tifie

s th

e pl

ayer

uni

quel

y in

a m

ultip

laye

r en

viro

nmen

t.

1.2.

2.2.

3P

riva

te O

ffens

ive

m_p

Offe

nsiv

eIte

ms

Thi

s is

the

list o

f of

fens

ive

item

s th

at a

re u

sed

by a

pla

yer

to h

inde

r ot

her

play

ers.

1.2.

3C

Item

1.2.

3.1

Des

crip

tion

Thi

s is

the

cla

ss t

hat

stor

es i

nfor

mat

ion

of a

n it

em t

hat

inte

ract

s w

ith

play

ers.

It

spec

iali

zes

into

CH

inde

ring

, CB

enef

icia

l and

CO

ffens

ive.

1.2.

3.2

Attr

ibut

es

1.2.

3.2.

1P

riva

te I

nteg

er m

_iD

urat

ion

Thi

s de

term

ines

how

long

the

item

will

aff

ect t

he p

laye

rs.

1.2.

4C

Hin

deri

ng

1.2.

4.1

Des

crip

tion

Thi

s cl

ass

of i

tem

s hi

nder

s th

e pl

ayer

s al

ong

the

trac

k of

a r

ace.

It

furt

her

spec

iali

zes

into

CD

ecel

erat

e an

d C

Stop

.

1.2.

5C

Dec

eler

ate

1.2.

5.1

Des

crip

tion

Thi

s cl

ass

of it

ems

mak

es th

e pl

ayer

trav

el s

low

er th

an o

ther

s.

1.2.

5.2

Attr

ibut

es

1.2.

5.2.

1P

riva

te F

loat

m_f

Diff

eren

ceT

his

dete

rmin

es th

e ex

tent

the

play

er is

dec

eler

ated

.

1.2.

6C

Stop

1.2.

6.1

Des

crip

tion

Thi

s cl

ass

of it

ems

stop

s th

e pl

ayer

fro

m m

ovin

g.

1.2.

7C

Ben

efic

ial

1.2.

7.1

Des

crip

tion

Thi

s cl

ass

of i

tem

s be

nefi

ts t

he p

laye

r al

ong

the

trac

k of

a r

ace.

It

furt

her

spec

iali

zes

into

CA

ccel

erat

e an

d C

Pro

tect

ive.

1.2.

8C

Acc

eler

ate

1.2.

8.1

Des

crip

tion

Thi

s cl

ass

of it

ems

mak

es th

e pl

ayer

trav

el f

aste

r th

an o

ther

s.

1.2.

8.2

Attr

ibut

es

1.2.

8.2.

1P

riva

te F

loat

m_f

Diff

eren

ceT

his

dete

rmin

es th

e ex

tent

the

play

er is

acc

eler

ated

.

Page 31: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

vi

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

1.2.

9C

Pro

tect

ive

1.2.

9.1

Des

crip

tion

Thi

s cl

ass

of it

ems

prot

ects

the

play

er f

rom

bei

ng o

ffen

ded

by o

ffen

sive

item

s.

1.2.

10C

Off

ensi

ve

1.2.

10.1

Des

crip

tion

Thi

s is

the

cla

ss o

f it

ems

that

can

be

kept

by

the

play

er a

nd t

hen

used

to

hind

er a

vic

tim

. It

spec

ializ

es in

to C

Avoi

dabl

e an

d C

Non

Avoi

dabl

e.

1.2.

11C

Avo

idab

le

1.2.

11.1

Des

crip

tion

Thi

s is

a c

lass

of

item

s w

hose

eff

ects

may

be

avoi

ded

by a

vic

tim.

1.2.

12C

Non

Avo

idab

le

1.2.

12.1

Des

crip

tion

Thi

s is

a c

lass

of

item

s w

hose

eff

ects

are

not

avo

idab

le i

n an

y ci

rcum

stan

ces

by a

vic

tim

. It

spec

ializ

es in

to C

Sing

le a

nd C

Glo

bal.

1.2.

13C

Sing

le

1.2.

13.1

Des

crip

tion

Thi

s cl

ass

of i

tem

s re

quir

es a

tar

get

vict

im t

o be

sel

ecte

d so

tha

t th

e vi

ctim

wil

l ex

peri

ence

the

effe

cts

of th

e ite

ms.

1.2.

14C

Glo

bal

1.2.

14.1

Des

crip

tion

Thi

s cl

ass

of it

ems

will

aff

ect a

ll ot

her

play

ers

whe

n us

ed b

y a

play

er.

1.3

Item

Des

crip

tion

s fo

r E

ach

Tra

ck

1.3.

1T

rack

1 –

Lan

d

1.3.

1.1

CD

ecel

erat

eN

one

1.3.

1.2

CSt

op

1.3.

1.2.

1C

Ani

mal

Trap

Thi

s ob

stac

le tr

aps

play

ers

step

ping

on

it im

mob

ilizi

ng th

em f

or 3

sec

onds

.

1.3.

1.3

CA

void

able

1.3.

1.3.

1C

Stra

ngeF

low

erSe

edIf

thi

s it

em h

its

a vi

ctim

, th

e vi

ctim

wil

l be

hin

dere

d by

a g

roup

of

stra

nge

flow

ers.

The

flow

ers

will

last

for

1 s

econ

d.

1.3.

1.4

CSi

ngle

1.3.

1.4.

1C

Cob

raT

he v

icti

m w

ill

be s

crew

ed u

p by

thi

s sn

ake,

sto

ppin

g th

e pl

ayer

fro

m m

ovin

g fo

r 3

seco

nds.

1.3.

1.5

CG

loba

lN

one

FYP

Fina

l Rep

ort

viii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

1.3.

1.6

CA

ccel

erat

e

1.3.

1.6.

1C

Fos

silF

uel

Whe

n a

play

er a

cqui

res

this

ite

m,

the

play

er w

ill

trav

el f

aste

r th

an o

ther

pla

yers

wil

l. T

heef

fect

will

last

for

5 s

econ

ds.

1.3.

1.7

CPr

otec

tive

1.3.

1.7.

1C

Pro

tect

iveS

hell

Whe

n a

play

er a

cqui

res

this

ite

m,

the

play

er w

ill

be i

mm

une

from

off

ensi

ve i

tem

s us

ed b

yot

her

play

ers.

The

pro

tect

ion

last

s fo

r 10

sec

onds

.

1.3.

2T

rack

2 –

Gra

nd P

riz

1.3.

2.1

CD

ecel

erat

e

1.3.

2.1.

1C

Roa

dste

rT

he r

oads

ter

may

com

e fr

om b

ehin

d th

e pl

ayer

s bu

mpi

ng t

hem

and

mak

ing

them

run

slow

er f

or 5

sec

onds

.

1.3.

2.2

CSt

opN

one

1.3.

2.3

CA

void

able

1.3.

2.3.

1C

Nee

dles

Thi

s st

abs

play

ers’

foo

t sto

ppin

g th

em f

or 1

sec

ond

if th

ey s

tep

on it

.

1.3.

2.4

CSi

ngle

1.3.

2.4.

1C

Dia

per

Thi

s w

ill s

top

the

vict

im f

or 3

sec

onds

.

1.3.

2.5

CG

loba

lN

one

1.3.

2.6

CA

ccel

erat

e

1.3.

2.6.

1C

Milk

Bot

tleT

his

item

incr

ease

s th

e pl

ayer

’s s

peed

for

5 s

econ

ds.

1.3.

2.7

CPr

otec

tive

1.3.

2.7.

1C

Mot

her

Thi

s it

em p

reve

nts

the

play

er f

rom

bei

ng h

arm

ed b

y of

fens

ive

item

s us

ed b

y ot

her

play

ers

for

8 se

cond

s.

1.3.

3T

rack

3 –

Wat

er

1.3.

3.1

CD

ecel

erat

e

1.3.

3.1.

1C

Shar

kT

he s

hark

atta

cks

play

ers

from

beh

ind

decr

easi

ng th

eir

spee

d fo

r 3

seco

nds.

1.3.

3.2

CSt

opN

one

1.3.

3.3

CA

void

able

1.3.

3.3.

1C

Oct

opus

The

oct

opus

spu

rts

blac

k in

k on

to a

pla

yer

mak

ing

him

los

e hi

s di

rect

ion

and

mov

eba

ckw

ards

for

5 s

econ

ds.

Page 32: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

ix

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

1.3.

3.4

CSi

ngle

1.3.

3.4.

1C

Torp

edo

The

vic

tim is

sto

pped

for

3 s

econ

ds.

1.3.

3.5

CG

loba

lN

one

1.3.

3.6

CA

ccel

erat

e

1.3.

3.6.

1C

Sash

imi

Play

ers

can

swim

fas

ter

for

5 se

cond

s.

1.3.

3.7

CPr

otec

tive

1.3.

3.7.

1C

Pro

tect

iveN

etPl

ayer

s w

ill

not

be a

ffec

ted

by a

ny h

arm

ful

effe

cts

incl

udin

g th

at f

rom

hin

deri

ng i

tem

s an

dof

fens

ive

item

s fo

r 10

sec

onds

.

1.3.

4T

rack

4 –

Sky

1.3.

4.1

CD

ecel

erat

e

1.3.

4.1.

1C

Bir

dFec

esR

educ

es a

pla

yer’

s sp

eed

by 5

0%. D

urat

ion:

10

seco

nds.

1.3.

4.2

CSt

opN

one

1.3.

4.3

CA

void

able

Non

e

1.3.

4.4

CSi

ngle

1.3.

4.4.

1C

Trac

ingB

omb

The

exp

losi

on s

tops

the

atta

cked

pla

yers

for

3 s

econ

ds.

1.3.

4.5

CG

loba

l

1.3.

4.5.

1C

Typh

oon

Atta

cks

all o

ther

pla

yers

and

cau

ses

them

to lo

se c

ontr

ol. D

urat

ion:

5 s

econ

ds.

1.3.

4.6

CA

ccel

erat

e

1.3.

4.6.

1C

Roc

ketE

ngin

eIn

crea

ses

the

play

er’s

spe

ed b

y 10

0%. D

urat

ion:

8 s

econ

ds.

1.3.

4.7

CPr

otec

tive

1.3.

4.7.

1C

Lase

rShi

eld

Pro

tect

s th

e pl

ayer

fro

m a

ll h

arm

ful

effe

cts,

inc

ludi

ng t

hat

from

hin

deri

ng i

tem

s an

dof

fens

ive

item

s. D

urat

ion:

20

seco

nds.

FYP

Fina

l Rep

ort

x

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.U

se C

ase

Mod

el

A u

se c

ase

is a

fun

ctio

n pr

ovid

ed b

y a

syst

em t

hat

yiel

ds a

vis

ible

res

ult

for

acto

rs. I

n th

is g

ame,

the

rear

e th

ree

kind

s of

act

ors:

Pla

yer,

Serv

er P

laye

r an

d C

lien

t Pl

ayer

, in

whi

ch P

laye

r sp

ecia

lize

s in

to t

hela

tter

tw

o. I

n ad

diti

on,

ther

e ar

e to

tall

y 12

use

cas

es,

i.e.,

oper

atio

ns f

or t

he p

laye

rs.

Som

e op

erat

ions

are

avai

labl

e fo

r al

l tr

acks

whi

le s

ome

are

for

a sp

ecif

ic t

rack

onl

y; s

ome

oper

atio

ns h

ave

to b

e do

nebe

fore

pla

ying

the

gam

e w

hile

oth

ers

cons

titut

e th

e ga

me

play

.

2.1

Syst

em U

se C

ases

2.1.

1H

elp

Thi

s us

e ca

se s

how

s ho

w a

pla

yer

asks

the

sys

tem

for

the

rul

es o

f th

e ga

me

and

how

to

cont

rol

the

char

acte

r as

sign

ed to

them

.

2.1.

1.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.1.

1.2

Prec

ondi

tions

The

Pla

yer

is a

lrea

dy in

the

mai

n m

enu

of th

e ga

me.

2.1.

1.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

sel

ects

the

optio

n –

Hel

p.2.

T

he s

yste

m d

ispl

ays

the

rule

s of

the

gam

e an

d th

e de

faul

t key

boar

d co

nfig

urat

ion.

3.

The

sys

tem

wai

ts f

or t

he P

laye

r to

sel

ect

the

opti

on t

o qu

it t

o th

e m

ain

men

u of

the

gam

e.4.

T

he u

se c

ase

ends

.

2.1.

1.4

Subf

low

sN

one

2.1.

1.5

Alte

rnat

e Pa

ths

Non

e

2.1.

1.6

Post

Con

ditio

nsT

he P

laye

r is

dir

ecte

d to

the

mai

n m

enu

of th

e ga

me.

2.1.

2Se

tup

Gam

e Se

ssio

n

Thi

s us

e ca

se s

how

s ho

w a

pla

yer

sets

up

a ga

me

serv

er to

cre

ate

a m

ultip

laye

r en

viro

nmen

t.

2.1.

2.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by S

erve

r Pl

ayer

.

2.1.

2.2

Prec

ondi

tions

The

Ser

ver

Play

er is

alr

eady

in th

e m

ain

men

u of

the

gam

e.

2.1.

2.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Se

rver

Pla

yer

sele

cts

the

optio

n –

Setu

p G

ame

Sess

ion.

2.

The

sys

tem

pro

mpt

s th

e S

erve

r P

laye

r to

sel

ect

the

trac

ks a

mon

g th

e fo

ur t

rack

spr

ovid

ed.

3.

The

Ser

ver

Play

er s

elec

ts th

e tr

acks

to p

lay

on.

4.

The

sys

tem

pro

mpt

s th

e S

erve

r P

laye

r to

ent

er t

he n

umbe

r of

lap

s fo

r ea

ch t

rack

sele

cted

.5.

T

he S

erve

r Pl

ayer

ent

ers

the

num

ber

of la

ps f

or e

ach

trac

k se

lect

ed.

6.

The

Ser

ver

Play

er i

s as

sign

ed a

par

ticu

lar

char

acte

r an

d is

pro

mpt

ed t

o w

ait

for

Cli

ent

Play

ers

to j

oin

this

gam

e se

ssio

n un

til h

e w

ants

to

quit

or t

he n

umbe

r of

pla

yers

rea

ches

the

max

imum

or

he c

hoos

es th

e op

tion

to la

unch

the

gam

e. (

A1)

7.

The

use

cas

e en

ds.

Page 33: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

x

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.1.

2.4

Subf

low

sN

one

2.1.

2.5

Alte

rnat

e Pa

ths

A1:

If n

o C

lient

Pla

yers

hav

e jo

ined

the

gam

e an

d th

e Se

rver

Pla

yer

choo

ses

to l

aunc

h th

ega

me,

an

erro

r m

essa

ge w

ill

be p

rint

ed o

n th

e sc

reen

and

the

sys

tem

wil

l re

turn

to

step

6 o

f th

e B

asic

Pat

h.

2.1.

2.6

Post

Con

ditio

nsT

he S

erve

r P

laye

r is

dir

ecte

d ei

ther

to

the

mai

n m

enu

of t

he g

ame

or t

o th

e st

art

of t

hega

me.

2.1.

3Jo

in G

ame

Sess

ion

Thi

s us

e ca

se s

how

s ho

w a

pla

yer

conn

ects

to a

gam

e se

rver

to p

lay

the

gam

e.

2.1.

3.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by C

lient

Pla

yer.

2.1.

3.2

Prec

ondi

tions

The

Clie

nt P

laye

r is

alr

eady

in th

e m

ain

men

u of

the

gam

e.

2.1.

3.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e C

lient

Pla

yer

choo

ses

the

optio

n –

Join

Gam

e Se

ssio

n.2.

T

he s

yste

m p

rom

pts

the

Cli

ent

Pla

yer

to e

nter

the

IP

addr

ess/

host

nam

e of

the

gam

ese

rver

. (A

1)3

. T

he s

yste

m d

ispl

ays

the

trac

ks a

nd t

he c

orre

spon

ding

num

ber

of l

aps

chos

en b

y th

eSe

rver

Pla

yer

of t

he g

ame

serv

er.

The

sys

tem

pro

mpt

s th

e C

lien

t Pl

ayer

to

conf

irm

to

join

this

gam

e se

ssio

n.4.

T

he C

lient

Pla

yer

conf

irm

s to

join

this

gam

e se

ssio

n.5

. T

he C

lien

t P

laye

r is

ass

igne

d a

part

icul

ar c

hara

cter

and

is

prom

pted

to

wai

t fo

r th

eSe

rver

Pla

yer

to la

unch

the

gam

e un

til h

e w

ants

to q

uit.

6.

The

use

cas

e en

ds.

2.1.

3.4

Subf

low

sN

one

2.1.

3.5

Alte

rnat

e Pa

ths

A1:

If t

he s

erve

r w

ith

the

ente

red

IP a

ddre

ss/h

ost

nam

e ca

nnot

be

reac

hed,

an

erro

rm

essa

ge w

ill

be p

rint

ed a

nd t

he C

lien

t P

laye

r is

pro

mpt

ed t

o en

ter

a va

lid

IPad

dres

s/ho

st n

ame

or to

term

inat

e th

e us

e ca

se.

2.1.

3.6

Post

Con

ditio

nsT

he C

lient

Pla

yer

is d

irec

ted

eith

er to

the

mai

n m

enu

or to

the

star

t of

the

gam

e.

2.1.

4Q

uit G

ame

Thi

s us

e ca

se s

how

s ho

w th

e Pl

ayer

qui

ts th

e ga

me.

2.1.

4.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.1.

4.2

Prec

ondi

tions

The

Pla

yer

is a

lrea

dy in

the

mai

n m

enu

of th

e ga

me.

2.1.

4.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Qui

t Gam

e.2.

T

he s

yste

m r

elea

ses

all r

esou

rces

acq

uire

d.3.

T

he u

se c

ase

ends

.

FYP

Fina

l Rep

ort

xi

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.1.

4.4

Subf

low

sN

one

2.1.

4.5

Alte

rnat

e Pa

ths

Non

e

2.1.

4.6

Post

Con

ditio

nsT

he g

ame

shut

s do

wn.

Page 34: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xiii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.2

Com

mon

Tra

ck U

se C

ases

2.2.

1A

ccel

erat

e

Thi

s us

e ca

se s

how

s ho

w p

laye

rs a

ccel

erat

e th

eir

char

acte

rs.

2.2.

1.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.2.

1.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.2.

1.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Acc

eler

ate.

2.

The

sys

tem

incr

ease

s th

e Pl

ayer

’s s

peed

by

a pa

rtic

ular

am

ount

. (A

1)3.

T

he s

yste

m r

ende

rs th

e up

date

d ch

arac

ter.

4.

The

use

cas

e en

ds.

2.2.

1.4

Subf

low

sN

one

2.2.

1.5

Alte

rnat

e Pa

ths

A1:

If t

he i

ncre

ased

spe

ed o

f th

e Pl

ayer

exc

eeds

the

max

imum

spe

ed a

llow

ed, t

he s

peed

is

trun

cate

d to

the

max

imum

spe

ed a

llow

ed.

2.2.

1.6

Post

Con

ditio

nsN

one

2.2.

2D

ecel

erat

e

Thi

s us

e ca

se s

how

s ho

w p

laye

rs d

ecel

erat

e th

eir

char

acte

rs.

2.2.

2.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.2.

2.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.2.

2.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Dec

eler

ate.

2.

The

sys

tem

dec

reas

es th

e Pl

ayer

’s s

peed

by

a pa

rtic

ular

am

ount

. (A

1)3.

T

he s

yste

m r

ende

rs th

e up

date

d ch

arac

ter.

4.

The

use

cas

e en

ds.

2.2.

2.4

Subf

low

sN

one

2.2.

2.5

Alte

rnat

e Pa

ths

A1:

If t

he d

ecre

ased

spe

ed o

f th

e Pl

ayer

exc

eeds

the

min

imum

spe

ed a

llow

ed, t

he s

peed

is

trun

cate

d to

the

min

imum

spe

ed a

llow

ed.

2.2.

2.6

Post

Con

ditio

nsN

one

2.2.

3C

hang

e O

rien

tatio

n

Thi

s us

e ca

se s

how

s ho

w p

laye

rs c

hang

e th

eir

orie

ntat

ion.

2.2.

3.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

FYP

Fina

l Rep

ort

xiv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.2.

3.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.2.

3.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Cha

nge

Ori

enta

tion.

2.

The

sys

tem

cha

nges

the

Play

er’s

ori

enta

tion

by a

par

ticul

ar v

alue

of

degr

ees.

3.

The

sys

tem

ren

ders

the

upda

ted

char

acte

r.4.

T

he u

se c

ase

ends

.

2.2.

3.4

Subf

low

sN

one

2.2.

3.5

Alte

rnat

e Pa

ths

Non

e

2.2.

3.6

Post

Con

ditio

nsN

one

2.2.

4.U

se O

ffen

sive

Ite

ms

Thi

s us

e ca

se s

how

s ho

w a

pla

yer

uses

off

ensi

ve it

ems

to h

inde

r ot

her

play

ers.

2.2.

4.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.2.

4.2

Prec

ondi

tions

The

Pla

yer

is a

lrea

dy in

the

gam

e an

d th

e Pl

ayer

alr

eady

pos

sess

es a

t lea

st o

ne it

em.

2.2.

4.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

offe

nsiv

e ite

m to

use

. (A

1)2.

T

he s

yste

m p

rom

pts

the

Play

er to

spe

cify

the

vict

im if

the

item

is C

Sing

le.

3.

The

item

is tr

igge

red

by th

e Pl

ayer

.4.

T

he it

em e

xhib

its it

s ef

fect

. (A

1)5.

T

he u

se c

ase

ends

.

2.2.

4.4

Subf

low

sN

one

2.2.

4.5

Alte

rnat

e Pa

ths

A1:

If t

he v

icti

m i

s pr

otec

ted

by C

Prot

ecti

ve i

tem

s, t

hen

the

vict

im i

s no

t af

fect

ed b

y th

eof

fens

ive

item

.

2.2.

4.6

Post

Con

ditio

nsN

one

Page 35: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.3

Use

Cas

es f

or T

rack

1 &

2 –

Lan

d &

Gra

nd P

riz

2.3.

1.Ju

mp

Thi

s us

e ca

se s

how

s ho

w p

laye

rs ju

mp

2.3.

1.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.3.

1.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.3.

1.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Jum

p.2.

T

he s

yste

m tr

ansl

ates

the

Play

er’s

pos

ition

up

by a

par

ticul

ar a

mou

nt.

3.

The

sys

tem

tran

slat

es th

e Pl

ayer

’s p

ositi

on d

own

to th

e gr

ound

aft

er s

ome

time.

4.

The

sys

tem

ren

ders

the

upda

ted

char

acte

r.5.

T

he u

se c

ase

ends

.

2.3.

1.4

Subf

low

sN

one

2.3.

1.5

Alte

rnat

e Pa

ths

Non

e

2.3.

1.6

Post

Con

ditio

nsN

one

FYP

Fina

l Rep

ort

xvi

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.4

Use

Cas

es f

or T

rack

3 –

Wat

er

2.4.

1.Si

nk

Thi

s us

e ca

se s

how

s ho

w p

laye

rs s

ink

tem

pora

rily

in w

ater

.

2.4.

1.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.4.

1.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.4.

1.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Sink

.2.

T

he s

yste

m tr

ansl

ates

the

Play

er’s

pos

ition

dow

n by

a p

artic

ular

am

ount

.3.

T

he s

yste

m tr

ansl

ates

the

Play

er’s

pos

ition

up

to th

e w

ater

leve

l aft

er s

ome

time.

4.

The

sys

tem

ren

ders

the

upda

ted

char

acte

r.5.

T

he u

se c

ase

ends

.

2.4.

1.4

Subf

low

sN

one

2.4.

1.5

Alte

rnat

e Pa

ths

Non

e

2.4.

1.6

Post

Con

ditio

nsN

one

Page 36: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xvi

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.5

Use

Cas

es f

or T

rack

4 –

Sky

2.5.

1.F

ly

Thi

s us

e ca

se s

how

s ho

w p

laye

rs f

ly in

the

sky.

2.5.

1.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.5.

1.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.5.

1.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Fly.

2.

The

sys

tem

tran

slat

es th

e Pl

ayer

’s p

ositi

on u

p by

a p

artic

ular

am

ount

.3.

T

he s

yste

m r

ende

rs th

e up

date

d ch

arac

ter.

4.

The

use

cas

e en

ds.

2.5.

1.4

Subf

low

sN

one

2.5.

1.5

Alte

rnat

e Pa

ths

Non

e

2.5.

1.6

Post

Con

ditio

nsN

one

2.5.

2.L

and

Thi

s us

e ca

se s

how

s ho

w p

laye

rs la

nd f

rom

the

sky.

2.5.

2.1

Act

ors

Thi

s us

e ca

se is

invo

ked

by P

laye

r.

2.5.

2.2

Prec

ondi

tions

The

gam

e ha

s al

read

y st

arte

d.

2.5.

2.3

Bas

ic P

ath

1.

The

use

cas

e st

arts

whe

n th

e Pl

ayer

cho

oses

the

optio

n –

Lan

d.2.

T

he s

yste

m tr

ansl

ates

the

Play

er’s

pos

ition

dow

n by

a p

artic

ular

am

ount

.3.

T

he s

yste

m r

ende

rs th

e up

date

d ch

arac

ter.

4.

The

use

cas

e en

ds.

2.5.

2.4

Subf

low

sN

one

2.5.

2.5

Alte

rnat

e Pa

ths

Non

e

2.5.

2.6

Post

Con

ditio

nsN

one

FYP

Fina

l Rep

ort

xviii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x D

– A

naly

sis

Mod

el

1Sy

stem

Arc

hite

ctur

e

Sin

ce a

gam

e is

a r

eal-

tim

e sy

stem

, it

has

to

chec

k w

hat

the

play

er i

nput

s an

d up

date

the

scr

een

imm

edia

tely

. To

ach

ieve

thi

s, t

he e

asie

st w

ay i

s to

org

aniz

e al

l th

e w

ork

in a

loo

p in

whi

ch e

ach

iter

atio

n pr

epar

es a

fra

me

to b

e dr

awn

on t

he s

cree

n. T

he f

ollo

win

g sh

ows

how

the

wor

k is

org

aniz

edin

side

a lo

op: A

. C

lear

Dra

win

g B

uffe

rsB

. C

heck

Inp

utC

. In

put R

espo

nses

D.

Ani

mat

e O

bjec

tsE

. G

ravi

ty R

espo

nses

F.

Col

lisio

n D

etec

tion

G.

Col

lisio

n R

espo

nses

H.

Rec

eive

and

Pro

cess

Net

wor

k Pa

cket

sI.

Send

Cur

rent

Sta

te &

Eve

nts

of L

ast F

ram

eJ.

V

isib

ility

Det

erm

inat

ion

and

Ren

der

3DK

. D

raw

2D

L.

Swap

Buf

fers

The

gam

e lo

op r

esul

ts in

the

follo

win

g sy

stem

arc

hite

ctur

e:

Page 37: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xix

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2G

ame

Eng

ine

2.1

Col

lisio

n D

etec

tion

2.1.

1C

lass

Dia

gram

2.1.

2C

lass

Des

crip

tions

2.1.

2.1

CPr

esC

ollis

ionD

etec

tionM

grT

his

clas

s co

ntai

ns t

he c

olli

sion

det

ecti

on r

outi

ne t

hat

dete

rmin

es w

hich

pai

rs o

f ob

ject

sco

llide

and

the

pair

s of

inte

rsec

ting

tria

ngle

s.

2.1.

2.2

CPr

esC

ollis

ionG

roup

Thi

s cl

ass

keep

s a

list o

f ob

ject

s in

the

scen

e th

at m

ay c

ollid

e w

ith e

ach

othe

r.

2.2

Ren

dera

ble

Gra

phic

s O

bjec

ts

2.2.

1C

lass

Dia

gram

FYP

Fina

l Rep

ort

xx

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.2.

2C

lass

Des

crip

tions

2.2.

2.1

CPr

esG

eoO

bjec

tT

his

is th

e in

terf

ace

of th

e fu

ndam

enta

l cla

ss in

the

grap

hics

eng

ine.

2.2.

2.2

CPr

esPr

imiti

veT

his

is th

e in

terf

ace

of th

e fu

ndam

enta

l 3D

obj

ect i

n th

e gr

aphi

cs e

ngin

e.

2.2.

2.3

CPr

esB

itmap

Thi

s cl

ass

man

ages

info

rmat

ion

stor

ed in

a b

itmap

imag

e.

2.2.

2.4

CPr

esX

Mod

elT

his

clas

s m

anag

es a

n ex

tern

al 3

D m

odel

that

is e

ncod

ed in

Mic

roso

ft D

irec

tX F

ile F

orm

at.

2.3

Non

-Ren

dera

ble

Gra

phic

s O

bjec

ts

2.3.

1C

lass

Dia

gram

2.3.

2C

lass

Des

crip

tions

2.3.

2.1

CPr

esC

oord

Fram

eT

his

clas

s m

anag

es c

oord

inat

e fr

ame

info

rmat

ion

such

as

posi

tion

, or

ient

atio

n an

dtr

ansf

orm

atio

n of

an

obje

ct in

the

scen

e.

2.3.

2.2

CPr

esL

ight

Fram

eT

his

clas

s m

anag

es c

oord

inat

e fr

ame

info

rmat

ion

spec

ific

ally

for

ligh

t sou

rces

.

2.3.

2.3

CPr

esC

amer

aFra

me

Thi

s cl

ass

man

ages

coo

rdin

ate

fram

e in

form

atio

n sp

ecif

ical

ly f

or c

amer

a.

Page 38: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xxi

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.3.

2.4

CPr

esPr

imiti

veFr

ame

Thi

s cl

ass

man

ages

coo

rdin

ate

fram

e in

form

atio

n sp

ecif

ical

ly f

or p

rim

itive

s.

2.3.

2.5

CPr

esG

eom

etri

cObj

ect

Thi

s cl

ass

man

ages

an

obje

ct’s

geo

met

ric

info

rmat

ion.

2.3.

2.6

CPr

esO

ctre

eRen

dere

rT

his

clas

s co

ntai

ns th

e ro

utin

e of

ren

deri

ng a

n oc

tree

.

2.3.

2.7

CPr

esO

ctre

eCom

pile

rT

his

clas

s co

ntai

ns th

e ro

utin

e of

bui

ldin

g an

oct

ree.

2.3.

2.8

CPr

esM

ater

ial

Thi

s cl

ass

man

ages

info

rmat

ion

of m

ater

ials

and

text

ures

.

2.3.

2.9

CPr

esR

ende

rDev

iceM

grT

his

clas

s en

caps

ulat

es f

unct

iona

liti

es o

f in

itia

liza

tion

of

and

rele

asin

g re

sour

ces

acqu

ired

by D

irec

t3D

.

2.3.

2.10

CPr

esC

amer

aT

his

clas

s en

caps

ulat

es th

e vi

ew m

atri

x.

2.3.

2.11

CPr

esFo

ntE

ngin

eT

his

clas

s is

res

pons

ible

for

ren

deri

ng 2

D b

itmap

fon

ts.

2.3.

2.12

CPr

esL

ight

Thi

s cl

ass

man

ages

info

rmat

ion

of a

ligh

t sou

rce.

2.3.

2.13

SPre

sBou

ndin

gBox

Thi

s is

the

data

str

uctu

re o

f a

boun

ding

box

.

2.3.

2.14

SPre

sOct

ree

Thi

s is

the

data

str

uctu

re o

f an

oct

ree.

2.3.

2.15

SPre

sOct

reeN

ode

Thi

s is

the

data

str

uctu

re o

f an

oct

ree

node

.

2.4

Tim

er

2.4.

1C

lass

Des

crip

tions

2.4.

1.1

CPr

esT

imer

Thi

s cl

ass

enca

psul

ates

the

fun

ctio

nali

ties

pro

vide

d by

the

hig

h pr

ecis

ion

64-b

it h

ardw

are

timer

.

2.5

Inpu

t

2.5.

1C

lass

Des

crip

tions

2.5.

1.1

CPr

esIn

put

Thi

s cl

ass

enca

psul

ates

the

func

tiona

litie

s pr

ovid

ed b

y D

irec

tInp

ut.

2.6

Phy

sics

2.6.

1C

lass

Des

crip

tions

2.6.

1.1

CPr

esPh

ysic

sMgr

Thi

s cl

ass

cont

ains

the

phys

ics

rout

ines

to a

pply

gra

vity

on

geom

etri

c ob

ject

s.

FYP

Fina

l Rep

ort

xxi

i

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

2.7

Net

wor

king

2.7.

1C

lass

Des

crip

tions

2.7.

1.1

CPr

esN

etw

ork

Thi

s cl

ass

enca

psul

ates

the

func

tiona

litie

s pr

ovid

ed b

y W

inso

ck.

Page 39: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xxiii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

3.G

ame

Cod

e

3.1

Obj

ect

Ani

mat

ion

3.1.

1C

lass

Des

crip

tions

3.1.

1.1

CO

bjec

tAni

mat

orT

his

clas

s m

anag

es th

e an

imat

ion

stat

e of

geo

met

ric

obje

cts

in th

e sc

ene.

3.2

Col

lisio

n R

espo

nses

3.2.

1C

lass

Des

crip

tions

3.2.

1.1

CC

ollis

ionR

espo

nses

Mgr

Thi

s cl

ass

is r

espo

nsib

le f

or i

nvok

ing

colli

sion

res

pons

e ro

utin

es o

f ge

omet

ric

obje

cts

in t

hesc

ene.

3.2.

2C

olla

bora

tion

Dia

gram

1.

The

Sys

tem

ask

s C

Col

lisio

nRes

pons

esM

gr to

upd

ate

the

stat

e of

geo

met

ric

obje

cts.

2.

The

CC

ollis

ionR

espo

nses

Mgr

ask

s C

Pres

Col

lisio

nDet

ectio

nMgr

to r

etur

n a

list o

f ob

ject

sin

col

lisio

n an

d th

e in

ters

ectin

g tr

iang

les

for

each

pai

r.2.

1 T

he C

Pres

Col

lisio

nDet

ectio

nMgr

ask

s C

Pres

Col

lisio

nGro

up to

ret

urn

geom

etri

cob

ject

s re

peat

edly

for

eac

h co

llisi

on g

roup

.2.

2 T

he C

Pres

Col

lisio

nDet

ectio

nMgr

che

cks

for

obje

cts

in c

ollis

ion

and

dete

rmin

e th

ein

ters

ectin

g tr

iang

les.

3.

If a

col

lisio

n pa

ir c

onta

ins

an it

em, C

Col

lisio

nRes

pons

esM

gr g

ets

the

attr

ibut

e va

lues

fro

mth

at it

em a

nd u

pdat

e th

e st

ate

of th

e ite

m.

4.

The

CC

ollis

ionR

espo

nses

Mgr

ask

s C

Cha

ract

er to

upd

ate

its s

tate

s su

ch a

s po

sitio

n,or

ient

atio

n an

d an

imat

ion.

FYP

Fina

l Rep

ort

xxiv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

3.3

Geo

met

ric

Obj

ects

3.3.

1C

lass

Dia

gram

3.3.

2.C

lass

Des

crip

tions

3.3.

2.1

CG

eom

etri

cObj

ectM

grT

his

clas

s is

res

pons

ible

for

cre

atin

g an

d de

stro

ying

all

obje

cts

in th

e sc

ene.

3.3.

2.2

CG

eom

etri

cObj

ect

Thi

s cl

ass

is th

e ba

se c

lass

of

all o

bjec

ts in

the

scen

e. I

t con

tain

s in

form

atio

n di

rect

ly r

elat

edto

the

gam

e pl

ay.

3.3.

2.3

CC

hara

cter

Thi

s cl

ass

stor

es in

form

atio

n of

a c

hara

cter

.

3.3.

2.4

CIt

emT

his

clas

s st

ores

inf

orm

atio

n of

an

item

tha

t in

tera

cts

wit

h pl

ayer

s. I

t sp

ecia

lize

s in

toC

Hin

deri

ng, C

Ben

efic

ial a

nd C

Off

ensi

ve.

3.3.

2.5

CH

inde

ring

Thi

s cl

ass

of i

tem

s hi

nder

s th

e pl

ayer

s al

ong

the

trac

k of

a r

ace.

It

furt

her

spec

iali

zes

into

CD

ecel

erat

e an

d C

Stop

.

3.3.

2.6

CD

ecel

erat

eT

his

clas

s of

item

s m

akes

the

play

ers

trav

el s

low

er th

an o

ther

s.

3.3.

2.7

CSt

opT

his

clas

s of

item

s st

ops

the

play

er f

rom

mov

ing.

3.3.

2.8

CB

enef

icia

lT

his

clas

s of

ite

ms

bene

fits

the

pla

yers

alo

ng t

he t

rack

of

a ra

ce.

It f

urth

er s

peci

aliz

es i

nto

Page 40: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xxv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

CA

ccel

erat

e an

d C

Prot

ectiv

e.

3.3.

2.9

CA

ccel

erat

eT

his

clas

s of

item

s m

akes

the

play

ers

trav

el f

aste

r th

an o

ther

s.

3.3.

2.10

CPr

otec

tive

Thi

s cl

ass

of it

ems

prot

ects

the

play

ers

from

bei

ng o

ffen

ded

by o

ffen

sive

item

s.

3.3.

2.11

CO

ffen

sive

Thi

s cl

ass

of it

ems

can

be k

ept b

y th

e pl

ayer

s an

d th

en u

sed

to h

inde

r a

vict

im. I

t spe

cial

izes

into

CA

void

able

and

CN

onA

void

able

.

3.3.

2.12

CA

void

able

Thi

s is

a c

lass

of

item

s w

hose

eff

ects

may

be

avoi

ded

by a

vic

tim.

3.3.

2.13

CN

onA

void

able

Thi

s is

a c

lass

of

item

s w

hose

eff

ects

are

not

avo

idab

le i

n an

y ci

rcum

stan

ces

by a

vic

tim

. It

spec

ializ

es in

to C

Sing

le a

nd C

Glo

bal.

3.3.

2.14

CSi

ngle

Thi

s cl

ass

of i

tem

s re

quir

es a

tar

get

vict

im t

o be

sel

ecte

d so

tha

t th

e vi

ctim

wil

l ex

peri

ence

the

effe

cts

of th

e ite

ms.

3.3.

2.15

CG

loba

lT

his

clas

s of

item

s w

ill a

ffec

t all

othe

r pl

ayer

s w

hen

used

by

a pl

ayer

.

3.3.

2.16

CA

nim

alTr

apT

his

obst

acle

trap

s pl

ayer

s st

eppi

ng o

n it

and

mak

es th

em im

mob

ile f

or 3

sec

onds

.

3.3.

2.17

CSt

rang

eFlo

wer

Seed

If t

his

item

hit

s a

vict

im,

the

vict

im w

ill

be h

inde

red

by a

gro

up o

f st

rang

e fl

ower

s. T

hefl

ower

s w

ill la

st f

or 1

sec

ond.

3.3.

2.18

CC

obra

The

vic

tim

wil

l be

scr

ewed

up

by t

his

snak

e, s

topp

ing

the

play

er f

rom

mov

ing

for

3se

cond

s.

3.3.

2.19

CFo

ssilF

uel

Whe

n a

play

er a

cqui

res

this

ite

m,

the

play

er w

ill

trav

el f

aste

r th

an o

ther

pla

yers

wil

l. T

heef

fect

will

last

for

5 s

econ

ds.

3.3.

2.20

CPr

otec

tiveS

hell

Whe

n a

play

er a

cqui

res

this

ite

m,

the

play

er w

ill

be i

mm

une

from

off

ensi

ve i

tem

s us

ed b

yot

her

play

ers.

The

pro

tect

ion

last

s fo

r 10

s.

3.3.

2.21

CR

oads

ter

It m

ay c

ome

from

the

bac

k of

the

pla

yers

, bu

mpi

ng t

hem

and

mak

e th

em r

un s

low

er f

or 5

seco

nds.

3.3.

2.22

CN

eedl

esT

his

stab

s pl

ayer

s’ f

oot s

topp

ing

them

for

1 s

econ

d if

they

ste

p on

it.

3.3.

2.23

CD

iape

rT

his

will

sto

p th

e vi

ctim

for

3 s

econ

ds.

3.3.

2.24

CM

ilkB

ottle

Thi

s ite

m in

crea

ses

the

play

er’s

spe

ed f

or 5

sec

onds

.

3.3.

2.25

CM

othe

rT

his

item

pre

vent

s th

e pl

ayer

fro

m b

eing

har

med

by

offe

nsiv

e it

ems

used

by

othe

r pl

ayer

s

FYP

Fina

l Rep

ort

xxvi

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

for

8 se

cond

s.

3.3.

2.26

CSh

ark

It c

omes

fro

m th

e ba

ck o

f pl

ayer

s an

d at

tack

s th

em, d

ecre

asin

g th

eir

spee

d fo

r 3

seco

nds.

3.3.

2.27

CO

ctop

usIt

spu

rts

blac

k in

k on

to a

pla

yer,

mak

ing

him

los

e hi

s di

rect

ion

and

mov

e ba

ckw

ards

for

5se

cond

s.

3.3.

2.28

CTo

rped

oT

he v

ictim

is s

topp

ed f

or 3

sec

onds

.

3.3.

2.29

CSa

shim

iPl

ayer

s ca

n sw

im f

aste

r fo

r 5

seco

nds.

3.3.

2.30

CPr

otec

tiveN

etPl

ayer

s w

ill

not

be a

ffec

ted

by a

ny h

arm

ful

effe

cts

incl

udin

g th

at f

rom

hin

deri

ng i

tem

s an

dof

fens

ive

item

s fo

r 10

sec

onds

.

3.3.

2.31

CB

irdF

eces

Red

uces

a p

laye

r’s

spee

d by

50%

. Dur

atio

n: 1

0 se

cond

s.

3.3.

2.32

CT

raci

ngB

omb

The

exp

losi

on s

tops

the

atta

cked

pla

yers

for

3 s

econ

ds.

3.3.

2.33

CTy

phoo

nA

ttack

s al

l oth

er p

laye

rs a

nd c

ause

s th

em to

lose

con

trol

. Dur

atio

n: 5

sec

onds

.

3.3.

2.34

CR

ocke

tEng

ine

Incr

ease

s th

e pl

ayer

’s s

peed

by

100%

. Dur

atio

n: 8

sec

onds

.

3.3.

2.35

CL

aser

Shie

ldP

rote

cts

the

play

er f

rom

all

har

mfu

l ef

fect

s, i

nclu

ding

tha

t fr

om h

inde

ring

ite

ms

and

offe

nsiv

e ite

ms.

Dur

atio

n: 2

0 se

cond

s.

3.4

Inpu

t R

espo

nses

3.4.

1C

lass

Des

crip

tions

3.4.

1.1

CIn

putR

espo

nses

Mgr

Thi

s cl

ass

cont

ains

the

rout

ines

of

hand

ling

play

er’s

inpu

t.

Page 41: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

x

xvii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

3.4.

2St

ate

Cha

rt D

iagr

am

3.5

Net

wor

k M

essa

ges

3.5.

1C

lass

Des

crip

tions

3.5.

1.1

CPr

esN

etw

orkM

essa

gesM

grT

his

clas

s co

ntai

ns th

e ro

utin

es o

f ha

ndlin

g ne

twor

k m

essa

ges.

FYP

Fina

l Rep

ort

x

xviii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x E

– 3

D M

odel

s

Mon

ster

Mod

els

Page 42: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xxix

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Tai

zhan

Mod

els

FYP

Fina

l Rep

ort

xxx

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Mag

icia

n M

odel

s

Rob

ot M

odel

s

A T

rack

Mod

el

Page 43: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xxxi

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x F

– G

antt

Cha

rt

Dur

atio

n(i

n W

eeks

)Ju

nJu

lA

ugSe

ptO

ctN

ovD

ecJa

nFe

bM

arA

prR

equi

rem

ent a

nd A

naly

sis

9wPl

ayer

Gui

de2w

Syst

em D

esig

n17

wA

rtwor

k12

w3D

Mod

ellin

g24

wU

ser

Inte

rfac

e D

esig

n4w

Tim

er1w

Ren

deri

ng R

outin

es12

wO

ctre

e Im

plem

enta

tion

4wV

isib

ility

Det

erm

inat

ion

4wC

ollis

ion

Det

ectio

n4w

Inpu

t4w

Net

wor

king

2wG

eom

etri

c O

bjec

ts8w

Col

lisio

n R

espo

nses

10w

Net

wor

k M

essa

ges

6wIn

put R

espo

nses

6wPr

opos

al R

epor

t2w

Prog

ress

Rep

ort

2wU

nit T

estin

g24

wSy

stem

Tes

ting

& D

ebug

ging

4wE

valu

atio

n4w

Fina

l Rep

ort &

Pos

ter

4wPr

ojec

t Pre

sent

atio

n2w

2001

2002

FYP

Fina

l Rep

ort

x

xxii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x G

– D

ivis

ion

of L

abou

r

Tas

ksL

ui C

hung

Man

,Fo

ngL

auL

aiC

lem

ent

Heu

ng W

ahPu

i Yu

Man

Tin

gR

equi

rem

ent a

nd A

naly

sis

XX

XX

Play

er G

uide

XX

Syste

m D

esig

nX

Artw

ork

XX

3D M

odel

ling

XX

Use

r Int

erfa

ce D

esig

nX

Tim

erX

XIn

put

XX

Gra

phic

s R

ende

ring

Rou

tines

XO

ctre

e Im

plem

enta

tion

XV

isibi

lity

Det

erm

inat

ion

XPh

ysic

sX

Col

lisio

n D

etec

tion

XN

etw

orki

ngX

Geo

met

ric

Obj

ect

XX

Col

lisio

n R

espo

nses

XX

XN

etw

ork

Mes

sage

sX

Inpu

t Res

pons

esX

Prop

osal

Rep

ort

XX

XX

Prog

ress

Rep

ort

XX

XX

Uni

t Tes

ting

XX

XX

Syste

m T

estin

g &

Deb

uggi

ngX

XX

XEv

alua

tion

XFi

nal R

epor

t & P

oste

rX

XX

XPr

ojec

t Pre

sent

atio

nX

XX

X

Page 44: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

x

xxiii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

App

endi

x H

– M

eeti

ng M

inut

es

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

1st G

roup

Mee

ting

Gro

up 4

Dat

e:Ju

ne 2

, 200

1T

ime:

5:00

p.m

.P

lace

:R

oom

346

4, H

KU

STA

tten

ding

:C

lem

ent L

ui, C

onni

e L

au, M

andy

Lai

, Fon

g H

eung

Wah

, Pro

f. L

ocho

vsky

and

othe

r gr

oups

of

this

pro

ject

Abs

ent:

Non

eR

ecor

der:

Man

dy L

ai

1.A

ppro

val o

f M

inut

es

Sinc

e th

is is

the

firs

t mee

ting,

ther

e is

no

appr

oval

of

min

utes

of

prev

ious

mee

ting.

2.R

epor

t on

Pro

gres

s

Sinc

e th

is is

the

firs

t mee

ting,

ther

e is

no

prog

ress

to b

e re

port

ed.

3.D

iscu

ssio

n It

ems

3.1

Beg

inni

ng

Pro

f. L

ocho

vsky

dis

trib

uted

han

dout

s to

all

gro

ups

of t

his

proj

ect

and

expl

aine

d th

e pr

ojec

tre

quir

emen

ts.

3.2

Mee

ting

s

Eac

h gr

oup

has

to m

eet P

rof.

Loc

hovs

ky a

t lea

st tw

ice

a m

onth

, in

whi

ch th

ere

is a

mee

ting

for

all

grou

ps.

A g

roup

can

mee

t Pr

of.

Loc

hovs

ky b

esid

es t

he r

equi

red

mee

ting

s. H

owev

er,

min

utes

of

each

mee

ting,

whi

ch a

re to

be

incl

uded

in th

e FY

P re

port

, hav

e to

be

subm

itted

.

3.3

Req

uire

men

ts in

thi

s pr

ojec

t

Alth

ough

the

req

uire

men

ts o

f th

is p

roje

ct a

re s

tate

d in

the

han

dout

, the

re a

re a

few

thi

ngs

wor

th t

ono

tice

. Fir

stly

, Pro

f. L

ocho

vsky

sai

d th

at a

dat

abas

e de

sign

is

not

nece

ssar

y as

a t

ypic

al D

BM

S is

too

slow

for

a g

ame.

Sec

ondl

y, f

rom

exp

erie

nce

in t

he F

YP

of

past

yea

rs,

mos

t gr

oups

impl

emen

ted

thei

r ga

mes

in C

++ w

ith D

irec

tX a

s w

ell a

s T

CP/

IP.

3.4

Adm

inis

trat

ive

info

rmat

ion

Prof

. L

ocho

vsky

sai

d th

at t

he p

ropo

sal

repo

rt i

s to

be

subm

itte

d in

the

3rd

wee

k of

Sep

tem

ber.

In

addi

tion

, the

re w

ill

be p

ract

ice

pres

enta

tion

s in

Oct

ober

200

1, F

ebru

ary

2002

and

May

200

2. T

hefi

rst

pres

enta

tion

wil

l la

st f

or 1

0 m

inut

es;

the

seco

nd p

rese

ntat

ion

wil

l la

st f

or 1

5 m

inut

es.

The

fina

l pro

ject

pre

sent

atio

n w

ill la

st f

or 2

0 m

inut

es a

t the

max

imum

.

Alt

houg

h th

ere

wil

l be

a d

emo

of t

his

proj

ect,

it w

ill

not

coun

t to

war

ds t

he f

inal

gra

de. I

nste

ad, i

tw

ill h

elp

the

grad

ers

to g

rade

this

pro

ject

.

3.5

Tim

e of

nex

t m

eeti

ng

The

nex

t mee

ting

will

be

at 5

p.m

. in

Roo

m 3

464

on 4

Aug

ust 2

001.

4.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 5:3

0 p.

m.

FYP

Fina

l Rep

ort

x

xxiv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

2nd G

roup

Mee

ting

Gro

up 4

Dat

e:4th

Aug

ust 2

001

Tim

e:5:

00 p

.m.

Pla

ce:

Roo

m 3

464,

HK

UST

Att

endi

ng:

Con

nie

Lau

, Man

dy L

ai, F

ong

Heu

ng W

ah, P

rof.

Loc

hovs

ky a

nd o

ther

gro

ups

of th

is p

roje

ctA

bsen

t:C

lem

ent L

uiR

ecor

der:

Man

dy L

ai

1.A

ppro

val o

f M

inut

es

The

min

utes

of

the

firs

t mee

ting

wer

e su

bmitt

ed f

or a

ppro

val.

2.R

epor

t on

Pro

gres

s

2.1

Gam

es d

esig

ned

Prof

. Loc

hovs

ky a

sked

all

grou

ps o

f th

is p

roje

ct to

sta

te w

hat k

ind

of g

ame

was

des

igne

d.

2.1.

1 G

roup

1

Rob

ots

go to

dis

able

all

the

bom

bs in

the

shor

test

tim

e.

2.1.

2 G

roup

2

The

re w

ill

be a

pla

tfor

m f

or p

laye

rs t

o co

mpe

te w

ith

each

oth

er.

If t

he h

ealt

h po

ints

valu

e of

a p

laye

r is

zer

o, th

e ch

arac

ter

for

that

pla

yer

will

die

and

the

gam

e te

rmin

ates

.

2.1.

3 G

roup

3

It is

a r

acin

g ga

me.

2.1.

4 G

roup

4

The

re a

re f

our

trac

ks f

or p

laye

rs t

o ra

ce. S

ome

item

s w

ill b

e pl

aced

on

the

trac

ks. T

here

are

thre

e ki

nds

of i

tem

s: o

ne i

s be

nefi

cial

to

play

ers,

one

hin

ders

pla

yers

and

one

wil

lbe

kep

t by

pla

yers

and

use

d to

hin

der

othe

r pl

ayer

s. T

he o

ne w

ho w

ins

the

grea

test

num

ber

of r

aces

will

be

the

win

ner.

2.2

Impl

emen

tati

on p

latf

orm

Pro

f. L

ocho

vsky

ask

ed a

ll g

roup

s of

thi

s pr

ojec

t to

sta

te w

hat

plat

form

wil

l be

use

d fo

rim

plem

entin

g th

e ga

me.

2.2.

1 G

roup

1

Dir

ectX

, Vis

ual C

++, T

CP/

IP

2.2.

2 G

roup

2

Dir

ectP

lay

2.2.

3 G

roup

3

Dir

ectX

, Vis

ual C

++, T

CP/

IP

2.2.

4 G

roup

4

Dir

ectX

, Vis

ual C

++, T

CP/

IP, 3

D S

tudi

o M

ax

Page 45: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

x

xxv

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

3.D

iscu

ssio

n It

ems

3.1

Item

s th

at n

eed

to b

e ha

nded

in a

t th

e ne

xt m

eeti

ng

Pro

f. L

ocho

vsky

sai

d th

at t

he n

ext

mee

ting

wou

ld b

e at

5 p

.m.

in R

oom

346

4 on

1st S

epte

mbe

r20

01. I

n th

e ne

xt m

eeti

ng, m

inut

es o

f th

is m

eeti

ng s

houl

d be

han

ded

in. A

s Pr

of. L

ocho

vsky

wil

lbe

aw

ay f

rom

7th

-17th

Sep

tem

ber,

if

a gr

oup

wan

ts f

eedb

ack

from

Pro

f. L

ocho

vsky

abo

ut t

hepr

ojec

t pr

opos

al,

a dr

aft

shou

ld b

e ha

nded

in

at t

he n

ext

mee

ting

. In

add

itio

n, P

rof.

Loc

hovs

kyha

d gi

ven

us a

gui

delin

e to

the

proj

ect p

ropo

sal i

n th

e w

eb p

age

http

://w

ww

.cs.

ust.h

k/ug

/fyp

.

Prof

. Loc

hovs

ky a

lso

rem

inde

d us

tha

t th

e pr

ojec

t pr

opos

al h

as t

o be

due

in

the

3rd o

r 4th

wee

k of

Sept

embe

r. I

t w

as s

tate

d th

at t

he p

roje

ct p

ropo

sal

shou

ld i

nclu

de l

ists

of

hard

war

e an

d so

ftw

are

envi

ronm

ent

need

ed f

or t

he p

roje

ct. T

here

sho

uld

be r

easo

ns s

peci

fied

for

eac

h ch

oice

of

soft

war

eus

ed.

An

App

endi

x, w

hich

inc

lude

s a

draf

t of

the

pla

yer

guid

e, s

houl

d be

pla

ced

in t

he p

roje

ctpr

opos

al.

3.2

Add

itio

nal i

nfor

mat

ion

3.2.

1So

ftw

are

spon

sors

hip

Stu

dent

Fon

g H

eung

Wah

in

Gro

up 4

ask

ed w

heth

er t

here

wou

ld b

e so

ftw

are

spon

sors

hip

for

each

gro

up. P

rof.

Loc

hovs

ky c

laim

ed t

hat

ther

e w

ere

five

cop

ies

of 3

DSt

udio

Max

. If

a gr

oup

need

ed t

o as

k fo

r so

ftw

are,

it

shou

ld m

ake

a lis

t of

sof

twar

e an

dse

nd e

mai

l to

Pro

f. L

ocho

vsky

req

uest

ing

for

spec

ific

sof

twar

e sh

arin

g. A

s P

rof.

Loc

hovs

ky w

as n

ot s

ure

wha

t so

ftw

are

was

ins

tall

ed i

n th

e FY

P la

b, g

roup

s w

ho n

eed

soft

war

e sp

onso

rshi

p sh

ould

sen

d em

ail

dire

ctly

to

the

CS

Dep

artm

ent.

Req

uest

s sh

ould

be m

ade

earl

y as

it ta

kes

abou

t thr

ee w

eeks

for

app

rova

l of

soft

war

e sp

onso

rshi

p.

The

re w

ill

be t

wo

PC’s

ass

igne

d to

eac

h gr

oup

for

test

ing

in t

he F

YP

lab.

The

fir

st o

new

ill b

e as

sign

ed d

urin

g Se

ptem

ber

whi

le th

e se

cond

one

will

be

assi

gned

late

r.

3.2.

2D

emon

stra

tion

Las

tly,

Pro

f. L

ocho

vsky

rem

inde

d th

e gr

oups

tha

t th

e fi

rst

dem

onst

rati

on w

ill

be a

t th

een

d of

Sep

tem

ber

to t

he b

egin

ning

of

Oct

ober

. E

ach

grou

p is

exp

ecte

d to

use

a f

ewsl

ides

to g

ive

a br

ief

pres

enta

tion.

4.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 5:2

0 p.

m.

FYP

Fina

l Rep

ort

x

xxvi

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

3rd G

roup

Mee

ting

Gro

up 4

Dat

e:Se

ptem

ber

1, 2

001

Tim

e:5:

00 p

.m.

Pla

ce:

Roo

m 3

464,

HK

UST

Att

endi

ng:

Cle

men

t Lui

, Pro

f. L

ocho

vsky

and

oth

er g

roup

s of

this

pro

ject

Abs

ent:

Con

nie

Lau

, Man

dy L

ai, F

ong

Heu

ng W

ahR

ecor

der:

Cle

men

t Lui

1.A

ppro

val o

f M

inut

es

The

min

utes

of

the

firs

t mee

ting

wer

e ap

prov

ed b

y Pr

of. L

ocho

vsky

.

2.R

epor

t on

Pro

gres

s

The

dra

ft o

f th

e pr

opos

al r

epor

t and

the

min

utes

of

the

seco

nd m

eetin

g w

ere

subm

itted

.

3.D

iscu

ssio

n It

ems

3.1

FY

P m

achi

ne

Pro

f. L

ocho

vsky

sai

d th

at a

ll g

roup

s sh

ould

ask

CS

Sys

tem

to

assi

gn t

hem

FY

P m

achi

nes

for

dem

onst

rati

ons

in t

he f

ollo

win

g m

eeti

ngs.

All

gro

ups

shou

ld d

iscu

ss t

he h

ardw

are

and

soft

war

eco

nfig

urat

ions

with

CS

Syst

em.

3.2

Dem

onst

rati

ons

in t

he f

ollo

win

g m

eeti

ngs

Pro

f. L

ocho

vsky

pro

pose

d th

e da

tes

of m

onth

ly g

roup

mee

ting

s. T

he f

irst

mee

ting

wil

l be

on

26/9

/01,

the

sec

ond

mee

ting

wil

l be

on

31/1

0/01

and

the

thi

rd m

eeti

ng w

ill

be o

n 28

/11/

01.

Dur

ing

thes

e m

eeti

ngs,

all

gro

ups

have

to

dem

onst

rate

the

ir w

ork

acco

rdin

g to

the

sch

edul

e se

t at

the

begi

nnin

g. A

ll g

roup

s ha

ve t

o de

mon

stra

te m

ovin

g a

grap

hica

l ob

ject

in

a m

achi

ne.

Inad

ditio

n, i

n th

e se

cond

dem

onst

ratio

n, t

hey

have

to

dem

onst

rate

con

trol

ling

a gr

aphi

cal

obje

ct i

n a

mac

hine

who

se m

ovem

ent

is s

how

n in

bot

h m

achi

nes.

Bes

ides

tha

t, in

the

thi

rd d

emon

stra

tion

,th

ey h

ave

to b

e ab

le to

con

trol

gra

phic

al o

bjec

ts w

hose

mov

emen

t is

show

n in

bot

h m

achi

nes.

The

re w

ill b

e no

mee

tings

in D

ecem

ber

as a

ll gr

oups

hav

e fi

nal e

xam

inat

ions

.

3.3

Com

mun

icat

ion

tuto

rs

Pro

f. L

ocho

vsky

sai

d th

at b

esid

es g

ivin

g hi

m r

epor

ts f

or p

roof

rea

ding

, al

l gr

oups

sho

uld

seek

advi

ce o

n th

eir

repo

rts

from

the

com

mun

icat

ion

tuto

rs.

4.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 5:1

5 p.

m.

Page 46: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

xx

xvii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

4th G

roup

Mee

ting

Gro

up 4

Dat

e:Se

ptem

ber

26, 2

001

Tim

e:7:

00 p

mP

lace

:R

oom

246

4 an

d FY

P la

bA

tten

ding

:C

lem

ent L

ui, C

onni

e L

au, M

andy

Lai

, Fon

g H

eung

Wah

, Pro

f. L

ocho

vsky

and

othe

r gr

oups

of

this

pro

ject

Abs

ent:

Non

eR

ecor

der:

Man

dy L

ai

1.D

iscu

ssio

n It

ems

1.1

Beg

inni

ng

Prof

. Loc

hovs

ky a

sked

the

four

gro

ups

to g

ive

thei

r pr

esen

tatio

ns o

f th

eir

prop

osal

rep

orts

.

1.2

Dem

onst

rati

on

Prof

Loc

hovs

ky a

sked

the

fou

r gr

oups

to

dem

onst

rate

the

ir p

roje

ct p

rogr

ess

in t

he F

YP

lab.

The

requ

irem

ent

of t

he d

emon

stra

tion

was

to

rend

er a

nd c

ontr

ol a

sim

ple

geom

etri

c ob

ject

loc

ally

in

a3D

env

iron

men

t.

1.3

Tim

e of

nex

t m

eeti

ng

The

nex

t mee

ting

will

be

at 7

:00p

m in

the

FYP

lab

on O

ctob

er 3

1, 2

001.

1.4

Req

uire

men

t of

nex

t m

eeti

ng

In t

he n

ext

mee

ting

, a

dem

o re

nder

ing

and

cont

roll

ing

a si

mpl

e ge

omet

ric

obje

ct l

ocal

ly a

ndre

mot

ely

will

be

requ

ired

with

two

com

pute

rs b

eing

abl

e to

com

mun

icat

e in

one

-way

con

nect

ion.

2.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 8:0

0 p.

m.

FYP

Fina

l Rep

ort

xxx

viii

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

5th G

roup

Mee

ting

Gro

up 4

Dat

e:O

ctob

er 3

1, 2

001

Tim

e:7:

00 p

mP

lace

:C

S la

b 4

Att

endi

ng:

Cle

men

t Lui

, Con

nie

Lau

, Man

dy L

ai, F

ong

Heu

ng W

ah, P

rof.

Loc

hovs

ky a

ndot

her

grou

ps o

f th

is p

roje

ctA

bsen

t:N

one

Rec

orde

r:M

andy

Lai

1.D

iscu

ssio

n It

ems

1.1

Dem

onst

rati

on

In C

S la

b 4,

Pro

f. L

ocho

vsky

ask

ed t

he f

our

grou

ps t

o de

mon

stra

te t

he p

rogr

ess

of r

ende

ring

and

cont

roll

ing

a si

mpl

e ge

omet

ric

obje

ct l

ocal

ly w

hile

the

oth

er m

achi

ne c

an s

ynch

roni

ze t

hein

form

atio

n re

ceiv

ed f

rom

the

firs

t mac

hine

.

1.2

Tim

e of

nex

t m

eeti

ng

The

nex

t mee

ting

will

be

at 7

:00

p.m

. in

the

FYP

lab

on 2

8 N

ovem

ber

2001

.

1.3

Req

uire

men

t of

the

nex

t m

eeti

ng

In t

he n

ext

mee

ting

, a

dem

o re

nder

ing

and

cont

roll

ing

a si

mpl

e ge

omet

ric

obje

ct l

ocal

ly a

ndre

mot

ely

is r

equi

red

wit

h tw

o co

mpu

ters

bei

ng a

ble

to c

omm

unic

ate

in t

wo-

way

con

nect

ion,

i.e

.,th

e ob

ject

can

be

cont

roll

ed i

n bo

th m

achi

nes

and

sim

ulta

neou

sly

can

be v

iew

ed b

y th

e tw

om

achi

nes.

2.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 7:1

5 p.

m.

Page 47: Prestissimo - HKUSTfred/FYP/...reports/ng-final.pdf · FYP Final Report 3 Multi-player, Network-based, 3D Game 2. Results 2.1 Design Phase 2.1.1 System Architecture Since a game is

FYP

Fina

l Rep

ort

x

xxix

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

6th G

roup

Mee

ting

Gro

up 4

Dat

e:Fe

brua

ry 6

, 200

1T

ime:

7:00

p.m

.P

lace

:R

oom

230

2, H

KU

STA

tten

ding

:C

onni

e L

au, M

andy

Lai

, And

y Fo

ng, P

rof.

Loc

hovs

ky a

nd o

ther

gro

ups

of th

ispr

ojec

tA

bsen

t:C

lem

ent L

uiR

ecor

der:

And

y Fo

ng

1.D

iscu

ssio

n It

ems

1.1

Pre

sent

atio

ns

Eac

h gr

oup

pres

ente

d th

e pr

ogre

ss o

f th

eir

proj

ects

.

1.1.

1G

roup

1

Rob

ots

try

to d

isab

le a

ll b

ombs

in

the

shor

test

tim

e. B

ound

ing

sphe

res

are

used

for

colli

sion

det

ectio

n.

1.1.

2G

roup

2

Sep

arat

ed t

he g

ame

engi

ne i

nto

seve

ral

part

s. R

ende

ring

and

net

wor

king

hav

e be

enco

ncen

trat

ed o

n so

far

and

mor

e tim

e w

ill b

e sp

ent o

n cr

eatio

n of

mod

els.

1.1.

3G

roup

3

The

ir g

ame

is a

rac

ing

gam

e fo

r di

ffer

ent

kind

s of

bal

ls.

Ano

ther

sof

twar

e is

use

d to

expo

rt a

max

file

to a

file

for

mat

that

can

be

load

ed b

y th

e G

enes

is3D

eng

ine.

1.1.

4G

roup

4

Cla

sses

for

phy

sics

and

ani

mat

ion

wer

e ad

ded

to t

he s

yste

m. T

he g

ame

now

sup

port

s 2-

way

com

mun

icat

ion

for

the

netw

orki

ng p

art.

Dif

fere

nt a

nim

atio

ns c

an b

e lo

aded

and

rend

ered

. Fin

ite

stat

e m

achi

ne (

FSM

) is

use

d to

han

dle

inpu

t re

spon

se. T

he O

ctre

e da

tast

ruct

ure

is u

sed

for

colli

sion

det

ectio

n an

d vi

ew f

rust

um c

ullin

g.

1.2

Tim

e of

Nex

t M

eeti

ng

The

nex

t mee

ting

will

be

at 6

p.m

. in

FYP

Lab

, Roo

m 4

210,

on

6th M

arch

200

2

2.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 8:1

0 p.

m.

FYP

Fina

l Rep

ort

x

l

Mul

ti-pl

ayer

, Net

wor

k-ba

sed,

3D

Gam

e

Fin

al Y

ear

Pro

ject

: M

ulti

-pla

yer,

Net

wor

k-ba

sed,

3D

Gam

e

Min

utes

of

the

7th G

roup

Mee

ting

Gro

up 4

Dat

e:M

arch

6, 2

001

Tim

e:6:

00 p

.m.

Pla

ce:

Roo

m 4

210,

FY

P L

ab, H

KU

STA

tten

ding

:C

onni

e L

au, M

andy

Lai

, And

y Fo

ng, C

lem

ent L

ui, P

rof.

Loc

hovs

ky a

nd o

ther

grou

ps o

f th

is p

roje

ctA

bsen

t:N

one

Rec

orde

r:A

ndy

Fong

1.D

iscu

ssio

n It

ems

1.1

Dem

onst

rati

ons

In t

he F

YP

Lab

, P

rof.

Loc

hovs

ky a

sked

the

fou

r gr

oups

to

dem

onst

rate

the

ir p

rogr

ess

on t

hedi

ffer

ent p

arts

of

the

gam

es s

uch

as r

ende

ring

, net

wor

king

and

col

lisio

n de

tect

ion.

1.1.

1G

roup

1

Supp

orts

2-p

laye

r ne

twor

k ga

me.

Pla

yers

can

pic

k up

a b

omb.

1.1.

2G

roup

2

Can

not p

rovi

de a

dem

o be

caus

e of

pro

blem

s w

ith th

e m

achi

nes

in th

e FY

P L

ab.

1.1.

3G

roup

3

Supp

orts

2-p

laye

r ga

me.

The

bal

l ca

n m

ove

alon

g th

e tr

ack.

Col

lisi

on d

etec

tion

is

hand

led.

The

vis

ibil

ity

of w

alls

are

che

cked

bef

ore

rend

erin

g. I

t al

so s

uppo

rts

chat

ting

betw

een

two

play

ers.

1.1.

4G

roup

4

Cha

ract

ers

can

run

and

jum

p in

the

gam

e w

ith

diff

eren

t an

imat

ions

. G

ravi

ty e

ffec

t is

adde

d. M

ovin

g on

non

-sm

ooth

sur

face

and

col

lisi

on d

etec

tion

bet

wee

n ch

arac

ter

and

trac

k ar

e su

ppor

ted

usin

g th

e O

ctre

e m

etho

d.

1.2

Tim

e of

Nex

t M

eeti

ng

The

nex

t mee

ting

will

be

at 6

p.m

. in

the

FYP

Lab

, Roo

m 4

210,

on

10th

Apr

il 20

02

2.M

eeti

ng A

djou

rnm

ent

The

mee

ting

was

adj

ourn

ed a

t 6:3

0 p.

m.