Sujith Surendran, Sriram Viji, Satyam Vaghani
svaghani@ cs.stanford.edu, email@example.com, firstname.lastname@example.org
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
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
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.
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
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.
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 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
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
Easy Check for Features:
3D viewing objects: Being a first person 3d shooter we had this
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
Texture Mapping:Almost all out objects had texture maps. Seveal levels:
Basic texture, Light maps, Time dependant texture mapping, Transparencies
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
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.
- 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
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.