Summary and Goals: |
|
| Survival of the Fittest is a 2-D battle simulation. The game is designed to be networkable for four players. Each player controls one military vehicle with which he can maneuver around the game area. The game area itself is comprised of ten different textures including open areas and barriers. |
Team Members: |
Expertise and Responsibilities: |
| Mark Hayes | Sound |
| Jay Ingalls | Game Play and Graphics |
| Jeremy Stoppelman | Networking (and Team Leader) |
| Jesse Wyant | Graphics |
Game Play: |
|
| The game is centered around multiplay. A maximum
of four players can participate in a game. The object is to destroy all
enemy tanks. Each player controls his tank via the keyboard. A
specialized handler replaces the DOS interrupt service to provide for the
up, down, left, and right arrows controlling tank movement and space bar
firing the turret.
Game play is controlled by the main loop. From this main loop all other functions are called. In the process of one iteration of the loop, the movement and direction flags are checked to see if the tank is moving and in which direction. New positions are calculated for the player's tank as well as the player's projectile, they are checked to see that the tank will not collide with any obstacle, and the player's coordinates are updated. Then there is a check to see if any projectiles have hit the tank and if so the player's strength is reduced. The strength is then compared to zero to determine if the player is dead. When a player dies, his position returns to the initial position, his strength is restored, and a kill is given to the enemy that fired the fatal shot. Calculations are made to determine which sounds are to be played, if any. Calls are then made to draw the new updated screen, play the sound, and transmit the player's new data to the server. | |
Graphics: | |
The graphics portions of Survival are comprised of a player's individual view of the world (a 240x200 pixel portion of the much larger world map) with their tank centered in the view, and the status bar to the right side of the screen (an 80x200 textured section) containing a scaled-down view of the world map with colored pixels representing the placement of the opponent's tanks. Below this miniature world map is a list of the four players (color coded) where, along with the player's name, is the multi-segment strength or armor bar and the number of kills attributed to that participant. A tank may fire a projectile at other visible (on their view-screen) tanks to inflict damages; or drive around--causing the background terrain and visible opponents to scroll in the opposite direction, lending the perception of motion. As the four participants' tanks move around on the world map, their relative positions are indicated on the miniature world map. The four (or less) vehicles have a colored square (floating above the left of the vehicle) for visual identification. Issues surmounted: how to quickly pull out arbitrary sections of a particular tile in the texture segment and write that to the screen buffer to `scroll' that portion of the view, and iterate for the edges and center tiles alike, etc. | |
Sound: | |
| Survival of the Fittest utilized both MIDI music and digital sound effects. Fire effects were be implemented. Additionally the SF theme song (really the A-Team theme) plays throughout the bloody melee. The game supports SoundBlaster compatible sound cards (which can play 8-bit wavs). Any DMA and IRQ configuration is acceptable. | |
Networking: | |
|
The multiplay feature of this game is implemented though NETBIOS. Because
of class requirements, networking was built in a client-server
fashion. A separate program provided packet compilation and
forwarding to the 4 (or less) clients. This was accomplished through a
combination of multicasting and unicasting. The server recieves packets
from the clients, compiles the data and then broadcasts this information
in a single packet to all of the clients (using a group send). Clients
send updates to the server by sending packets to the machine name (unicast).
Some of the challenges that were faced: Timing, how often and when to send packets? How do you wait for all players to join in? How do you allow 4 or less players? The separate server software that was written had a text mode video interface. It displays which players logged in and their coordinates. The client software will be built into the game, a wait message is present until the clients have recieved a game start signal. | |
|
Networking data structures:
SERV_DATA struc ; broadcasted to clients
pos_ax dw ? ; player_a x coord
pos_ay dw ? ; player_a y coord
pos_bx dw ? ; player_b x coord
pos_by dw ? ; player_b y coord
pos_cx dw ? ; player_c x coord
pos_cy dw ? ; player_c y coord
pos_dx dw ? ; player_d x coord
pos_dy dw ? ; player_d y coord
angle_a db ? ; player_a angle
angle_b db ? ; player_b angle
angle_c db ? ; player_c angle
angle_d db ? ; player_d angle
fire_ax dw ? ; player_a projectile
fire_ay dw ? ; player_a projectile
fire_bx dw ? ; player_b projectile
fire_by dw ? ; player_b projectile
fire_cx dw ? ; player_c projectile
fire_cy dw ? ; player_c projectile
fire_dx dw ? ; player_d projectile
fire_dy dw ? ; player_d projectile
strength_a db ? ; player_a strengthometer
strength_b db ? ; player_b strengthometer
strength_c db ? ; player_c strengthometer
strength_d db ? ; player_d strengthometer
kills_a db ? ; player_a kill count
kills_b db ? ; player_b kill count
kills_c db ? ; player_c kill count
kills_d db ? ; player_d kill count
end_game db ? ; end_game request
SERV_DATA ends
PLAYER_D struc ; recieved from clients
player_num db ? ; player's number (0-3)
pos_x dw ? ; player's x position
pos_y dw ? ; player's y position
angle db ? ; player's angle
fire_x dw ? ; player's fire coord
fire_y dw ? ; player's fire coord
strength db ? ; player's strength
kills db ? ; player's kill count
end_game db ? ; end_game request
PLAYER_D ends
|
Questions? Comments? Want a copy of the game? Send email to: stoppelm@ews.uiuc.edu
