Project Description:

Since the switch over from the Sun machine occurred this year, there is a serious lack of games to be played by students in the lab. The goal of this project is to design and program a side-scrolling shoot-um game, similar to Contra or Metal Slug series. The game would be networked for multiplayer, easily portable to other OSs. (The lab is bound to switch again eventually.) The purpose is to learn about game design considerations through the making of the game, as well as to produce a cohesive, polished final game.

The game itself will star the player(s) as a variety of characters, looking to exterminate demons that have invaded a futuristic city. Each character will vary in appearance, as well as have various attributes that will give them different advantages and disadvantages. Game play will take place from a side-view, with the players only moving in one plane. Levels will consist of traveling across the screen by jumping from platform to platform, while attempting to shoot enemies, with a boss at the end. Contact with any one enemy bullet will kill the player. Various power-ups will be available to the player to improve their firepower. The characters and backgrounds will be represented by 2d sprites. However, the game will be coded using OpenGL, utilizing 3d effects for the platforms, various boss characters, and additional effects. Networking would be included, allowing 2 players on different terminals to play together. The game should therefore allow user to sign on and find other people waiting to play in some kind of lobby, as well as keep track of high scores so that players and 2 player teams can be ranked. Additionally, some form of level editor will need to be coded, in order to create, save and load levels.

System Model:

Components:

MAIN LOGIC
----------

The main logic class is the central component. Its tasks will involve keeping track of the gamestate, and notifing the other components when they are needed to do something. It will also contain the main game loop, and is therefore responsible for all timing involved in the program.

It would store all of the game objects, including the players, bullets, enemies, platforms and background. The players, bullets, and enemies would be stored in thier own vectors, and these would be iterated through during the main loop and updated where appropriate. The platforms and backgrounds would be stored in an array or map, so that speedy access of them for collision purposes is possible. (It allows easy, free elimination of far off platforms and backgrounds.) All objects will be assigned unique IDs.

It notifies:

Display -- with positions of objects to draw during every loop, as well as changes in the state of a character (so that animation may be changed).
Sound -- when it should play a specified sound effect.
Networking -- The positions of all objects for the client player during a online game.

It utilizes:

Scripting -- to read in and set behavior parameters at the load of a enemy.
3D Math -- in order to check whether such events as collisions have occured.

It is notified by:

Networking -- on the client side to update all objects, on the server side to handle second players input, as well as events triggered on the client side.
Input -- when the player moves, shoots, or quits the game.

DISPLAY
-------

The display component is responsible for using OPENGL to display the action. GLUT will be used to easily create a window in which to draw to, since no GUI Widgets are required. Requirements of the Display include:

Drawing objects where/when requested by logic.
Keeping track of animation frames/loops for characters and enemies.
Creating and Managing textures for all created objects.
Using Frustrum Culling to avoid drawing all objects.

The Display should have a mirror object for each object created by the logic, such that each object shares a "unique ID" with its counterpart in the other component. This allows for syncing of the the graphical object, with its logical equivalent. Thus when reporting the position of an object, the logic need only specify this ID value.

NETWORKING
----------

The networking component will take care of sending and recieving information with a second player. The client will simply operate by recieving all of the positions from the server, as well as notifications about new object creations, and other events. The server will then recieve the client users input, and will then treat it just as it does the input of the local user. In this way, the client will not have its own logic at all, but rather mirror the game-state of the server, and the server will not treat the client any differently than another input device.

SOUND
-----

The sound component should simply do 2 things. It should be able to play a background MIDI or MP3 as music, and it should be able to play .WAVs specified by the logic. The Logic will pass the sound component and event, such as 'BULLET_HITS_WALL" and the Sound component will look it up in a map, and play the appropriate sound effect.

Note: This could be quickly implemented using an existing sound library.

3D MATH
-------

Another smaller component, this would allow the logic to simply ask for collisions between spheres, planes and lines. This lets the Logic make descisions about the next "state" of an object. (ie. testing if a bullet hits the player)

Note: This is a VERY small coponent that could be done easily by anyone whith 123 experince in just a few days, if that.

INPUT
-----

The input component would allow for reading keyboard and mouse input. It would simply report to the Logic when an input is made, and the logic will act accordingly on the next "update."

SCRIPTING
---------

The scripting component would have small base requirements, with a large possibility for expansion. Upon creation of an enemy object, the Logic will be able to ask the scripting component about any special attributes the enemy has, which will set flags inside the logic's representation. Then when updating the enemy, the logic will be able to make choices depenging on the flags set. (ie. SHOOTS, CAN_JUMP etc...) These flags can be edited via Notepad for each enemy type.

LEVEL EDITOR
------------

The purpose of the level editor is a quick and easy way to create levels for the game. The user would be able to place platforms and backdrop "planes" and select thier texture. Additionally, the user can place enemies and powerups, as well as place simple camera commands throughout the level. Levels could then be saved, where they could be opened by the game itself for use.

The menus involved would be simple and rendered in GL and/or GLUT, avoiding the use of a complicated GUI and the required library.

Game User Interface:

As seen above, the game user interface will just consist of a player "sprite" (in this case the nun) which can be moved around the enviroment. Game will run at 800x600 resolution, full screen or windowed.

Connection User Interface:


Users will simply get a small window similar to the above after running the program. They can select another player and hit "ask to play", and then that user will recieve a small pop-up window asking them to confirm. The player asking is the server, the player respnding is the client. After they hit OK, the game commences. If the user selects "play alone", the game begins locally with one player.

Editor User Interface:

Users will be presented with a simple zoomed out view of the level, and are able to access functions from a pop-up menu activated by right click. Level items are locked into a "grid" which can be slid along the z axis to allow for placing objects in different planes. Right clicking on an object will allow for the user to edit its properties such as texture and transparency.

Keyboard shortcuts will activate the different modes, allowing the user to place polygons, platforms, enemies, and special objects (power-ups, camera controls, etc..) The menu to select which item to place will look like the following:

The editor should be kept as simple as possible, while still allowing for all the needed functionality. Awkward keybinding are preferable to cleaner, more complex to implement, GUI solutions which will take up more time.

Requirements:

The Player:

High:
-must be able to move left and right
-must be able to jump
-must be able to shoot in 8 directions
-must have correct collision detection. (for both platform navigation and hit detection form bullets)
-must be able to drop down from a platform by holding down and pressing jump.
-must be able to die when shot
-must be able to throw grenades as a secondary weapon
-must be able to pick up power-ups
-must respawn if player has lives left.
-must be fully animated.
Low:
-must be able to climb ladders
-must be able to remap control keys for both first and second player.
-must be able to select different characters to play as, with different abilities
-must be able to command some sort of vehicle in parts of the game

The Editor:

High:
-must save and load some “level file” format
-must support constructing a level using pre-built geometry blocks (tiles) and created planes.
-must support deletion of areas
-must let user texture geometry of level.
-must let user place enemies in the level
-must let users place control points to guide the camera in game.
-must support placement of lights.
-must support placement of power-ups
Low:
-must allow for zoom points, which change the camera zoom in game

The Engine:

High:
-must load levels from level file
-must have some form of “effects” for explosions, etc…
-must obey all flow commands set up in the editor
-must support 1 or 2 players, with a 2nd player able to join the game at any time.
-must manage the game, including enforcing the “rules” and keeping track of all game objects.
Medium:
-must support setting up animations for sprites in separate files, allowing for “skinning” of game.
-must have text engine to display messages from custom font bitmaps.

The Enemies:

High:
-must have some way of moving, taking into consideration the level geometry.
-must be able to attack the player
-must have some defined behavior
-must be able to be destroyed by player.
-must exist multiple (3+) different types of enemy per level (not including boss)
-must be fully animated.
-must be able to script behaviors
Low:
-must be able to edit behaviors in the editor. (as opposed to in Notepad, etc..)

Power-ups:

High:
-must be able to be collected
-must include custom graphics and movement to distinguish them.
-must be at least 3 different kinds.

Networking:

High
-must allow for lag free gameplay
-must allow user to find other players
-must support 2 players in the game
-must be able to track high scores
Low:
-must support 4 players in the game

Sound:

High:
-must feature 3D sound
-must support MIDI, MP3 or MOD playing capabilities for background music
-must support WAV files for sound effects
Low:
-must support a real-time reverb effect to apply to WAV files. (for caves, etc.)
-must support user-selected tracks to play as background music

Non-functional Requirements

Performance

The program would be required to perform at above a minimum of 30 frames per second on the SunLab machines in order for the game to remain fun and accurate.

Testing

Testing would require that each component be tested on its own first. After the compnents have been integrated, a steady diet of playing would help track down the last of the bugs. If needed, "testing" sessions could be held in the Sunlab, offering free pizza to anyone who would play the game for an hour.

Reliability

The program must be able to run full games without crashing. Slowdown must be kept to a minimum, and it should also not affect other processes on the machine it is running.

Ease of use

The game must be easily runnable and playable by a user who is familiar with video games, but has not read any documentation on this particular one. Additionally, the connection to an internet game should be transparent, and not require any knowledge of connecting to an internet game.

Portability

The game should easily port to Windows, because it is the OS of choice for most gamers. (We would like to play this thing after Brown you know...) Additional portability is not required, but wanted. Any other version are not required to Network with versions on other OS's.

Documentation

Documentation on how to play the game will exist in the game itself, quickly listing the buttons needed to play. Documentation on troubleshooting, level editing, and configuration will exist in a README file in the game's directory.

Dependencies on other systems

None are inherant in the project. Outside libraries could be used for portions of the game (input, sound, etc..), but since no one particular library is ever required, systems that cause problems can be quickly replaced. It is up to the implementer of each component to decide if utilizing any outside libs is worthwhile.

Note that OpenGL and GLUT are working stable libraries that do not constitute any risk.

Risks:

The major risks involved with the project are:

1)Complex Logic -- The Logic's reliance on the Display to be functioning at a base level before the results can be seen and tested. The Display programmer would need to quickly get up a "dummy" version that allows for shapes to be drawn in place of actual game objects, as reading a text output would be near impossible.

2)Contenet -- The creation of media. Models and art would need to be collected and put in a format which could be used. Additionally, level data would have to be generated before the Level Editor was completed in order to allow the actual game to be tested.

Conclusion:

All features under High priority would be implemented. Additionally, a minimum of 2 working levels would be completed, with a goal of at least 3. Also included would be a title screen and game over screen. Obvious extensions for any future versions would be to include more levels, more weapons, enemies, etc; Support for a deathmatch mode, where the players are out to kill each other; and AI partners to play as the second player if the user is alone in the lab.