Component Descriptions (edited from spec):

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 component that could be done easily by anyone with 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.

Note: Level Data will have its own spec, so that the people writing the level editor, and the game logic will be using the exact same system. An additional bit of code that saves and loads the level files could also be helpful, so they are only coded once and shared between the 2 logics.

<new>GAME SERVER <new>
---------

In addition to the above components, a small server/client program would need to be coded, to allow for users to find each other and start a game. One person could probably code both parts, as it would just be a small seperate program. The server would constantly run, and keep track of the players connected, waiting to play. The clients would allow user to match up, and start a game (which will be a seperate executable with the connection information passed in at the command line). See spec for GUI "look."

External Dependencies

OpenGL -- to display the 3d graphics. Easy and free, with plenty of documentation.
The Art -- will be provided by Andy Hull's art independent study. More could be taken from commercial games if needed.
Level Files -- must be created with editor, format must be designed. Bigggest Issue.
Sound Library -- any misc. lib will do. Just need to play music, (any format) and sounds when needed.
GLUT for windowing and input -- again, easy and free, with plenty of documentaiton.
Networking -- options vary here as well, need some way to open sockets and connect. QT or HawkNL seem best choices.

Task Breakdown/Group Organization (edited from Brian Chuck's BEAR top level design doc)

Project Leader (1)

The Project Leader is responsible for the overall progress of the project. His/her duties include monitoring group members’ progress and setting/adjusting deadlines accordingly, keeping track of the overall progress of the group, facilitating communication between the different group members, and making sure everyone in the group knows what is going on. Though he/she is responsible for setting all the group deadlines, the entire group must discuss these dates jointly; the Project Leader is the person who takes in the input of all the group members and makes the final decision on the deadlines. He/she is also responsible for keeping group morale up and making sure that everyone in the group is aware of his/her duties. This person is also in charge of setting up and mainting CVS for the project members, helping with library integration, as well as making sure hand-ins are on schedule.

Architect (1)

The Architect is one of the coders (with less work), who is responsible for the design of the project. Said person will know the project design intimately, and he/she will know all the details and about the design for each piece of the project. He/she is responsible for making sure the project retains its “conceptual integrity.” Each group member will have a say in the design of the project, but the Architect will have the final say. Any design changes that may arise during the project implementation must be approved by the Architect. They must keep in close contact with the project leader to make sure everything is on track.

Coders (7)

The Coder will do the actual coding and implementation of the application. Each Coder will be given a specific component or set of components to implement. He/she will have the responsibility of making sure his/her component(s) get implemented. Once said component(s) has been implemented, he/she will have the responsibility of fixing any bugs found in his/her code. The Coder can get his/her portion implemented by any means that he/she deems reasonable. If he/she wishes to have other members of the group help him/her, it is allowable, however not at the expense of another person’s duties.

Coders Component Breakdown (total = 7)

• Main Logic (1 1/2 people) -- responsible for coding the underlying logic of the game, and making calls to the other components.
• Display (1 person) -- responsible for displaying textured polygons, keeping track of the camera, and supporting animations as well as some drawing algorithms.
• GLUT -- Windowing/Input (0 person) -- VERY small component, could be done in a day. Just setting up GLUT to use a window and linking keypresses, will most likely be handled by logic crew as a neccessity.
• Sound (1/2 person) -- responsible for finding and wrapping a sound library, as well as finding/making sounds/music to use.
• Math (1/2 person) -- VERY small component, to test collision in the game.
• Scripting (1/2 person) -- VERY small component, can load small files to define enemy movement.
• Editor (1 person) -- responsible for a section of code that allows for creation of levels, as well as placing enemies and camera controls.
• Networking (1 person) -- reponsible for passing information between a logic using server mode and one using client mode.
• Join Game Server/Client (1 person) -- responsible for writing a small server/client to find other players, as well as a high score list.

Documenter (1)

The Documenter is one of the coders responsible for creating the documentation for the project. This includes a User Manual, design documentation, and documentation pertaining to each component and its implementation. The design documentation and implementation documentation should be mostly created by the Architect and Coders; thus the Documenter’s duties in these areas will consist mainly of gathering the already written documents, proofreading and editing them, and organizing them in a presentable fashion. Therefore, the main duty of the Documenter is to write the User Manual. They should also keep the entire team up to date with changes and updates as they arrise.

Quality Assurance (1)

Before programming begins, this person is responsible for contacting possible users for input. This person is responsible for writing test code to make sure components are working as documented before integration. They should also actively try and break any usable executable. Any bugs found should be sent to the documentor for recording and dispersement. They are also responsible for organizing testing times as well, and gathering outside testers for this purpose. During these testing times they should collect data from users, both on feature bugs, and possible improvements/user wants.

Schedule

3/7 – Top-level design selection
Project responsibilities assigned

3/14 – Final top-level design
· All revisions of top-level design collected and made
· Top-level design frozen
· Project assignments frozen

3/19 – Interface proposals
· Each component’s Coder produces a proposal for their external interfaces

3/24 – Interface comments
· Each member should go over all interface proposals, including ones that do
and don’t affect their components and provide feedback, comments and
suggestions

3/28 – Final interface definition
· Each component owner finalizes his/her interface by taking into account all
comments made
· Approval for each interface must be granted by both the Project Leader and
the Architect
· Interfaces are frozen and can only be changed through a thorough review
process

4/2 – Detailed designs
· Each Coder should have a finished design approved by the Architect and
project TA
· Once approved, design should be recorded
· Designs are frozen

4/14 – Initial systems integration
· Initial viewing of the project
· Most of the Display should be here, with the core implementation ready for Logic calls

4/21 – Initial system tested, debugged
· By this date, Tester as well as users should have tested the initial system and
recorded any bugs found
· Coders should have fixed most of, if not all, bugs found

4/25 – Full system implementation
· System should be fully implemented and functional
· In-class demo should be possible
· Functionality frozen

4/26-4/29 – Debugging, Testing
· Extensive testing should be done by Tester, as well as each member of the
group, and as many users as possible
· Any bugs found should be duly recorded and fixed

4/30 – Public Demo
· Project demo in Lubrano

5/1 – 5/6 – More debugging, testing
· Testing should be going on to find all bugs in the system
· Fix any bugs found
· Documentation should have been created ongoing as the project develops; any
documentation still required should be produced

5/7 – Final system submission
· Hand in of system
· All coding, testing, and debugging must be finished at this point
· All documentation must be finished and handed in

Assumptions

The method to join a game, while well detailed in the Spec in terms of GUI and functionality, is not discussed in implentation terms. It is assumed here that a seperate executable, which will then launch the game from the command line is an acceptable solution.