CS 190 Top Level Design CS Contra Krister Fardig kfardig 1) Levelized high-level component diagram -------------- +-------------------------| Controller |-----------------------+ | -------------- | | | | | | | +-----------+ | +-----------+ | | | | | | | | | ---------------- | | | | | Logic Output | | | | | ---------------- | | | | | | | | --------------- | | ----------- | | | Logic Input | | | | Display | | | --------------- | | ----------- | | | | | | | | ---------- ----- ---------- --------- ----- ------- ------- |Game State| |Input| |Networking| |Scripting| |Sound| |Animate| |3D Math| ---------- ----- ---------- --------- ----- ------- ------- Controller - backbone of the project. Houses all of the local components of the game. Controls flow of information to and from the gamestate (principally Logic Input -> Gamestate -> Logic Output). Contains the main game loop. Logic Output - Shell for audio and visual output. Logic Input - Shell for keyboard, mouse, and network input. 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. 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. Game State - Stores 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. Input - Allows for reading keyboard and mouse input. It would simply report to the Logic Input when an input is made, which will send it along to the Controller which will cause the gamestate to act accordingly on the next "update." 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. 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. 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. Animation - Keeping track of animation frames/loops for characters and enemies, and anything else required by the Display to present animation onscreen. 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) 2) External Dependencies The project requires a graphics library, but fortunately many stable ones exist. OpenGL and GLUT are the most likely. The project requires a sound library, but as it only requires some very basic functionality, any simple one will do. Content - there is a tremendous amount of artwork that would be required, for models, backgrounds, animations and everything else. 3) Task Breakdown Controller - 1 person Gamestate - 1 person (linked closely w/ Controller) Logic Output & Sound & Display - 2 people Logic Input & Input - 1/2 person as needed (probably controller person) Networking - 1 person 3D Math - 1/2 person Scripting - 1/2 person Editor - 1 person 4) Group Organization 1 Project Leader 1 Architect 6 Coders 1 Documentor 1 Lead Tester 5) Schedule 3/3 - Top level design chosen. Group tasks given. 3/10 Final design due. Any changes from top-level documented. 3/15 Interface proposals due. Interaction protocol documented. 3/17 Comments on interface. 3/21 Interface finalized Approval/review by lead, architect. Review by tester and documentator. 4/2 Component designs due. Approval review by lead, architect. Review by tester and documentor. 4/2 - 4/16 Programming. Lead oversight. 4/16 Base programming finished. Component testing finished. Integration begins. 4/21 First pass at system testing mostly complete, bug lists compiled. Design documentation handed in. 4/28 Code freeze, functionality set. Only bugfixes worked on. Full integration User manual complete. 5/9 Final Demo/Presentation Documentation handin 6) Assumptions about specs The implementation of how clients find each other to create a multiplayer game is not definited. We know what to do (have all available clients listed) but not how to do it.