ng-proposal...Title ng-proposal.doc Author fred Created Date 1/16/2003 2:03:22 PM

FYP Proposal 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:

FYP Proposal Report

Table of Contents

1. Introduction ............................................................................................................ 1 1.1 Motivation .................................................................................................................. 1

1.2 Game Play .................................................................................................................. 1

1.3 Background ................................................................................................................ 1

2. Progress ................................................................................................................... 2 2.1 Design Phase .............................................................................................................. 2

2.2 Implementation Phase ................................................................................................. 2

2.3 Testing Phase .............................................................................................................. 3

2.4 Evaluation Phase ......................................................................................................... 3

3. Methodology ............................................................................................................ 4 3.1 Design Phase .............................................................................................................. 4

3.2 Implementation Phase ................................................................................................. 5

3.2.1 Game Engine .................................................................................................. 5

3.2.2 Networking .................................................................................................... 5

3.2.3 Artwork .......................................................................................................... 5

3.2.4 Game Code .................................................................................................... 5

3.3 Testing Phase .............................................................................................................. 6

3.4 Evaluation Phase ......................................................................................................... 6

4. Project Planning ...................................................................................................... 7

5. Required Hardware and Software ........................................................................... 8 5.1 Hardware .................................................................................................................... 8

5.2 Software ..................................................................................................................... 8

6. References ............................................................................................................... 9 6.1 Books ......................................................................................................................... 9

6.2 Web Sites .................................................................................................................... 9

7. Appendices ............................................................................................................... i Appendix A – Player Guide .................................................................................................... i

Appendix B – Domain and Use Case Models ....................................................................... iv

Appendix C – Sketches of Artwork .................................................................................... xix

Appendix D – Meeting Minutes ........................................................................................ xxii

FYP Proposal Report 1

1. Introduction

1.1 Motivation

Game development companies like Origin Systems, Blizzard Entertainment and Westwood Studios are

well known to gamers for their award-winning games such as the Ultima Online series, Diablo series

and Command & Conquer series, respectively. Not only do these games feature stunning graphics, but

they also have complex game play in which players can handle a lot of things. For example, in Ultima

Online, players can create different characters with different characteristics such as profession, sex

and appearance.

Games with simple game play, such as Super Mario, are popular with the general public, too.

Different from the complex games mentioned, simple games target players of all ages instead of only

the young. Being replayable is one reason for their popularity. Players will play them more than once

after they finish a game.

In this project, we will design and implement a 4-player, 3D PC game that has simple game play and,

most importantly, is replayable.

1.2 Game Play

Our game, Presstissimo, is in the form of a race that requires traveling on land, swimming in water

and flying through the sky. It provides four tracks for the players: two are on land and one each for

swimming and flying. In each session, one of the players selects from one to four tracks of the tracks

to play on. The winner is the player who wins the greatest number of races. If there are two or more

players who win the greatest number of races, i.e., a draw, then all players play an additional track

until a winner can be determined.

Along each track, players may encounter different objects in different tracks. Some objects benefit the

players, like the Protective Shell that protects players from being harmed in the track on land. Other

objects, like the Shark that slows players down in the track in water, hinder the players during the race.

Moreover, some objects, like Typhoon that attack other players in the track in the sky, can be kept by a

player and then used to hinder another player.

1.3 Background

As this project is a 3D, multiplayer game, it involves graphics and network programming. Therefore,

this summer we learnt DirectX 8 and Winsock programming. In addition, we also learnt how to use

3D Studio Max to model 3D objects in the game.


2. Progress

2.1 Design Phase

The game play was finalized and preliminary domain and use case models were worked out during

the summer. The domain model describes the classes of objects that can be seen by the players and

their corresponding attributes, while the use case model describes all the functions that the players can

perform in the game. Both models are attached in Appendix B.

In addition, some preliminary sketches of the characters and other 3D objects in our game were

completed. The sketches are attached in Appendix C. The modeling of some 3D objects using 3D

Studio Max was also started.

Although 3D Studio Max provides an easier way to make 3D models than drawing them using

DirectGraphics, they cannot be rendered directly in the program. There are three methods to load an

external 3D model into the program. The first method is to write code that directly reads a .max file

and renders it. The second method is to use the Studio Max SDK to develop a plugin that exports

a .max file in the preferred file format and then to write code that renders it. The last method is to first

export a .max file into a .3ds file and then to use a program provided by Microsoft called conv3ds.exe

to convert the .3ds file into a .x file. After that, a DirectGraphics function is used to load the mesh

stored in the .x file and render it. Among these three methods, the last method is the easiest and the

most reliable as we do not have to learn or derive any file formats and code to load and render the

model. Therefore, the last method was chosen to load the 3D models.

2.2 Implementation Phase

An engine is a piece of software that takes in data and responds with respect to the given data. A game

engine is an engine that is used to assist game development. It should be able to provide services such

as rendering graphics, performing collision detection, playing sound and handling input. In this

project, our game engine will be able to provide graphics rendering, collision detection and handling

of input services.

During the summer, work was started on the graphics-rendering component. This component manages

all graphics rendering code in the game, including initialization and releasing of system resources

acquired by the graphics device. It provides services of rendering 3D geometric primitives such as

point, line, point list, line list/strip and mesh. Additionally, it is able to load an external 3D model,

which is encoded in .x file format, into the game. 2D objects, such as color-keyed bitmaps and fonts,

are rendered through this subsystem.

There is a timer, which provides services such as measuring and synchronizing the frame rate,

associated with the game engine.


2.3 Testing Phase

To test the graphics component, it is essential to check whether the component can render the

primitives stated above. The primitives were defined by arbitrary vertices and their rendering methods

were run. The primitives were rendered correctly. In addition, a bitmap was loaded and rendered. The

frame rate of the program was also rendered. Figure 1 shows a screenshot of testing the rendering of

triangles, the frame rate and a bitmap. A simple 3D model, such as a cube together with a sphere made

by 3D Studio Max, was also rendered successfully.

Since we were not assigned a machine in the FYP lab during summer, the code was tested on our own

machine. The hardware and software configuration is listed below:

• Intel Pentium III 550MHz

• 128MB SDRAM

• Matrox G400 Display Card with 32MB video memory

• Microsoft Windows Me

• Microsoft DirectX 8.0a runtime library (Debug version).

Figure 1: A screenshot testing rendering some triangles, the frame rate and a bitmap.

2.4 Evaluation Phase

The sketches of the artwork were evaluated through a team discussion. When the preliminary sketches

were made, we looked to see if the artwork would be suitable for the game. Some of the group

members thought that the artwork required modification. Therefore, the artwork was modified and

then evaluated until all group members were satisfied.


3. Methodology

Game programming is different from ordinary business application programming. The responsibility

of business application programmers is to make a system that responds correctly to users’ input. Game

programmers not only have to make sure that the game logic functions correctly, but also to push the

hardware to its performance limit, which is the most difficult part of this project. Data structures and

algorithms have to be chosen carefully so that the game is optimized as much as possible.

It is difficult to learn a completely new graphics package and programming environment in a short

time to get the project started. We learnt OpenGL in our graphics course, but we cannot use our

knowledge of OpenGL in this project since the underlying structures of OpenGL and DirectX are

quite different. We cannot apply our knowledge of console programming in this project since our

game is a Windows application.

Since this is a race game, basic physics modeling involving speed, acceleration and collision is

unavoidable. Before implementing the game, the collision responses to the collisions among objects

have to be worked out.

Therefore, this project provides an opportunity to learn tools, such as DirectX and 3D Studio Max,

other than what was learnt during academic studies and how to optimize code through using data

structures and algorithms in order to run the program efficiently.

There are four phases in this project: Design, Implementation, Testing and Evaluation. The duties to

be fulfilled in each phase will be discussed in the following.

3.1 Design Phase

This phase is subdivided into two parts. In the first part, the functional requirement of the game is

identified. A class diagram and a use case diagram are used to visualize the functional requirement.

These models are attached in Appendix B. In the second part, the routine of each use case is worked

out. Sequence diagrams are used to represent the routines. All diagrams are drawn using Rational

Rose.

3.2 Implementation Phase

In this project, there are four main components to be implemented, namely, Game Engine,

Networking, Graphics and Game Code.

Among programming languages like Java, Visual Basic, C, and C++, code written in C is the fastest.

Although C++ is a little bit slower than C, this difference is insignificant in game programming. In

addition, the code written in C++ is easier to maintain because of its object-oriented property. The

ease of maintaining the code outweighs the little gain in speed. Therefore, C++ is chosen to be the

programming language in this project.


3.2.1 Game Engine

As previously mentioned, a game engine is a piece of software that assists game development. Our

game engine is subdivided into three subsystems: Graphics Rendering, Input Handling and Collision

Detection.

3.2.1.1 Graphics Rendering

This subsystem manages all code that renders graphics in the game, including initialization and

releasing of system resources acquired by the graphics device. It provides services of rendering 3D

geometric primitives such as point, line, point list, line list/strip and mesh. It is able to load an external

3D model, which is encoded in .x file format, into the game. In addition, 2D objects such as

color-keyed bitmaps and fonts are rendered through this subsystem. Other graphics objects that are

not renderable, such as camera, light and materials, are also managed by this subsystem.

There are two common graphics APIs: DirectX and OpenGL. DirectX is for the Windows platform

only while OpenGL is cross-platform. Since the game will be run on the Windows platform, DirectX

is a good choice. There is much debate on the performance and programmer friendliness of both API’s.

In the past, DirectX is indeed slower than OpenGL. As DirectX developed, the difference in the

performance grew narrower. With the recent introduction of DirectX 8, the performance of both API’s

is almost the same. In addition, the DirectX 8 API was rewritten so that DirectDraw and Direct3D

were combined into DirectGraphics. As a consequence, the API is cleaner than that in previous

versions. Moreover, some useful utility functions, such as loading meshes into the program from .x

file format, add to the programmer friendliness of the DirectX API. Therefore, DirectGraphics of

DirectX 8.0a is chosen to be the graphics package in this project.

3.2.1.2 Input Handling

This subsystem provides services for easy registration of responses to corresponding player’s input.

Similar to the Graphics Rendering Subsystem, this subsystem includes initialization and releasing of

system resources acquired by the input device. DirectInput of DirectX 8.0a is chosen to be the input

handling API to implement this subsystem.

3.2.1.3 Collision Detection

This subsystem provides services for checking if two objects collide.

3.2.2 Networking

This component provides services for sending and receiving messages. It is also able to connect to

and disconnect from an arbitrary host.

DirectPlay is a component of DirectX dealing with network communication in a multiplayer game. It

is at a higher level than TCP/IP as it is built on top of TCP/IP. Programmers may benefit from the

simpler syntax. However, it is less flexible to use DirectPlay. Therefore, TCP/IP (Winsock 2.0) is

chosen to be the network protocol in this project.


3.2.3 Artwork

This is the set of artwork that is to be drawn on the computer screen. The artwork was already

sketched and evaluated. 3D Studio Max will be used to model the objects that can be seen by the

players.

3.2.4 Game Code

This component is directly related to the game play itself. It can be subdivided into 3 subsystems:

Collision Response, Input Handling, and Network Message Handling.

3.2.4.1 Collision Response

This subsystem contains the responses when a collision between two objects occurs. There are three

kinds of collision: Character-Track collision, Character-Character collision and Character-Item

collision. Different kinds of collisions have different responses. The Character-Track collision

response stops the character from penetrating through the track; while the Character-Character

collision response bounces the characters away from each other. The Character-Item collision

response will be determined by the property of each item.

This subsystem depends on the Collision Detection subsystem in the Game Engine as collision

responses will only be carried out if there is a collision detected.

3.2.4.2 Input Handling

This subsystem is a set of routines corresponding to the player’s input. It includes moving, using

items, making a choice in some scenarios like setting up a game session and joining a game session.

The full set of functionalities that a player can manipulate is described in the use case model in

Appendix B.

This subsystem depends on the Input subsystem in our Game Engine.

3.2.4.3 Network Message Handling

This subsystem includes the definition of a packet that carries messages needed to synchronize the

game state. The communication among player machines will be achieved by the client-server model.

This subsystem depends on the Network subsystem in our Game Engine.

3.3 Testing Phase

This phase finds errors in the program and debugs the program. Actually, this phase goes with the

implementation phase. When a particular component is finished, stubs or drivers are used to test the

component to see if it works (unit test). When all components are finished, they are tested to see if

they interact correctly with each other (integration test). They are tested in a bottom-up manner, that is,

test the subsystems first and then the whole system.

Since the game code depends on the network component and the game engine component, it is

essential to ensure that both components work before testing the game code. In addition, inside the

game engine, the graphics component will be tested before testing the input and collision components


since the responses of the input and collision components are visualized through the graphics

component.

3.4 Evaluation Phase

After testing and debugging, the game will be posted on the web for interested parties to download. In

addition, a homepage will be constructed to let players give comments and rate the game on graphics

quality, game play, speed and ease of control.

The evaluation phase will last for a month. During this period, the comments given by players will be

constantly checked and improved versions of our game will be released.

4. Project Planning

Below is the Gantt chart of our project schedule.

Duration(in Weeks) Jun Jul AugSept Oct Nov Dec Jan Feb MarApr

Requirement and Analysis 9wPlayer Guide 2wSystem Design 15wArtwork 12wGraphics Rendering 4wCollision Detection 4wInput 4wNetwork 2wCollision Responses 10wNetwork Message Handling 4wInput Handling 4wProposal Report 2wProgress Report 2wSystem Testing & Debugging 4wEvaluation 4wFinal Report & Poster 4wProject Presentation 4w

2001 2002


Below are the details of how we divide our work:

Lui Chung Man, Fong Lau LaiClement Heung Wah Pui Yu Man Ting

Requirement and Analysis X X X XPlayer Guide XSystem Design X X X XArtwork X XGraphics Rendering XCollision Detection X X X XInput X XNetwork X XCollision Responses X X X XNetwork Message Handling X XInput Handling X XProposal Report X X X XProgress Report X X X XSystem Testing & Debugging X X X XEvaluation X X X XFinal Report & Poster X X X XProject Presentation X X X X

5. Required Hardware and Software

The following are the lists of the hardware and software that we will use in order to complete the

project. Most of the listed items will be provided by CS System, except the Accelerated 3D Graphics

Display Card. Up until now CS System is still checking whether such a display card can be provided.

5.1 Hardware

• Intel Pentium III 550MHz

• 128 MB RAM

• 200 MB hard disk space

• A Display Monitor

• A Standard 102-key Keyboard

• LAN Support

• Accelerated 3D Graphics Display Card

5.2 Software

• Programming Language: C++

• Graphics Package: DirectGraphics of DirectX 8.0a

• Network Protocol: TCP/IP (Winsock 2.0)

• Microsoft Visual C++ 6.0

• 3D Studio Max


• GIMP

6. References

6.1 Books

1. Barron, T., Multiplayer Game Programming. Prima Tech, 2001.

2. Deloura, M., Game Programming Gems, Vol. I. Charles River Media, 2000.

3. LaMonthe, A., Tricks of the Windows Game Programming Gurus. SAMS, 1999.

4. Moller, T., and Haines, E., Real-Time Rendering. A.K. Peters Ltd., 1999.

5. Walsh, P., The Zen of Direct3D Game Programming. Prima Tech, 2001.

6. 3DS MAX R4 ? ? ? ? ? ? ? ? ? ? ?

7. 3DS MAX R4 ? ? ? ? ? ? ? ? ? ? ?

8. 3DS MAX ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

9. DirectX 3D ? ? ? ? ? ? ? ? ? ? ? ? ? (DirectX 3D Graphics Programming Bible

Chinese Version)

10. ? ? ? ? ? ? (? ? ? ? ? ? ? ? )

11. 3ds max 4 ? ? ? - ? ? ? ? ? (? ? ? ? ? ? ? ? ? ? )

12. 3ds max 4 ? ? ? - ? ? ? ? ? (? ? ? ? ? ? ? ? ? ? )

13. ? ? 3D Studio Max R3.X

6.2 Websites

1. http://www.flipcode.com (Last Accessed: 21/9/2001)

2. http://www.gamedev.net (Last Accessed: 19/9/2001)

3. http://www.cfxweb.net (Last Accessed: 18/9/2001)

4. http://www.gamasutra.com (Last Accessed: 16/9/2001)

5. http://www.zen-x.net (Last Accessed: 1/9/2001)

FYP Proposal Report i

7. Appendices

Appendix A – Prestissimo Player Guide

Introduction

Magician, Robot, Tarzan and Monster are competing for the honour of “The Prestissimo in the

Universe”, which means the fastest mover in the Universe. Now, they are polishing their favorite

traveling tools to get ready for the competitions on Land, in the Water, and in the Sky.

In this game, you are going to be one of the mentioned characters to race on the tracks on Land, in the

Water and in the Sky. Along each track, there are items that either benefit or hinder you. In addition,

you can keep some items and then use them to hinder other players.

The winner is the one who wins the greatest number of races. If there is a draw, then all players will

play an additional track until a winner can be determined.

Playing Prestissimo

Setting up a game session

After entering the game, you will see the main menu of the game. If you want to be the server of this

game, then choose “Setup Game Session”. After that, you have to choose the tracks to play and enter

the number of laps for each track. Wait until other players join your game session. When a player

joins your game session, you can either launch the game by pressing ENTER or wait for another two

players to join. If you want to return to the main menu, press ESCAPE.

Joining a game session

If you want to join a game session that is setup somewhere, then choose “Join Game Session”. You

will be prompted to enter the IP address or the host name of the game server. After entering it, the

tracks selected by the game server and the corresponding number of laps will be displayed. Press

ENTER to confirm joining the game session or press ESCAPE to return to the main menu.

Getting Help

Choose HELP to check the default keyboard configuration of the game.

Playing the game

When a game session is launched, you will be directed to the first track selected. The following

explains how to play the game.

Move

Use the arrow keys to move forward, backward, or change direction. Besides that, there are some

special movements in each track. Press ALT to jump in the tracks on Land, sink in the Water and fly

FYP Proposal Report ii

upwards in the Sky. In addition, press CTRL to fly downwards in the Sky.

Encountering Items

Along each track, there are different kinds of items that interact with you. Some items benefit you

while some hinder you. In addition, you can keep some items and then use them to hinder other

players.

Beneficial Items

Fossil Fuel When a player acquires this item, the player will travel faster than other players will.

The effect will last for 5 seconds.

Protective Shell When a player acquires this item, the player will be immune from offensive items

used by other players. The protection lasts for 10 seconds.

Milk Bottle This item increases the player’s speed for 5 seconds.

Mother This item prevents the player from being harmed by offensive items used by other

players for 8 seconds.

Sashimi Players can swim faster for 5 seconds.

Protective Net Players will not be affected by any harmful effects including that from hindering

items and offensive items for 10 seconds.

Rocket Engine Increases the player’s speed by 100%. Duration: 8 seconds.

Laser Shield Protects the player from all harmful effects, including that from hindering items and

offensive items. Duration: 20 seconds.

Hindering Items

Animal Trap This obstacle traps players stepping on it and makes them immobile for 3 seconds.

Roadster It may come from behind players, bumping them and making them run slower for 5

seconds.

Shark It comes from behind players and attacks them, decreasing their speed for 3 seconds.

Bird Feces Reduce a player’s speed by 50%. Duration: 10 seconds.

Offensive Items

Strange Flower If this item hits a victim, the victim will be hindered by a group of strange flowers.

Seed The flowers will last for 1 second.

Cobra The victim will be screwed up by this snake, stopping the player from moving for 3

seconds.

Needles This stabs players’ feet stopping them for 1 second if they step on it.

FYP Proposal Report iii

Diaper This will stop the victim for 3 seconds.

Octopus It spurts black ink onto a player, making him lose his direction and move backward

for 5 seconds.

Torpedo The victim is stopped for 3 seconds.

Tracing Bomb The explosion stops the attacked players for 3 seconds.

Typhoon Attacks all other players and causes them to lose control. Duration: 5 seconds.

Using Offensive Items

At the bottom of the screen, you will see a list of offensive items you have collected along the track.

Press 1, 2, … to use item 1, 2, … If the item has a target, then you have to specify a victim by

pressing 1, 2, 3 or 4.

Quitting the game

To quit the game, choose QUIT GAME in the main menu.

FYP Proposal Report iv

Appendix B - Domain and Use Case Models

1. Domain Model

Each track will feature the classes stated below. The class diagram shown below can be viewed as a

hierarchy tree. Each leaf will further specialize into different subclasses in each track. Detailed classes

of items, which are visible to players, will be described later.

1.1 Common Class Diagram

1.2 Common Class Descriptions

1.2.1 CGeometricObject

1.2.1.1 Description

This class is the base class of all objects that are renderable and drawable on the screen. 1.2.1.2 Attributes

1.2.1.2.1 Private Polygon m_pPolygonList

This is the list of polygons that are to be rendered and drawn on the screen.

1.2.1.2.2 Private Point m_ptLocation

This stores the current location of the geometric object in the world.

1.2.1.2.3 Private Vector m_vtOrientation

This stores the orientation the geometric object is facing in the world.

FYP Proposal Report v

1.2.2 CCharacter

1.2.2.1 Description

This class stores information of a player.

1.2.2.2 Attributes

1.2.2.2.1 Private Float m_fSpeed

This stores the current speed of the player.

1.2.2.2.2 Private Char m_cID

This identifies the player uniquely in a multiplayer environment.

1.2.2.2.3 Private Offensive m_pOffensiveItems

This is the list of offensive items that are used by a player to hinder other players.

1.2.3 CItem

1.2.3.1 Description

This is the class that stores information of an item that interacts with players. It specializes

into CHindering, CBeneficial and COffensive.

1.2.3.2 Attributes

1.2.3.2.1 Private Integer m_iDuration

This determines how long the item will affect the players.

1.2.4 CHindering

1.2.4.1 Description

This is a class of items that hinder the players along the track of a race. It further specializes

into CDecelerate and CStop.

1.2.5 CDecelerate

1.2.5.1 Description

This is a class of items that makes the player travel slower than others.

1.2.5.2 Attributes

1.2.5.2.1 Private Float m_fDifference

This determines the extent the player is decelerated.

1.2.6 CStop

1.2.6.1 Description

This is a class of items that stops the player from moving.

1.2.7 CBeneficial

1.2.7.1 Description

This is a class of items that benefits the player along the track of a race. It further

specializes into CAccelerate and CProtective.

FYP Proposal Report vi

1.2.8 CAccelerate

1.2.8.1 Description

This is a class of items that makes the player travel faster than others.

1.2.8.2 Attributes

1.2.8.2.1 Private Float m_fDifference

This determines the extent the player is accelerated.

1.2.9 CProtective

1.2.9.1 Description

This is a class of items that protects the player from being offended by offensive items.

1.2.10 COffensive

1.2.10.1 Description

This is the class of items that can be kept by the player and then used to hinder a victim. It

specializes into CAvoidable and CNonAvoidable.

1.2.11 CAvoidable


This is a class of items whose effects may be avoided by a victim.

1.2.12 CNonAvoidable


This is a class of items whose effects are not avoidable in any circumstances by a victim. It

specializes into Single and Global.

1.2.13 CSingle


This is a class of items that requires a target victim to be selected so that the victim will

experience the effects of the items.

1.2.14 CGlobal


This is a class of items that will affect all other players when used by a player.

1.3 Item Descriptions for Each Track

1.3.1 Track 1 – Land

1.3.1.1 CDecelerate

None

1.3.1.2 CStop

1.3.1.2.1 CAnimalTrap

This obstacle traps players stepping on it immobilizing them for 3 seconds.

FYP Proposal Report vii

1.3.1.3 CAvoidable

1.3.1.3.1 CStrangeFlowerSeed

If this item hits a victim, the victim will be hindered by a group of strange

flowers. The flowers will last for 1 second.

1.3.1.4 CSingle

1.3.1.4.1 CCobra

The victim will be screwed up by this snake, stopping the player from moving for

3 seconds.

1.3.1.5 CGlobal

None

1.3.1.6 CAccelerate

1.3.1.6.1 CFossilFuel

When a player acquires this item, the player will travel faster than other players

will. The effect will last for 5 seconds.

1.3.1.7 CProtective

1.3.1.7.1 CProtectiveShell

When a player acquires this item, the player will be immune from offensive items

used by other players. The protection lasts for 10 seconds.

1.3.2 Track 2 – Grand Priz

1.3.2.1 CDecelerate

1.3.2.1.1 CRoadster

The roadster may come from behind the players bumping them and making them

run slower for 5 seconds.

1.3.2.2 CStop

None

1.3.2.3 CAvoidable

1.3.2.3.1 CNeedles

This stabs players’ foot stopping them for 1 second if they step on it.

1.3.2.4 CSingle

1.3.2.4.1 CDiaper

This will stop the victim for 3 seconds.

1.3.2.5 CGlobal

None

1.3.2.6 CAccelerate

1.3.2.6.1 CMilkBottle

This item increases the player’s speed for 5 seconds.

FYP Proposal Report viii

1.3.2.7 CProtective

1.3.2.7.1 CMother

This item prevents the player from being harmed by offensive items used by

other players for 8 seconds.

1.3.3 Track 3 – Water

1.3.3.1 CDecelerate

1.3.3.1.1 CShark

The shark attacks players from behind decreasing their speed for 3 seconds.

1.3.3.2 CStop

None

1.3.3.3 CAvoidable

1.3.3.3.1 COctopus

The octopus spurts black ink onto a player making him lose his direction and

move backwards for 5 seconds.

1.3.3.4 CSingle

1.3.3.4.1 CTorpedo

The victim is stopped for 3 seconds.

1.3.3.5 CGlobal

None

1.3.3.6 CAccelerate

1.3.3.6.1 CSashimi

Players can swim faster for 5 seconds.

1.3.3.7 CProtective

1.3.3.7.1 CProtectiveNet

Players will not be affected by any harmful effects including that from hindering

items and offensive items for 10 seconds.

1.3.4 Track 4 – Sky

1.3.4.1 CDecelerate

1.3.4.1.1 CBirdFeces

Reduces a player’s speed by 50%. Duration: 10 seconds.

1.3.4.2 CStop

None

1.3.4.3 CAvoidable

None

FYP Proposal Report ix

1.3.4.4 CSingle

1.3.4.4.1 CTracingBomb

The explosion stops the attacked players for 3 seconds.

1.3.4.5 CGlobal

1.3.4.5.1 CTyphoon

Attacks all other players and causes them to lose control. Duration: 5 seconds.

1.3.4.6 CAccelerate

1.3.4.6.1 CRocketEngine

Increases the player’s speed by 100%. Duration: 8 seconds.

1.3.4.7 CProtective

1.3.4.7.1 CLaserShield

Protects the player from all harmful effects, including that from hindering items

and offensive items. Duration: 20 seconds.

FYP Proposal Report x

2. Use Case Model

A use case is a function provided by a system that yields a visible result for actors. In this game, there

are three kinds of actors: Player, Server Player and Client Player, in which Player specializes into the

latter two. In addition, there are totally 12 use cases, i.e., operations for the players. Some operations

are available for all tracks while some are for a specific track only; some operations have to be done

before playing the game while others constitute the game play.

2.1 System Use Cases

2.1.1 Help

This use case shows how a player asks the system for the rules of the game and how to control the

character assigned to them.

2.1.1.1 Actors

This use case is invoked by Player.

2.1.1.2 Preconditions

The Player is already in the main menu of the game.

2.1.1.3 Basic Path

1. The use case starts when the Player selects the option – Help.

2. The system displays the rules of the game and the default keyboard configuration.

3. The system waits for the Player to select the option to quit to the main menu of the

game.

4. The use case ends.

2.1.1.4 Subflows

None

2.1.1.5 Alternate Paths

None

2.1.1.6 Post Conditions

The Player is directed to the main menu of the game.

2.1.2 Setup Game Session

This use case shows how a player sets up a game server to create a multiplayer environment.

2.1.2.1 Actors

This use case is invoked by Server Player.


The Server Player is already in the main menu of the game.

2.1.2.3 Basic Path

1. The use case starts when the Server Player selects the option – Setup Game Session.

2. The system prompts the Server Player to select the tracks among the four tracks

FYP Proposal Report xi

provided.

3. The Server Player selects the tracks to play on.

4. The system prompts the Server Player to enter the number of laps for each track

selected.

5. The Server Player enters the number of laps for each track selected.

6. The Server Player is assigned a particular character and is prompted to wait for Client

Players to join this game session until he wants to quit or the number of players reaches

the maximum or he chooses the option to launch the game. (A1)


2.1.2.4 Subflows

None


A1: If no Client Players have joined the game and the Server Player chooses to launch the

game, an error message will be printed on the screen and the system will return to

step 6 of the Basic Path.


The Server Player is directed either to the main menu of the game or to the start of the

game.

2.1.3 Join Game Session

This use case shows how a player connects to a game server to play the game.

2.1.3.1 Actors

This use case is invoked by Client Player.


The Client Player is already in the main menu of the game.

2.1.3.3 Basic Path

1. The use case starts when the Client Player chooses the option – Join Game Session.

2. The system prompts the Client Player to enter the IP address/host name of the game

server. (A1)

3. The system displays the tracks and the corresponding number of laps chosen by the

Server Player of the game server. The system prompts the Client Player to confirm to

join this game session.

4. The Client Player confirms to join this game session.

5. The Client Player is assigned a particular character and is prompted to wait for the

Server Player to launch the game until he wants to quit.


2.1.3.4 Subflows

None

FYP Proposal Report xii


A1: If the server with the entered IP address/host name cannot be reached, an error

message will be printed and the Client Player is prompted to enter a valid IP

address/host name or to terminate the use case.


The Client Player is directed either to the main menu or to the start of the game.

2.1.42.1.4 Quit Game

This use case shows how the Player quits the game.

2.1.4.1 Actors



The Player is already in the main menu of the game.

2.1.4.3 Basic Path

1. The use case starts when the Player chooses the option – Quit Game.

2. The system releases all resources acquired.


2.1.4.4 Subflows

None


None


The game shuts down.

FYP Proposal Report xiii

2.2 Common Track Use Cases

2.2.1 Accelerate

This use case shows how players accelerate their characters.

2.2.1.1 Actors



The game has already started.

2.2.1.3 Basic Path

1. The use case starts when the Player chooses the option – Accelerate.

2. The system increases the Player’s speed by a particular amount. (A1)

3. The system renders the updated character.


2.2.1.4 Subflows

None


A1: If the increased speed of the Player exceeds the maximum speed allowed, the speed is

truncated to the maximum speed allowed.


None

2.2.2 Decelerate

This use case shows how players decelerate their characters.

2.2.2.1 Actors




2.2.2.3 Basic Path

1. The use case starts when the Player chooses the option – Decelerate.

2. The system decreases the Player’s speed by a particular amount. (A1)



2.2.2.4 Subflows

None


A1: If the decreased speed of the Player exceeds the minimum speed allowed, the speed is

truncated to the minimum speed allowed.

FYP Proposal Report xiv


None

2.2.3 Change Orientation

This use case shows how players change their orientation.

2.2.3.1 Actors




2.2.3.3 Basic Path

1. The use case starts when the Player chooses the option – Change Orientation.

2. The system changes the Player’s orientation by a particular value of degrees.



2.2.3.4 Subflows

None


None


None

2.2.4. Use Offensive Items

This use case shows how a player uses offensive items to hinder other players.

2.2.4.1 Actors



The Player is already in the game and the Player already possesses at least one item.

2.2.4.3 Basic Path

1. The use case starts when the Player chooses the offensive item to use. (A1)

2. The system prompts the Player to specify the victim if the item is CSingle.

3. The item is triggered by the Player.

4. The item exhibits its effect. (A1)


2.2.4.4 Subflows

None


A1: If the victim is protected by CProtective items, then the victim is not affected by the

FYP Proposal Report xv

offensive item.


None

FYP Proposal Report xvi

2.3 Use Cases for Track 1 & 2 – Land & Grand Priz

2.3.1. Jump

This use case shows how players jump

2.3.1.1 Actors




2.3.1.3 Basic Path

1. The use case starts when the Player chooses the option – Jump.

2. The system translates the Player’s position up by a particular amount.

3. The system translates the Player’s position down to the ground after some time.



2.3.1.4 Subflows

None


None


None

FYP Proposal Report xvii

2.4 Use Cases for Track 3 – Water

2.4.1. Sink

This use case shows how players sink temporarily in water.

2.4.1.1 Actors




2.4.1.3 Basic Path

1. The use case starts when the Player chooses the option – Sink.

2. The system translates the Player’s position down by a particular amount.

3. The system translates the Player’s position up to the water level after some time.



2.4.1.4 Subflows

None


None


None

FYP Proposal Report xviii

2.5 Use Cases for Track 4 – Sky

2.5.1. Fly

This use case shows how players fly in the sky.

2.5.1.1 Actors




1.5.1.3 Basic Path

1. The use case starts when the Player chooses the option – Fly.

2. The system translates the Player’s position up by a particular amount.



2.5.1.4 Subflows

None


None


None

2.5.2. Land

This use case shows how players land from the sky.

2.5.2.1 Actors




2.5.2.3 Basic Path

1. The use case starts when the Player chooses the option – Land.

2. The system translates the Player’s position down by a particular amount.



2.5.2.4 Subflows

None


None


None

FYP Proposal Report xix

Appendix C – Sketches of Artwork

Tarzan and his traveling tools

Magician and her traveling tools

FYP Proposal Report xx

Monster and its traveling tools

Items that appear in the tracks in Land and Grand Priz

FYP Proposal Report xxi

Robot and its traveling tools

Items that appear in the tracks in water and the sky

FYP Proposal Report xxii

Appendix D – Meeting Minutes

Final Year Project: Multi-player, Network-based, 3D Game

Minutes of the 1st Group Meeting

Group 4

Date: June 2, 2001

Time: 5:00 p.m.

Place: Room 3464, HKUST

Attending: Clement Lui, Connie Lau, Mandy Lai, Fong Heung Wah, Prof. Lochovsky, and

other groups of this project

Absent: None

Recorder: Mandy Lai

1. Approval of Minutes

Since this is the first meeting, there is no approval of minutes of previous meeting.

2. Report on Progress

Since this is the first meeting, there is no progress to be reported.

3. Discussion Items

3.1 Beginning

Prof. Lochovsky distributed handouts to all groups of this project and explained the project

requirements.

3.2 Meetings

Each group has to meet Prof. Lochovsky at least twice a month, in which there is a meeting for all

groups. A group can meet Prof. Lochovsky besides the required meetings. However, minutes of

each meeting, which are to be included in the FYP report, have to be submitted.

3.3 Requirements in this project

Although the requirements of this project are stated in the handout, there are a few things worth to

notice. Firstly, Prof. Lochovsky said that a database design is not necessary as a typical DBMS is

too slow for a game. Secondly, from experience in the FYP of past years, most groups

implemented their games in C++ with DirectX as well as TCP/IP.

3.4 Administrative Information

Prof. Lochovsky said that the proposal report is to be submitted in the 3rd week of September. In

addition, there will be practice presentations in October 2001, February 2002 and May 2002. The

FYP Proposal Report xxiii

first presentation will last for 10 minutes; the second presentation will last for 15 minutes. The

final project presentation will last for 20 minutes at the maximum.

Although there will be a demo of this project, it will not count towards the final grade. Instead, it

will help the graders to grade this project.

3.5 Time of Next Meeting

The next meeting will be at 5 p.m. in Room 3464 on 4 August 2001.

4. Meeting Adjournment

The meeting was adjourned at 5:30 p.m.

FYP Proposal Report xxiv

Final Year Project: Multi-player, Network-based, 3D Game Minutes of the 2nd Group Meeting

Group 4

Date: 4th August 2001

Time: 5:00 pm


Attending: Connie Lau, Mandy Lai, Fong Heung Wah, Prof. Lochovsky, and other groups

of this project

Absent: Clement Lui

Recorder: Mandy Lai


The minutes of the 1st meeting were submitted for approval.


2.1 Games designed

Prof. Lochovsky asked all groups of this project to state what kind of game was designed.

2.1.1 Group 1

Robots go to disable all the bombs in the shortest time.

2.1.2 Group 2

There will be a platform for players to compete with each other. If the health points

value of a player is zero, the character for that player will die and the game terminates.

2.1.3 Group 3

It is a racing game.

2.1.4 Group 4

There are four tracks for players to race. Some items will be placed on the tracks.

There are three kinds of items: one is beneficial to players, one hinders players, and one

will be kept by players and used to hinder other players. The one who wins the greatest

number of races will be the winner.

2.2 Implementation platform

Prof. Lochovsky asked all groups of this project to state what platform will be used for

implementing the game.

2.2.1 Group 1

DirectX, Visual C++, TCP/IP

2.2.2 Group 2

FYP Proposal Report xxv

DirectPlay

2.2.3 Group 3

DirectX, Visual C++, TCP/IP

2.2.4 Group 4

DirectX, Visual C++, TCP/IP, 3D Studio Max

3. Discussion Items

3.1 Items that need to be handed in in the next meeting

Prof. Lochovsky said that the next meeting would be at 5 p.m. in Room 3464 on 1st September

2001. In the next meeting, minutes of this meeting should be handed in. As Prof. Lochovsky will

be away from 7th-17th September, if a group wants feedback from Prof. Lochovsky about the

project proposal, a draft should be handed in in the next meeting. In addition, Prof. Lochovsky

had given us a guideline to the project proposal in the web page http://www.cs.ust.hk/ug/fyp.

Prof. Lochovsky also reminded us that the project proposal has to be due in the 3rd or 4th week of

September. It was stated that the project proposal should include lists of hardware and software

environment needed for the project. There should be reasons specified for each choice of software

used. An Appendix, which includes a draft of the player guide, should be placed in the project

proposal.

3.2 Additional information

3.2.1 Software sponsorship

Student Fong Heung Wah in Group 4 asked whether there would be software

sponsorship for each group. Prof. Lochovsky claimed that there were five copies of 3D

Studio Max. If a group needed to ask for software, it should make a list of software and

send email to Prof. Lochovsky requesting for specific software sharing. As Prof.

Lochovsky was not sure what software was installed in the FYP lab, groups who need

software sponsorship should send email directly to the CS Department. Requests should

be made early as it takes about three weeks for approval of software sponsorship.

There will be two PC’s assigned to each group for testing in the FYP lab. The first one

will be assigned during September while the second one will be assigned later.

3.2.2 Demonstration

Lastly, Prof. Lochovsky reminded the groups that the first demonstration will be at the

end of September to the beginning of October. Each group is expected to use a few

slides to give a brief presentation.



FYP Proposal Report xxvi

Final Year Project: Multi-player, Network-based, 3D Game Minutes of the 3rd Group Meeting

Group 4

Date: September 1, 2001

Time: 5:00 p.m.


Attending: Clement Lui, Prof. Lochovsky, and other groups of this project

Absent: Connie Lau, Mandy Lai, Fong Heung Wah

Recorder: Clement Lui


The minutes of the first meeting were approved by Prof. Lochovsky.


The draft of the proposal report and the minutes of the second meeting were submitted.

3. Discussion Items

3.1 FYP machine

Prof. Lochovsky said that all groups should ask CS System to assign them FYP machines for

demonstrations in the following meetings. All groups should discuss the hardware and software

configurations with CS System.

3.2 Demonstrations in the following meetings

Prof. Lochovsky proposed the dates of monthly group meetings. The first meeting will be on

26/9/01, the second meeting will be on 31/10/01 and the third meeting will be on 28/11/01.

During these meetings, all groups have to demonstrate their work according to the schedule set at

the beginning. All groups have to demonstrate moving a graphical object in a machine. In

addition, in the second demonstration, they have to demonstrate controlling a graphical object in a

machine whose movement is shown in both machines. Besides that, in the third demonstration,

they have to be able to control graphical objects whose movement is shown in both machines.

There will be no meetings in December as all groups have final examinations.

3.3 Communication tutors

Prof. Lochovsky said that besides giving him reports for proof reading, all groups should seek

advice on their reports from the communication tutors.



Documents

ng-proposal...Title ng-proposal.doc Author fred Created Date 1/16/2003 2:03:22 PM