Team Whoopass

Ashley Ring
Alan Frindell

Game Name: Whoopass IV: Wrath of Whoopass
Target Platform: Windows98

How to build Whoopass IV

Load the RobotTest.dsw into Visual Studio 6.0 and select Build whoopass.exe from the Build menu.

How to start Whoopass IV

The Whoopass IV executable should be in the directory containing the images, items, robotclasses, skills, sounds, worlds subdirectories. At the prompt type
whoopass [[-n playerName] -[t { hover, johnny, dalek }] [-c gameName] |
          [ -d gameNum numDaleks]]


-n playerName                Specifies the name you want to go by in the game
-t { hover, johnny, dalek }  Specifies the class you want your robot to be
-c gameName                  Creates a new game called gameName, otherwise you
                             will have to join a game

-or-

-d gameNum numDaleks        Specifies that this should be the dalek server for
                            game gameNum, with numDaleks daleks
Just typing whoopass sets your name to "Whoopass", your class to johnny, and puts you in join mode.

Daleks are the computer generated enemies of Whoopass. They have a simple "search and destry" AI and are most deadly in large numbers. The dalek server controls all the daleks in a particular game.

1 player creates the game, up to 3 human players may join the game, and an unlimited number of daleks can be added by running the dalek server.

How to play Whoopass IV

See our manual online at http://www/~blitz/whoopass/whoopass.html. Also mirrored in this directory here.

Optional Features Completed

*Networking

Our networking uses UDP Mulitcast to transmit data between clients. For the most part it is a server-less protocol. UDP was chosen primarily for speed. TCP spends too much time retransmitting old data and sending useless header junk. By the time the old data gets to you, 10 pieces of new data have already been delayed. Each client can register a packet processor callback with the network module. The packets are read in a separate thread of execution and the packet processor is called when a packet is received. Locking issues are dealt with at the local rather than global levels.

There are two primary phases for game networking.

The "gather" phase happens before a game starts during which clients interested in hosting games wait for other players to join their game. Each game creator sends out a packet containing information regarding his game every 500 milliseconds. Every player in the join or create phase listens on 4 ports (9423-9426) and displays game information. A player can join any game that has not already started (and isn't full) by pressing 1 - 4 depending on which game he wants to join. When a player joins a game, he sends out a game information packet with his information added to the packet. The game host starts the game by pressing 's'. The only other responsibility the game host has is to seed the world with energon. For this reason, he waits 1 second after starting the game to ensure all players are in the correct listening mode, then sends the energon information. After this, the host may quit the game without aversely affecting game play.

Game state is maintained by each player broadcasting his most crucial state (position, direction, velocity, current move) every 500 milliseconds. The same information is also broadcast when the player moves or turns. Dead reckoning is used to crate smooth animation of network players. Consider this scenario: Player A pushes the up arrow key (indicating a move forward). He broadcasts his state, including his intention to move forward. All network players will update his position based on their most recent update packet, animating him from there. Within 500 milliseconds, all players will hear from him again, and update their information to keep the game in synch.

A number of other packet types are used to convey other game information:

Packet Type Function If packet gets dropped
NewEnergon All players should create a new energon at the given location There is plenty of energon in the world, this one will die eventually anyways
OpenChest All players should mark the given chest as open and not accessible to other players It does not significantly impact gameplay if two players get booty from the same chest
Animation All players should begin the specfied animation for the given player. This is used both in battle mode for weapons and wander mode for skills. Plenty of animations to go around, who wants to see them all anyways
BattleRequest The specified player is requested to do battle with the sender. This is the only packet that requires a reply. The defender must reply to the attacker with his current stats (hit points are of particular interest) Battle only takes place if both go through, worst case is you have to attack again
Attack The specified player has been attacked and should process the damage specified in this packet. Think of it as a "miss"
Deceased The specified player has died. He should exit battle mode and return to his safe zone (or to a random location, if he was a dalek) Perhaps another "reply" packet would work better here.
Gift With some probability, a deceased player will give booty to his attacker. Players don't always get gifts anyways
Quit This player has quit the game and should be removed from play. The player will be detected as having left the game automatically in 5 seconds.

*View Frustum Culling

It makes sense that we shouldn't even waste OpenGL's time rendering objects outside the viewing frustum, so we implemented view frustum culling. To obtain the world coordinates of the six clipping planes, gluUnproject is used to retrieve the 8 coordinates of the bounding volume. From these coordinates, the equations for the planes are computed and stored for later use. Because there is a lot of math involved in computing these planes, it is only performed when the camera moves.

The objects we chose to cull were robots, chests and energon. We chose not to cull walls since there are relatively few walls compared to the other objects and it is harder to detect when a wall is inside or outside of the frustum. It is possible for all 8 coordinates of a wall to be outside the frustum, but for the wall to still be visible. We figured the extra processing required for the determination would be better spent rendering the wall.

The other objects all occupy a unit cube, so it is sufficient to ask whether any of the eight vertices of a given object lies inside the frustum. If so, the object is rendered, otherwise it is skipped.

The performance increase was most significant for energon, probably because there is so much of it in the world.

Sound

The sound for the game is all handled in soundmanager.c. We support both asynchronous wav sound and CD music. For .wav sound, we use Microsoft's DirectSound API. All of the sound effects in the game are played in this way.

The CD music is used for the soundtrack for the game. We have different tracks for battle and for wandering through the world. As you switch modes, the track switches automatically. Each world file specifies the CD track that will be played as the user wanders through the world. The track for battle mode is the same regardless of the current world.

To implement CD music, we used the windows Media Control Interface (MCI) to control the CD device. We adapted Giancarlo Iovino's CdAudio class to get this to work in our program. His article can be found at: http://www.codeguru.com/multimedia/cd_audio.shtml

On-screen Control Panel

The on-screen control panel is implemented in menu.c and dialog.c. The control panel is really a context-sensitive series of menus. There are different menus for battle mode and for wander mode. The particulars are described in detail in the game manual.

The menus are drawn in the following way:

The background for the dialog is assembled into an array of colors per pixel. In order to draw the menu, we clear out the model view and projection matrices, loading an Ortho2D projection of the width and height of the screen in their place. To draw the background, we set the raster position to the desired position and call glDrawPixels on the background array. To write out the text in the dialog, we set up the orthographic 2D projection in the same way. Then we call glutBitmapCharacter for each character we want to draw.

Since the player can have any number of inventory items or skills, we made the menus scrollable. This means that there is additional logic to determine which lines of the menu ought to be visible at a given time. We made the menus transparent so that they would not fully obscure any objects on the screen.

Game Content

We created all of the 3D models in our game - including Johnny 5, Hoverbot, and the Dalek -- from scratch (kudos to Ashley for Hoverbot and the Dalek, especially).

Textures were obtained primarily from Paul Bourke's extensive online collection located at http://www.swin.edu.au/astronomy/pbourke/texture/ and the Moving Bitmaps In 3D Space tutorial located at http://www.demonews.com/hosted/nehe/opengl.htm.

Sounds were obtained online primarily from http://www.wulfert.com/theme/game-a.html and a variety of other online sources. The soundtrack contains .s3ms from Future Assassin and Nightbeat. Our alternate soundtrack feautres the London Symphony Orchestra perfoming selections from composer John Williams.

Code Credits

Some geometrical algorithms used in view frustum culling were adapted from proofs and examples from Paul Bourke's geometry website, located at http://www.swin.edu.au/astronomy/pbourke/geometry/
As mentioned above
To implement CD music, we used the windows Media Control Interface (MCI) to control the CD device. We adapted Giancarlo Iovino's CdAudio class to get this to work in our program. His article can be found at: http://www.codeguru.com/multimedia/cd_audio.shtml
We used code from /usr/class/cs248/support/src/glut-3.7/progs/advanced97/texture.{c,h} to load rgb textures.

Game Description

You are an inexperienced robot thrust into a competitive arena with other robots. To survive, you must collect resources and treasure in the world before other robots do. Above all, you must also be able to defeat other robots in head-to-head combat. If you defeat them, you'll gain experience and abilities and maybe even some of their booty.

Prepare yourself, for the world...of Whoopass

Whoopass IV: Wrath of Whoopass

Whoopass IV is a multiplayer networked game for up to 4 players per game. There can be an unlimited number of computer players. The game itself completely customizable through the various text files in the items, worlds, and images subdirectories.

See screenshots, read the manual and download the full, playable game at http://www.stanford.edu/~blitz/whoopass/index.html
Last modified: Tue Dec 7 16:34:16 PST 1999