CS248 Final Project Report 12/07/99 Team: mazewar Platform: PC ( OpenGL + DirectSound + TCP/IP ) Member: Xiaofeng Ren, Bin Li, Quanqiu Wang 1. How to run the game? Requirement: win9x/NT, DirectX ( DirectSound ), TCP/IP networking To start a game in single player mode ( or server mode ), simply use command 'mazewar'; use 'mazewar server_name' to start a client which automatically connects to the server, server_name refers to the server's host name ( or IP address ). * Please run our program on a windows machine with sound card and DirectX support. If there is any problem in making the program run, please let us know and we could give more details of the development environment. 2. How to play the game? The game environment is a maze, in which one family of mechs fight with the other. The controls are standard: use the four arrows keys to move yourself, use the space key to fire. There are two additional keys, 'd' and 'f', which allows you to move in the lateral direction. Health, score, and remaining bullets are displayed on the panel to the right of the screen. The health ( equivalently, energy level ) will be gradually restored. Each time you eliminate one opponent, the score increases by 1. In a networked game, players were designed to cooperate; but you can choose to fight each other too. 3. Features -- Lighting and smooth shading Inside our maze, we can specify several lights ( at most eight). To do lighting, we set up light sources, set up materials, and specify geometry with normals. Also the lamps on the wall could be toggled on as light sources; however it tends to slow down the program and breaks the overall feel of the scene. We recommend running the game with the lamp lights off ( default ). -- Texture mapping We implement texture mapping for the floor, the ceiling, and all the walls inside our maze. Steps: Use the code provided to read RGB files. Establish texture context. Load the texture. Use the texture for the geometrical primitives. -- Sound DirectSound is used in our project to play sound and music. The original C++ code is from a sample program in DirectX SDK. Secondary DirectSound buffers are used since we want the automatic mixing feature. We have made significant changes to the code so that now our game supports playing multiple sound effects at the same time. We have background music, gunfire effects and explosion effects in the game. -- Collision Detection The movement in the maze is essentially 2D. This makes the collision detection relatively simple. It's based on the 2D distance between two objects, or between an object and a wall. The sizes of objects are specified in model.cpp. To detect whether a bullet hits an object is more complicated, since the bullet could move at a high speed. We implemented a general Clear function, which is also used to determine whether an object is occluded by others when a mech attempts to shoot. Using the Clear function we determine whether the bullet hits anything along the way between two updates of the scene. Analytic appproach is possible but hard to implement and not easy to adapt to changes in game design. Hence we used a sampling technique, essentially checking all the positions along the path, see if any collision has happened. -- View Frustrum Culling Culling is essential to the performance of our game since we have a large world and possibly many objects. On the other hand, it's easy since we are in a world consisting of cells. For every update of the scene, each cell is determined whether it's in the view frustrum or not. Only culling in the horizontal direction is considered; there is no culling in the vertical direction, due to the structure of the scene. An angle is computed, and if it's larger than the field of view, it's marked as invisible. -- Occlussion Culling This is also cell-based, not hard to implement but it reduces the visible cells to usually 5 - 15, and makes it feasible to play the game in real time. The four corners of a cell is each checked for visibility; if all of four are occluded by other cells and hence invisible, the cell is marked invisible. All objects in an invisible cell are not drawn. -- Levels of Detail Control The original modes are fairly complex and envolves a large number of triangles. Using a free tool LODESTAR ( see reference ), we reduced the models to different levels of detail, and used them in the game. The control is quite simple: there is a base level which can be adjusted from the menu; starting from the base level, a distance-based criterion is based. The farther away an object is, the more simple model we use. -- Motion Animation We didn't have access to any motion capture data, so we did the decomposition and refinement of poses manually. The sequences we finally used include a 8-step walk sequence and two 5-step rotation sequences. To integrate motion control with collision detection and AI, the state of a computer-controlled mech is divided into several levels. The lowest level is the Action Level, specifying which action ( walk, turn, stand, peek, shoot, etc. ) the mech is performing and which step of the action it is in. The intermediate level is the Tactic Level, specifying the intention that the mech wants to turn to a specific direction, or want to go to a certain cell. The highest level is the State, the mech could be patrolling, attacking, retreating ( not implemented ), etc. And lower-level variables are set according to the high-level variables. -- AI We have used a few simple techniques to enhance the AI of the game. Every computer-controlled mech is supposed to have a remote sensor, and it can determine the position of a player-controlled mech once it's within a certain range. A simple path planning algorithm ( use value iteration ) determines the closes way to reach the player-controlled mech. It's invoked when the object can not be seen and/or it's getting out of attack range. The mech will enter a 'maneuver' mode when it gets close to the object to attack and fires. No sophisticated AI techniques are used here; it just moves randomly to survive the bullets. ( The bullet is assumed to move fast and there is no time for reaction. ) -- Network we choose UDP socket for its speed advantage over TCP socket. It seems reliability, that is, loss of packets, is not a very big problem here. First because the network we are using is fairly reliable. Second, the missing packet may manifest only as key stroke not registered, or some small jitter in the game. It should not cause much uncomfort for the user. When the program is run without argument, it automatically run as a server and handle connection from clients. When the program is run with a argument, i.e., the remote machine name, it will run as client and try to connect to the specified remote machine . The server and clients exchange packets between each other. When a client make a move, it will send a packet to the server. The server will update the game status according to the events of itself and events from clients. And the game config is encapasulated in a packet and send to all clients. The clients will update the game config according the newest server packet. We intend to use packetNo to maintain the order of packets. We also keep the time when the packet is receiced. The timing can serve several purpose, to make sure we received packet is recent and to log when do we last heard from client or server. This information is used to check the server and client status. -- Game Level Editor Game level editor enables the user to specify the layout of the wall, the position of light , robots, and players. It is required that the map contains at least self, that is, myself. Otherwise the editor will not save and exit. It is a orthogonal view of a map, the position of the map is determined by the position of mouse. The user can pick a object to draw from a panel. Then the user can start to draw in the drawable map region. And the objects on the map can be "brushed away" by the brush , which simply remove any objects in the cell where the brush is applied. The editor also enable the user to choose the map size, player numbers etc from menu selection. The map infomation is then saved in a 'mwar.map' file , which can be readed by the game program by moving the file to the game directory and renaming it to 'mazewar.map'. -- On-Screen Panel The control panel is meant to be what the player should see inside the mech, that is, a round window of the scene , and some display and control inside the machine. A control panel is added to display the game information and enable some user input. It is drawn on top of the main display with a orthogonal view projection. The side of the window is drawn using triangle and quads. The user info including bullets,score,health and message are passed on to the drawing function as a CInfo object. The information is then drawn at appropriate places. Message is drawn on the bottom, ie , message board. Health info is displayed as a clock, which shows the percentage of the player health. Also a map is also displayed. The postion of the players and robots are drawn on the map to provide a overhead view of the maze. We haved originally wanted to let the user choose weapons from the control panel. This is done by the mouse function, which will change the user weapons if appropriate region is selected. This feature is not drawn on the panel yet because we didn't have time to implement the weapon change in the game. -- Procedural modeling We use particle systems to model fire. The used method is briefly described in Chapter 20 of the textbook. We specify the initial particles with positions, moving directions, velocity, and colors. The position of each particle at subsequent times is computed by adding its velocity vector to its current position. We add some control over the shape of the fire, and the color changing mode of the fire. 4. External Resource The two 3D models, sound files, and the texture images are all free resources from http://www.3dcafe.com/. The original 3D models are under ./external/. They are converted into C code by 3D Exploration from XD Software. The code for reading RGB images is provided to us. The code for reading WAVE files and playing streaming DirectSound buffer is adapted from a Microsoft DirectX SDK sample. The model decimation is done using the free tool LODESTAR from http://www.cg.tuwien.ac.at/research/vr/lodestar/.