Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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.
FYP Proposal Report 2
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.
FYP Proposal Report 3
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.
FYP Proposal Report 4
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.
FYP Proposal Report 5
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.
FYP Proposal Report 6
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
FYP Proposal Report 7
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
FYP Proposal Report 8
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
FYP Proposal Report 9
• 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
1.2.11.1 Description
This is a class of items whose effects may be avoided by a victim.
1.2.12 CNonAvoidable
1.2.12.1 Description
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
1.2.13.1 Description
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
1.2.14.1 Description
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.
2.1.2.2 Preconditions
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)
7. The use case ends.
2.1.2.4 Subflows
None
2.1.2.5 Alternate Paths
A1: If no Client Players have joined the game and the Server Player chooses to launch the
game, an error message will be printed on the screen and the system will return to
step 6 of the Basic Path.
2.1.2.6 Post Conditions
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.
2.1.3.2 Preconditions
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.
6. The use case ends.
2.1.3.4 Subflows
None
FYP Proposal Report xii
2.1.3.5 Alternate Paths
A1: If the server with the entered IP address/host name cannot be reached, an error
message will be printed and the Client Player is prompted to enter a valid IP
address/host name or to terminate the use case.
2.1.3.6 Post Conditions
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
This use case is invoked by Player.
2.1.4.2 Preconditions
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.
3. The use case ends.
2.1.4.4 Subflows
None
2.1.4.5 Alternate Paths
None
2.1.4.6 Post Conditions
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
This use case is invoked by Player.
2.2.1.2 Preconditions
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.
4. The use case ends.
2.2.1.4 Subflows
None
2.2.1.5 Alternate Paths
A1: If the increased speed of the Player exceeds the maximum speed allowed, the speed is
truncated to the maximum speed allowed.
2.2.1.6 Post Conditions
None
2.2.2 Decelerate
This use case shows how players decelerate their characters.
2.2.2.1 Actors
This use case is invoked by Player.
2.2.2.2 Preconditions
The game has already started.
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)
3. The system renders the updated character.
4. The use case ends.
2.2.2.4 Subflows
None
2.2.2.5 Alternate Paths
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
2.2.2.6 Post Conditions
None
2.2.3 Change Orientation
This use case shows how players change their orientation.
2.2.3.1 Actors
This use case is invoked by Player.
2.2.3.2 Preconditions
The game has already started.
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.
3. The system renders the updated character.
4. The use case ends.
2.2.3.4 Subflows
None
2.2.3.5 Alternate Paths
None
2.2.3.6 Post Conditions
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
This use case is invoked by Player.
2.2.4.2 Preconditions
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)
5. The use case ends.
2.2.4.4 Subflows
None
2.2.4.5 Alternate Paths
A1: If the victim is protected by CProtective items, then the victim is not affected by the
FYP Proposal Report xv
offensive item.
2.2.4.6 Post Conditions
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
This use case is invoked by Player.
2.3.1.2 Preconditions
The game has already started.
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.
4. The system renders the updated character.
5. The use case ends.
2.3.1.4 Subflows
None
2.3.1.5 Alternate Paths
None
2.3.1.6 Post Conditions
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
This use case is invoked by Player.
2.4.1.2 Preconditions
The game has already started.
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.
4. The system renders the updated character.
5. The use case ends.
2.4.1.4 Subflows
None
2.4.1.5 Alternate Paths
None
2.4.1.6 Post Conditions
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
This use case is invoked by Player.
2.5.1.2 Preconditions
The game has already started.
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.
3. The system renders the updated character.
4. The use case ends.
2.5.1.4 Subflows
None
2.5.1.5 Alternate Paths
None
2.5.1.6 Post Conditions
None
2.5.2. Land
This use case shows how players land from the sky.
2.5.2.1 Actors
This use case is invoked by Player.
2.5.2.2 Preconditions
The game has already started.
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.
3. The system renders the updated character.
4. The use case ends.
2.5.2.4 Subflows
None
2.5.2.5 Alternate Paths
None
2.5.2.6 Post Conditions
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
Place: Room 3464, HKUST
Attending: Connie Lau, Mandy Lai, Fong Heung Wah, Prof. Lochovsky, and other groups
of this project
Absent: Clement Lui
Recorder: Mandy Lai
1. Approval of Minutes
The minutes of the 1st meeting were submitted for approval.
2. Report on Progress
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.
4. Meeting Adjournment
The meeting was adjourned at 5:20 p.m.
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.
Place: Room 3464, HKUST
Attending: Clement Lui, Prof. Lochovsky, and other groups of this project
Absent: Connie Lau, Mandy Lai, Fong Heung Wah
Recorder: Clement Lui
1. Approval of Minutes
The minutes of the first meeting were approved by Prof. Lochovsky.
2. Report on Progress
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.
4. Meeting Adjournment
The meeting was adjourned at 5:15 p.m.