Drop Drop
Technical Design Document
Game Mechanics 3
Platform and OS 3
Minimum System Requirements 3
Reccomended System Requirements 3
External Code 3
Simple Directmedia Layer (SDL) 3
OpenGL 3
Xerces C++ 4
zlib 4
HawkNL 4
JDZ 4
Game Object Data 5
Inheritance Tree 5
Object Manager 5
Data Flow 7
Menus Data Flow 7
Core Data Flow 7
Pre-Game Networking Flow 9
In-Game Networking Flow 11
Game Implementation 13
Artificial Intelligence 13
Physics 13
Objects 13
Collisions (collsion resolution) 14
Timer 14
Networking 14
Overall Networking Design 14
DDNP 16
Packets 18
Thread 19
Optimized Networking for LAN 21
User Interface 22
GUI Object Data 22
Inheritance Tree 22
Controls 24
Input Engine 24
Implementation 24
Art and Video 25
Rendering Engine 25
Implementation 25
cOGL 25
c3DbaseUserModel 28
c3DbaseObject 29
c3DbaseModel 29
cBaseTexture 30
cImage 30
Specifications 30
Artist Instructions 30
Sound and Music 31
Level-Specific Code 32
Levels Overview 32
Cage File Format 32
Memory 34
Memory Allocation 34
Memory Map 35
Risk Analysis 36
Development Tools 37
Map Editor 37
Recommended Coding Standard 39
Naming Convention 39
Variables 39
Pre-variable tags 39
Variable Names 39
Variable Types 40
#defines 40
Examples 40
Functions 40
Methods (member functions) 41
Functions 41
Macros 41
Examples 41
Commenting 41
Header Comments 41
Types of Comments 41
Defining Comments 42
In Code Comments 42
Layout 42
Inline Assembly 42
Team Sign Off 43
Game Mechanics
Platform and OS
Drop Drop has been designed with portability in mind. By using platform independent libraries, it is theoretically possible to port it to several different architectures and operating systems. Our main platform for development and release are the Windows operating systems newer than Windows 98. However, the game also runs on MacOS X and UNIX/Linux platforms and will ship simultaneously on those.
Minimum System Requirements
· Pentium™-III processor at 500MHz or better
· 128MB System Memory
· 20MB available hard disk space
· 56K modem or Broadband internet connection
· Hardware support for OpenGL
Reccomended System Requirements
· Pentium™-III processor at 800MHz or better
· 256MB System Memory
· 20MB available hard disk space
· Broadband internet connection
· Hardware support for OpenGL
External Code
Simple Directmedia Layer (SDL)
The Simple Directmedia Layer (SDL) is a cross-platform library for common game tasks. It includes functionality for setting up the game window and interfacing with the OS, playing sounds and CD-ROMs, interfacing with OpenGL, input gathering from keyboard, mouse, and joysticks, and multithreading. We will be using SDL for the low level interfacing with the OS, such as input gathering, setting up the OpenGL window where the game will be drawn, playing our simple sound clips, and doing multithreading for the networking.
SDL is available to us under the GNU Lesser General Public License (LGPL). Under those terms, we are allowed to use the library free of cost as well as redistribute it. However, if we make any changes to the library, we must provide those under the LGPL as well. We do not have any plans to make modifications to the library.
http://www.libsdl.org/
OpenGL
OpenGL is a widely used graphics API. We will use OpenGL 1.2 for all of our rendering requirements. This includes two-dimensional entities and three-dimensional models. OpenGL is widely available with many versions of windows as well as other operating systems such as MacOS X and Linux.
http://www.opengl.org/
SGI, the owners of OpenGL, do not require software developers to license OpenGL. Therefore we are free to use the library.
Xerces C++
Xerces C++ is a library for loading and parsing XML files. It is robust and includes many advanced features such as support for Schema and DTD. We will be using Xerces C++ for loading menu files specified in XML format. For example, we might have a mainmenu.xml file that, when loaded by Xerces C++ and interpreted by the game, would produce a functional main menu screen. We will also use Xerces C++ for loading in files that contain data about model animations and model files. We feel this is important because it gives us a standard and flexible way to load in data, instead of having to build a format ourselves and parse it. Additionally, we will produce DTD files for automatically validating our XML documents.
Xerces C++ is available under the Apache license. Under this license we may use the library free of charge as well as redistribute it.
http://xml.apache.org/xerces-c/
zlib
zlib is a general purpose compression library. It provides good compression quickly on general data that we might like to compress. zlib will be used by Drop Drop’s JDZ file loading (see the section on JDZ). JDZ files internally use zlib to compress the data they hold.
zlib is available under the zlib license. Under this license we may use the library free of charge as well as redistribute it.
http://www.zlib.org/
HawkNL
For cross platform networking we will be using HawkNL, which is a free game-oriented network API. This low level API wraps around the operating system’s native networking sockets, making it usable on multiple platforms such as Windows, Linux, and MacOS.
HawkNL is available to us under the GNU Lesser General Public License. Under those terms, we are allowed to use the library free of cost as well as redistribute it. However, if we make any changes to the library, we must provide those under the LGPL as well. We do not have any plans to make modifications to the library.
http://www.hawksoft.com/hawknl
JDZ
JDZ files contain many files within them in a similar manner to PAK, MPQ, or ZIP. Those files are individually compressed and then stored into the .JDZ file. JDZ uses the zlib library to compress and uncompress the contained files. When the user extracts a file, only the file that is being extracted is loaded from the file and into memory. This is possible since the JDZ stores the files individually compressed and therefore it is possible to determine which portion of the JDZ file contains the desired file. This means that files can quickly and efficiently be extracted from the JDZ file. The JDZ format and accessing tools were internally developed prior to the start of GAM300 and contain no external code, with the exception of the zlib general-purpose compression library (see the zlib subsection of the External Code section).
Game Object Data
Inheritance Tree
Object Manager
The object manager is the interface to all the objects in the game. The object manager will recieve all the mail sent for an object and forward it on to the specific object. This way the mail center doesn’t have to interface with the specific object it is delivering mail to. The object manager will handle all the objects in the game by keeping a pointer to them. Each object in the game will have an unique ID that is global throughout the network. This means that the same coin on two computers playing a networked game of Drop Drop will have the same ID. When a client gets a periodic update, it will call the object manager to update the data of all the objects referenced in the packet. It uses the global ID for the object to identify the object on the client’s side. After all the objects have been updated, the object IDs in the delete list will be deleted if they still exist and haven’t been deleted during a previous update. After a few seconds of an object being on the delete list, the server will remove it under the assumption that all the clients have received at least one update message with the object on the delete list.
The global ID is also used by the mail center to identify who each message is for. This is because messages are sent more often than just specific objects and therefore the first 200 IDs are reserved for components like the network system, input engine, graphics engine, timer, and so forth. Also, the IDs from 200-255 are also reserved for the objects in the game that will stay around throughout the game, such as characters, the pong ball, and moving bumpers.
The object manager will need to use a better storage method for the objects in the game then a simple linked list. A hash table combination with a link list could help cut down the time to search for an object by the size of the hash table. The object manager will also have to make sure it has the Character Mutex whenever it views or updates a character in the game. This is to make sure that the game remains thread-safe. Characters will be kept in a certain range for their ID; probably from 200-219, but this could change if there are ever more then 20 characters. So the object manager will easily be able to identify a character from any other object just by looking at the object’s global ID.
Data Flow
Menus Data Flow
Menus are made up of pages such as “Sound Options” or “Chat Lobby.” Pages are made up of widgets such as push buttons and list boxes. Input data will be passed to the current page. When the current page receives that data, it will interpret it and send it to the currently focused widget, in the case of keyboard data, or to the widget that the data hits, in the case of mouse data. Once the widget has received the input data, it will then perform actions specific to the widget. For example, if a left mouse click occurred at pixel (50,50) on the screen, the click would be handed to the current page of the menu, then to the push button at (50,50) in the page, and then the push button would emit a clicked() signal. That signal will basically just call a list of callback functions that have been connected to it. In the example situation, the push button may have the text “quit game” and the CleanupMemory() and QuitGame() functions connected to it. In that case, the CleanupMemory() function would be called, and all memory cleaned up, and then the QuitGame() function would be called, and the game would quit.
Core Data Flow
The game flow is based around a simple mail system. All types of information, such as keyboard input, network packets, timer events, removing objects, and so forth, are sent as messages to the mail center. The mail center will have two queues where messages are stored; one is for the main thread to post on and the other is for any thread which is not the main thread of the program to post on. When the mail center is told to deliver its mail, it empties out the main thread queue and then the other thread queue. The main thread queue will only have a push onto the back of the queue, but the other thread queue will allow full access to the queue. This is because the network will need to check the contents of the queue for messages that are out of date when it is placing a item in the queue. A normal push will also be supported.
When a message needs to be sent somewhere there are two ways to do it. The first is to post the message in the mail queue. This means the mail will be delivered when the mail system gets around to it. If the message needs to be received right away, or a response is needed immediately, a message can be sent instead of posted. When a message is sent, the reciever will receive it right away and a response in the form of an integer will be returned to the sender of the message. During a networked game, the mail center may redirect a message to networking, or make a carbon copy and then send that to networking, because the message may need to be verified by the server or a message from the server may need to be sent to the clients. When a message is sent, the sender of the message will have to delete it. This is unlike posting a message, in which case the mail center will delete the message after it has been delivered.
The game’s main loop will be executed each frame. It will start by checking input. If any useful input events are found, a message will be sent to the correct destination, such as the character being controlled by the computer. After the input, the timer will be checked. The timer will then check all the registered timer events that it needs to and then send messages to the mail center in response to any timer events happening. Then after the timer events are checked, the mail center will deliver all the mail in the queues to the appropriate place or places. After a peice of mail has been delivered, the mail message will be deleted.
After the mail has been delivered the object manager takes control to calculate the expected positions of all objects in accordance with their physics and the time elapsed. Then collisions are calcuated and then resolved. After all the collisions are resolved, the collisions will be checked again and this will repeat until there are no more collisions that need to be resolved. Then the object manager will set the new postions from the results of the collisions and resolutions. Then the screen will be rendered to finish the current frame and the process will start all over again.