1.1 Project Overview2.0 Project Organization
1.2 Definitions, Acronyms, and Abbreviations
1.3 References
1.4 Overview of Document
2.1 Process Model3.0 Team-specific Aspects
2.2 Organizational Structure and Responsibilities
2.3 Organizational Boundaries and Interfaces
2.4 Reviews, Walkthroughs, Inspections, and Audits
2.4.1 Procedures for Reviews, Walkthroughs, Inspections, and Audits
2.4.2 Schedule of Reviews, Walkthroughs, Inspections, and Audits
3.1 Management Objectives and Prioritories4.0 Preliminary Sketch of Project Requirements
3.2 Team Name
3.3 Possible Meeting Times
3.4 Teams Range of Skills and Experience
4.1 Overview of Functional Requirements
4.2 Overview of Data Requirements
4.3 General Constraints, Assumptions, Dependencies, Guidelines
4.4 User View of Product Use
Team Foo Sharks will create a puzzle game entitled Sonic Boxmo. It will consist of novel and innovative features including a multi-cursor multi-player user interface and fast-paced music based puzzles, which will immerse the players into a unique musical environment. Each player in the game is going to have their own cursor and speaker, and will play in a shared 3D hardware-accelerated environment.
Include key terms; this section helps ensure that the project plan will be understood the same way by everyone. Be sure to alphabetize!
- OpenAL: Open Audio Library
- OpenGL: Open Graphics Library
- SR1, SR2, SR3: Staged Release 1, 2, & 3
- SRS: Software Requirements Specification
OpenGL Primer, 3rd Edition - Angel, Edward
Software Project Survival Guide - Steve McConnell
This document provides an overview of the Sonic Boxmo project implementation plan.
We will be using an iterative development process consisting of several large milestones and many small, component milestones. The core components of the project will be individually coded in parallel by each group member and integrated and debugged for an initial staged release (SR1). The second staged release (SR2) will consist of functioning game mechanics. The third staged release (SR3) will incorporate a sand-box mode and more puzzle content, 3d-models, sound-samples, etc. We will exhaustively test components inidividualy with synthetic representative use cases and data sets, further testing will involve play testing on various hardware/os environments. Source code management and version controll will be achieved via Subversion. Each component will have an associated bug-log which will be maintained via the SVN server and updated as bugs are discovered/fixed. Visual Studio 2005 SP1 will be the IDE of choice.
Item Due Date Project Plan January 30, 2008 SRS February 3, 2008 SDS v1 February 3, 2008 SDS v2 February 17, 2008 VVP February 23, 2008 Stage 1 Code March 7, 2008 VVR March 10, 2008 VVR v2 March 27, 2008 Stage 2 Code March 31, 2008 VVR v3 April 12, 2008 Stage 3 Code April 13, 2008 Formal Presentation April 14, 2008 Product Release April 21, 2008 Legacy Turn-in April 25, 2008 Demo April 27, 2008 Final Report April 27, 2008
Initial sole responsibilities:
Seth (Overlord): Audio Pioneer... choose appropriate audio API, create/test base classes. As Overlord, Seth has absolute veto power over any of Jareds crazy ideas.
Jared (Supreme Project Leader): Multi-Mouse Wrapper API, Wii Remote Driver. As Supreme Project Leader it is Jareds responsibility to ensure that deliverables are indeed delivered and that the project is progressing appropriately.
Justin (El Presidente): Graphics, 3D Modeling... create/test 3d engine, create 3d models. As Presdent, Justin will be primariy responsible for deciding on document layouts and assisting the Overlord in veto duties.Respoinsibilities will be added/changed as the project demands. Titles/roles will only be modified as required to keep the project on-track.
Shared responsibilities:
Key decisions such as game mechanics, will be made as a consensus of all members.
Documents and deliverables will be created as a group (split and divided as needed).
As this is a self-assigned project our outside relationships are limited.Thomas Henderson
Instructor and Project Advisor. Provedes feedback on quality of deliverables and is essentially our audience/client for every aspect of the project (hope he likes games...).
This section may be updated as consultations are made and as testers are resruited.
This will be added when we are closer to staged releases (SR1, SR2, SR3) and have a stronger idea of what needs to be audited.
Prior to each Staged Release
General management duties will be handled through a consensus of all group members. If and only if a consensus can not be reached on a given matter the Supreme Project Leader will be responsible for the decision.
Foo Sharks
Team meetings are held daily after class at 21:45 GMT.
|
Legend: 5=worst, 1=best |
Jared |
Justin |
Seth |
|
Programming C/C++ |
1 |
1 |
1 |
|
Graphics (OpenGL) |
2 |
2 |
3 |
|
Audio (OpenAL) |
4 |
5 |
5 |
|
3D Modeling |
5 |
1 |
4 |
|
Sofware Design |
1 |
3 |
3 |
| Game-play design | 2 | 3 | 1 |
Sonic Boxmo is a multi-player puzzle game and is intended for entertainment purposes only.
Describe data that are input to or output from the product as well as any data that are stored within the system, for example in files or on disk. This section should only cover data requirements from the user's point of view. Once again, this should not be design-oriented.
Up to 4 wary gamers, long bored of plunking the clumsy buttons of the over-priced guitar hero controllers, legs worn from countless hours of fumbling clumsily on a flimsy Dance-Dance Revolution mat, plug in their 4 usb mice and, for the first time in their single-cursured existence, are greated not with a pointless struggle to control a shared cursor, but instead find that they are in full command of their own independant pointer with which to battle their friends in a best-of-all worlds music puzzle.
1.0 (1/31/2008) Initial Document Release
1.01 (2/6/2008) added bars between sections