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:
37
Embed
Fong Heung Wah Lai Man Ting Lau Pui Yu Lui Chung Man, Clementfred/FYP/.../ng-proposal.pdf · FYP Proposal Report 1 1. Introduction 1.1 Motivation Game development companies like Origin
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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:
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
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.