| ECE291 | Computer Engineering II | Lockwood, Spring 1999 |
Team Members:
Introduction:
A company off the Eastern Seaboard has spent thousands of dollars securing a salvage permit for an area of the deep sea. They believe that there may be treasure there left by pirates long ago. They (foolishly) hired you to guard their potential gold mine. What they don't know is that you are really part of a cunning ring of salvage thieves who offer their sevices to unknowing companies and reap the benefits before the companies have a chance to send down their own divers. Most of the time the ring splits all of the loot equally, but recently you've been feeling greedy and didn't tell them about this job. The rest of your cohorts found out about this and have come for themselves. For you to acquire your loot (and get out alive) you must fend them off in the Underwater Escapade
Underwater Escapade (UE) is a top-down, multi-player game using NetBIOS to be played over a local network. Game play incorporates viewing the diver from above in one of 16 isometric rotations and using a weapon to shoot wildlife and other players. The diver swims by inputs from the keyboard. By having the diver constantly remain in the center of the screen, we have the environment scroll smoothly around him. This environment does not only consist of water, but also obstacles such as impenetrable stone and poisonous underwater wildlife. In addition, there are an assortment of weapons, which upgrade the defending abilities, as well as objects which restore your life.
Main Features:Problem Description and Implementation:
A 360 direction smooth-scrolling adventure has been implemented. The scrolling aspect has been implemented with two major points of interest. First, a giant game map has been constructed of size 1280x800 pixels. This is the size of 4 screens creating our virtual world. Using this virtual map, we have placed the player in the approximate center of the screen and fixed his placement with regard to the physical monitor. Relatively, however, the background has been designed to continually be in motion. This gives the appearance that our diver is swimming around. The diver has been implemented with 16 isometric positions. Using the keyboard, a player can rotate the diver to the desired position and then apply an amount of thrust. The second point of interest is the fluidity in which all this has been achieved. The Programmable Interrupt Controller has been harnessed to refresh the display at a rate of 30Hz. This is much faster than anything that the human eye is sensitive to, and therefore, appears extremely fluid. Also, we have utilized the concept of double buffering. By first moving a screenful amount of graphic information to a memory location and then transferring it again by high-speed string operations to video memory, we eliminate flicker which can be caused by writing directly to video memory. This unexpected result is due to the fact that block transfers across the PCI bus are more efficient than several byte-sized transfers.
Movement is probably the most complex and in-depth feature of our simulation. By using the floating-point unit, we calculated acceleration, deceleration, velocity, and other statistics which enabled us to create movement of our diver which displays glide, momentum, and sliding. We feel that the depth to which we explored this aspect of the simulation sets us apart from other simulations of this nature. The movement truly does take into account the underwater environment of the game and adds the challenge for the player.
In addition to other players in our underwater game environment, we also implemented creatures, which are poisonous by nature and affect the level of life of a player. The wildlife add an additional amount of challenge to our simulation as players must work to avoid these animals in addition to avoiding other players who are attempting to attack. These creatures are aware of the environment in which they are contained and therefore react accordingly. They have a variety of speeds and directions and incorporate a real obstacle for the players.
Networking is one of the most integral parts of our simulation. The game is primarily a network one and provides little challenge otherwise. The networking is done using the NetBIOS protocol and the sending and receiving of information. Structures and packets are the basis of our networking. Player, object, and weapon structures store information such as ownership, position, velocity, and orientation. Separate network packet structures are also set up and provide capsules in which information can be broadcasted. Different packet structures are used at different times in accordance of what information needs to be sent and received. In addition to these structures, arrays of some structures exist so that all object, players, and projectiles can be accounted for and positioned on the screen as well as judge when a collision occurs. Initially a player sends a 'Hello' packet informing other potential existing players that the new player now exists. If this player is the only player, it waits for 2 seconds and then loads default values into its several arrays. Players are continually sending out 'Hello' packets at a rate of .5 Hz. Entering players see these packets and update their arrays indicating appropriate players as active. Once these 'Hello' packets are seen, they are ignored unless a new player enters. 'Player Update' packets are sent out at a rate of 36Hz. These inform all players of player position and orientations. 'Object Update' packets are a little bit different. Each player has a set of objects that it owns. These objects range from fish that are swimming to weapons that have been fired and are traveling through the water. Each player sends out these 'Object Update' packets for all of the other players to analyze and use to draw images on each individual screen. Finally, 'Goodbye' packets are sent when players leave the game. These packets inform all other players that the sender of the packet is leaving and to mark him inactive in the player array.
An interesting feature, which will help players on their trek through the deep-sea, is the Heads Up Display or HUD. The HUD appears at the bottom of the playing display and displays information such as health level, degree of thrust, and most importantly SONAR. The SONAR display is the most helpful feature of the HUD. The SONAR displays the position of all of the other players in relation to your current position. However, the SONAR does not show fish and other wildlife, thereby keeping the challenge of the sea creatures.
No game would be complete without the addition of sound. Our simulation uses just a snippet of sound as an accentuation to game play. A player will first notice that a MIDI song is continually playing in the background. This is accomplished by utilizing the MIDPAK provided to us. The MIDPAK, when installed, patches into the 66h interrupt on the user’s interrupt vector table. From there, a variety of functions can be called by simply calling the interrupt. By using the register and play functions of the MIDPAK, we are able to take an eXtended MIDI song and play it through the sound card’s MIDI capabilities. The repeat of the song is accomplished by applying the status function and determining whether or not the song is finished. This status function is called through our PIC. Once the status is determined to be that where the song is not playing, it is registered again and played.
This project took us approximately 120 programming and planning hours per person.
Constants, General Variables, and Structures
Procedures and Variables: (those within external libraries have been omitted)