by Genki Kuroda and three other members
San Francisco State University, Computer Science
CSc 631 Multi-player Game Development, Dr. Yoon
Computer games have been recently advanced with the development of computer graphics. At the same time, many components of computer games have been specialized into one particular complex task. We describe what we developed and our achievements.
1.2 Introduction
Tank Game is a multi-player network game. Objective of the game in single or multi-player mode is to destroy other players' tower, buildings and tanks to accumulate points. Players navigate in a urban city with buildings and towers or in open space with terrestrial settings containing hills and mountains. Each player can uses a radar system to efficiently locate and destroy its enemies.
1.3 Overview:
Tank Game is playable but it's still under development. It follows the open source philosophy which grants you total permission to freely do whatever you want with the source code. Should you feel like contributing to improvement of the game your contributions are appreciated. A better game plot would improve game playing. One idea is implemented team play.
1.3.1 Control Functionality
- Mouse (self explanatory)
- Game Pad (self explanatory)
- Keyboard
|
Turret Control: |
Tank Control: | ||||||||||||||||||||||||||||||||||
|
|
1.3.2 Screen Capture
Main Menu
Network Mode
Game in play
1.3.2 Previous Work
Tank Game was previously developed as a single-player shooting game with unfinished parts. Most of graphical features including particle engines were developed.
The unfinished parts includes a game control system such as time management, scoring system which decided who wins the game.
1.3.3 Our Achievements
Since the game was still in early conceptual and programming implementation before we took over, many features and functionalities were lacking. No network multi-player features, no collision detection and with only rudimentary graphic design for tanks and buildings. We made the following enhancements, factored code to increase graphic rendering speed, improved initializing of game, rewritten sound engine, added game pad support, converted single-player mode to multi-player mode with networking capabilities and added a new game plot objective, defending one's own towers.
1.4 Techniques
1.4.1 Game Engine
1.4.1(a) OpenGL
Tank Game fully uses OpenGL as graphical library. No other graphical library is used.
1.4.1(b) Sound Manager of OpenAL
Initially, Tank Game implemented SDL-mixer but we replaced the sound system which utilizes 3-Dimensional Audio. To accomplish the 3-D feature, we used cross-platform audio library, Open Audio Library, OpenAL.
1.4.1(c) Input Device Support
Originally, Tank Game supported keyboard input only. So we managed to add mouse and game pad support to improve the game playability and enjoyment. Especially, the game pad support improved the playability because the game pad allows us to input multiple commands at the same time while keyboard only permits a single key input. So, we can easily control a tank with game pad key to move a tank diagonally, not the combination of vertical horizontal and movement.
1.4.2. Networking
1.4.2.(a) TCP/IP
We chose TCP for networking since none of us had experience with unreliable UDP network. To enhance the network latency, TCP can be converted into UDP, but since UDP is not lossless protocol some of data can be missing or undelivered. So, we need to add extra feature to check the data integrity by making sure each data contains correct headers and size, simple checksum.
1.4.2.(b) Server/Client Architecture - Single-Thread and Multiple Thread
In terms of networking, Tank Game works as a single-thread client, and Server works as multiple threads which can accept as many as 16 clients at the same time. Each thread of Server is dedicated to communicates with a single client. Even we chose to use non-blocking socket to minimize the latency which comings from calling socket APIs, but we are not fully satisfied with the single thread client design because the single thread client cannot be halted at any moment to receive large data, which can be improved if we change into multiple threads which separates OpenGL graphical thread and networking thread.
1.4.2.(c) Real-Time, Latency
Real-Time is simply harder than any other non-real-time programs because we need to make sure any latency by processing heavy process which usually deals with networking. We tried to minimize the latency by using non-blocking socket, but single threaded client design made harder to deal with the latency. Additionally,to reduce the latency, we could add the estimate by calculating the velocity of tanks.
1.4.2.(d) Synchronization
Synchronization was done by utilizing C++ STL feature. We chose to use thread-safe data structure such as "map", "vector" as many as possible to avoid the synchronization problem.
1.4.3. Shader
Unfortunately, we could not manage to implement a shader in GLSL for Tank Game.
1.5 Difficulties
1.5.1 Collaboration with DAI Design team
We were required to work with a Design Team, but the communication between the team was not nearly perfect because development process halted a couple times to wait for the design team responses. Additionally, we didn't set the deadline of modeling products, which delayed entire development.
1.5.2 Fixing Bugs / Debugging - Optimization
We tried to optimize the program as much as we could. This was mostly by fixing existing bugs. The best optimization was done by enhancing texture manager to avoid multiple loads of same texture. Additionally, fixing memory leaks at real-time program improved the memory management.
1.5.3 Bump Mapping
Using a technique demonstrated in http://nehe.gamedev.net/data/articles/article.asp?article=20 , we attempted to add bump mapping to the game. The technique in this tutorial is simple and could be hard coded into the game with no major problems. However, since most of our textures are loaded via a TextureLoader object, it was difficult to extend this object to include a Normal Map without breaking the other textures without normal maps. For future work, the TextureLoader needs to be extended so it can also support a bump map (normal map) without breaking textures that do not have a bump map.
1.6 Possible Future Works
* GPU Programming is advised to add many graphical feature including run-time shadow, particle effects, explosion effects.
* New models can be easily imported as long as modeling format is supported such as object file with the extension .obj
* Additional image format support except TGA.
* UDP networking is advised to reduce network latency
* Estimation of position also reduces the latency and improve the game playability.
* Team play
1.7 Summary / Conclusion
We all learned the complexity of game development, and some of us gained more interest in computer graphics. A game development was challenging but it was also fun and enjoyable.
Appendix A: How to Run the Program
Complete source code and Executables are found in the link described at the top of this documentation.
After decompresssing the zip file, you will see two executables: tank.exe and MultiThread.exe in the top directory.
The tank.exe is Client and the MultiThread.exe is Server. The tank.exe needs to run at the top-level directory.
So do not move the executables into other directory.
In the menu of tank game client, "Join Game" will connect to Server and wait for other client "Start Game"
If you choose "Single Player" mode, of course, you don't need to prepare any Server.
Appendix B: Network - Server and Client Design
Limitation:
Not so efficient due to TCP overheads.
Only Little Endian is supported for both server and client.
Server cannot do multi-casting due to TCP constraint.
Server and Client won't work under the same machine.
Packet to Send:
Clients Many real time data, including tank motion, bullet vectors, status of tank.
Server All status of game such as number of tank damaged and status of tower.
Packet Syntax:
Binary Mode (just a copy of class in string), the first byte is an ID to determine which implies class type.
After sending a packet, always wait for ACK command. (This is the same to both Server and Client)
Client Architecture:
Single thread shared with OpenGL thread.
Sends Motion of Tank, Bullet Vector, Tank Power
Server Architecture:
Run as a separate process with tank game.
Keep track of all data send by clients.
Keep track of play time e.g 5 minutes time elapse.
Appendix C: List of Tools that We Used for Development
* Visual Studio 2005 for C++
* GPU Programming is advised to add many graphical feature including run-time shadow, particle effects, explosion effects.
* New models can be easily imported as long as modeling format is supported such as object file with the extension .obj
* Additional image format support except TGA.
* UDP networking is advised to reduce network latency
* Estimation of position also reduces the latency and improve the game playability.
* Team play
1.7 Summary / Conclusion
We all learned the complexity of game development, and some of us gained more interest in computer graphics. A game development was challenging but it was also fun and enjoyable.
Appendix A: How to Run the Program
Complete source code and Executables are found in the link described at the top of this documentation.
After decompresssing the zip file, you will see two executables: tank.exe and MultiThread.exe in the top directory.
The tank.exe is Client and the MultiThread.exe is Server. The tank.exe needs to run at the top-level directory.
So do not move the executables into other directory.
In the menu of tank game client, "Join Game" will connect to Server and wait for other client "Start Game"
If you choose "Single Player" mode, of course, you don't need to prepare any Server.
Appendix B: Network - Server and Client Design
Limitation:
Not so efficient due to TCP overheads.
Only Little Endian is supported for both server and client.
Server cannot do multi-casting due to TCP constraint.
Server and Client won't work under the same machine.
Packet to Send:
Clients Many real time data, including tank motion, bullet vectors, status of tank.
Server All status of game such as number of tank damaged and status of tower.
Packet Syntax:
Binary Mode (just a copy of class in string), the first byte is an ID to determine which implies class type.
After sending a packet, always wait for ACK command. (This is the same to both Server and Client)
Client Architecture:
Single thread shared with OpenGL thread.
Sends Motion of Tank, Bullet Vector, Tank Power
Server Architecture:
Run as a separate process with tank game.
Keep track of all data send by clients.
Keep track of play time e.g 5 minutes time elapse.
Appendix C: List of Tools that We Used for Development
* Visual Studio 2005 for C++
* Photo Shop ver.7
* Nvidia Normal Map Filter for Photo Shop: http://developer.nvidia.com/object/photoshop_dds_plugins.html
* Blender ver.2.37 for 3D Modeling http://www.blender.org/
* Doxygen for documentation. http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc
* Graphiz http://graphviz.org/Download_windows.php