Satyam Vaghani's Homepage

Pulse

Sujith Surendran, Sriram Viji, Satyam Vaghani
svaghani@ cs.stanford.edu, sujiths@stanford.edu, sviji@stanford.edu

About Pulse

Pulse is an intense first person shooter which would absorb the player in an environment filled with vivid graphics and sound. The competition would be against only the best opponents, other people playing from their secluded hideouts on the network, with only one goal: to defeat you.

Welcome to the battlezone

Game Play

Pulse used complicated maps that were designed with death match style play in mind. It allowed for the easy use of 'bsp' maps which could be imported from quake which led to a large pre-existing selection of maps, with complex worlds allowing for interesting game play.

To make the game more that just a first person shoot-'em-up game, Pulse tried to create random and player invoked changes in the game environment. The most impressive is the Pulse mode, where the player invokes time dialtion. Time slows down making all other player move slower, giving the user a speed advantage. Also the background music becomes your hearbeat and the textures on the map change to Matrix style green characters, sharply contrasting players from the map.

Lights off - IR Glasses to the rescue

The server also had the capability to randomly affect environment settings by invoking fog as well as switching off lights through the map. The players also had the ability to pick up and carry Infra Red (IR) glasses which they could use to see in the dark till the lights came back on!

Fog makes matters worse!

There was a choice of three weapons to choose from, the pistol, which was the standard start weapon, packs quite a punch but has a small clip and a low rate of fire. The maching gun could be obtained which has a 40 bullet clip with a much higher rate of fire, but each bullet does little damage. The rocket launcher was the third weapon, packing quite a punch with explosive rockets. Be warned of its slow rate of fire and reload times.

Each player had a head up display (HUD) indicating his inventory as well as health and his ammo information, which changed as he used or gained items.

Graphics

Pulse used a lot of optimization in its graphics display so as to render a complex and realistic scene with as little effort as possible. It provided the ability to view complex maps with complex lighting at very little cost.

The special features used for this rendering include several types of culling. View frustrum culling was implemented so as to draw faces of the map that lie within the players view. Portal culling was implemented using the data information in the BSP tree structure which leads to information on which nodes in the tree are visible from the current node. This leads to efficient elimination of faces in the rendering process. Depth culling was used to not draw planes too far away from the viewer.

You can be 'The Chosen One' and move faster than the others. Remember the Matrix?

The texturing in Pulse is quite complex and uses several overlayed textures. There is an initial tetxture that represents how the basic surface should look. Over this, a light map is textured which generates complex realistic looking maps at very little extra cost. The light map is pre processed during level construction and does not require computation during game play. Transparencies were also used to show lighting effects and transparent textures in the game. The last feature implemented in texturing was moving textures based on a predefined mapping function which was time dependant. This allows waving flags as well as moving clouds and skies. The sky effect is particularly cool as it overlays transparent textures at different speeds.

The Sky adds-in to the fear factor

Lighting effects were used to do overall lighting effects such as regular ambient light, or darkness (as decided by the server) or infra red lighting.

Collision Detection

Pulse has quite a comprehensive set of geometric definitions, which can be used to represent objects in the world and most of these objects can effectively determine collisin with each other. This proved to be very useful to generate on the fly collision detection where required.

The most interesting part behind the collision detection is the use of the BSP tree. The BSP tree has a list of bounding boxes for each node and therefore the tree is traversed for a given object and branches are rejected or accpted based on the parent nodes, which lets you traverse to the required are in log(number of nodes) time. This allows detection for each player with checks to only about 30 nodes and then the objects in the required node(s). The entire player movement behavious is based on collision detection and the algorithm was refined to allow the player to climb steps as well as slide along surfaces, by applying normal forces on the player based on the surfaces he collides with.

Each bullet/projectile used ray collision detection to determine the point of impact on the map, and this required great efficiency as there could be several projectiles flying around at any given time.

Gravitational forces were implemented on the players and this allowed realistic jumping and falling (with acceleration), and then they would stop upon hitting a wall. Another special feature we got working was that players would also slide down slopes (on the ramps of staircases) due to gravity.

Animation

Each of the models in Pulse had a heirachical structure of models, and each model itself could be seperated into parts with bounding boxes. Each part was then attached to another part creating a heirarchy. Each part had an origin for transforms, allowing easy transformations and animation.

The models for the players were imported from Half-Life Counter-Strike mod and the models were animated by us using our structure and then developing a set of actions and their respective animation sequences. This animation was generated from a script file we wrote at the beginning of each session.

Animations included standing (in which the player moves as he breathes), running and jumping, as well as smooth transitions between the actions, giving a very realisitic player.

Networking

Pulse was designed as a multiplayer networked game and could run servers on windows as well as linux boxes. The servers accepeted connections from up to ten people (tested with up to 3) and resolved gameplay issues. It was designed to be as robust as possible so as to allow clients to connect and disconnect without affecting overall gameplay.

The size of network packets was a critical issue and we tried to minimize the communication that was required between the players and the server so as to allow more players to join a given server.

Each of the players would connect to a server to join in the game. The server mainly forwarded events recieved from each of the players to all others. It would also store the state of the game so that it may be transferred to any new player. Periodic updates of the player position could be sent every display cycle if players moved a lot.

For projectiles the velocity, initial position was sent to all players once. Each player was then responsible for rendering and interpolating the position of the projectile. However the player who fired the projectile was responsible for the resolving the collision detection and removal of the projectile. He would determine who took damage. This helped resolve ambiguities due to lag in the network. For weapon/ammo/powerup pick up the server would resolve who actually gets what and return the events to the players.

Sound

The sound system for Pulse supported multi-channel sound, which could be loaded up from wav files. It allowed as much control as desired over each audio sample that needed to be played. It allowed priorities to be set for sound so as to play only the most important sounds in case of an overload. However the 32 channel sound never gave any problems.

The sound system allowed background music to go on throught the game uninterupted. It allowed control over the position of a sound, creating the necesarry stereo effects. Sounds could then be heard in the right direction and distance.

Game Editor

Our game is general enough that it can support any Quake3 bsp world. We ended up using a lot of models we picked up of the web. To deal with the many formats we converted all of them to openGL display lists using 3D exploration. We then converted that into out proprietary format which would allow us to load them in at run time. We could then alter our models without changing code/re compling. We could also configure models to be composed of other simple models. Each component could be given an offset, orientation and scale.

Easy Check for Features:

3D viewing objects: Being a first person 3d shooter we had this covered
User Input: We stuck to a mouse/keyboard combo
Lighting and smooth shading: We had materials and smooth shading for almost all our entities. We used lighting for the infra red mode, we also used "Black light" to simulate darkness. Light maps were used in the textures.

On-screen control panel: We had a nifty alpha blended panel which had images of our weapons/ammo/powerups and health,ammo displays. The selected items were higlighted.
View Frustum culling: The list of faces in our map which fell in our view frustum were generated and displayed.
Portal culling: Visibility information on each portion of the world was pre computed and stored. This gave us another way of cutting down on unnecessary rendering. Even with moving objects we could compute that given its present location could it be seen by the viewer.It would be possible to judge if there are many things to be rendered at a scene and depending on that we could crank up/down the quality of rendering(we didnt actually do this,but we could potentially have done a level of detail based on computing resources as opposed to distance).
Depth culling: Objects far away from the viewer are clipped.
Procedurally generated modelling: We used generated textures to give the effect of moving clouds and fluttering banners.
Collision detection: We leveraged off the bsp tree of the world for collision detection between moving objects and the world.Given the position of an object we could filter down to the area where collision needs to be done. We ran a bounding box down the bsp tree to determine where exactly the collision took place. Further after colliding with the map a player would be given a reactive push. Thus a player could slide against a wall, climb stairs, even fall through elevator shafts.
Simulated Dynamics: We had gravity. The combination of collision detection and gravity allowed a player to stand on the map and not fall through it. All the models in our game were hierarchihcally structured.For the player we had a richly modeled movement behaviour. A player when standing would seem to breathe. A sequence of motions were given when moving. Similarly while jumping there was another sequence of motions. All the seperate motions were transitioned smoothly.
Sound: We had mutli channel sound.Movements of players were also rendered through sound (foot steps). For projectiles we had directional sound ,which dimnished as the proejctile moved away. We also had background music playing.
Networked multi player: Supports up to 10 players connecting to a single server. - Game Editor: none created but we used a standard quake bsp format for which editors exist.

Resources

- Fmod libraries used for platform independent sound
- OpenGl, glut libraries used for display
- HawkNL libraries used for platform independent networking
- Quake specs used as a reference in reading in maps
- AfterShock code used as a reference for understanding bsp trees
- 3-D Exploration and Maya used to convert and animate models
- coldet v1.1 used as a reference for collision primitives
- Maps,textures from PlanetQuake
- Counter-Strike model imported for players

Installation

Windows version: Unzip gamesource.zip Open the games.dsw workspace in the gamesource directory using MS VC++. Set as active project the server files project.Build and execute. That starts the server. Preferably on another system unzip gamesource.zip. Open games.dsw .Set as active project the gamefiles project. Set the arguments to the ip <address of the server>:<port - it is 11248>. Build and execute. Clicking "Play" will hook you to the server and begin the game. Similarly other clients may join in.

We also have a linux version of the game.