Foo Sharks

SDS: Sonic Boxmo

Version: 1.0

CS 4500, University of Utah, Spring 2008

1. Introduction

1.1 Purpose of this document

This document outlines the various components, component relations and interfaces of the Sonic Boxmo project.

1.2 Scope of Project

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.

1.3 Definitions, Acronyms, and Abbreviations

• HID: Human Interface Device
• OpenAL: Open Audio Library
• OpenGL: Open Graphics Library
• SRS: Software Requirements Specification

1.4 References

OpenGL Primer, 3^rd Edition - Angel, Edward
Software Project Survival Guide - Steve McConnell

1.5 Overview of Document

2. System architecture description

2.1 Overview of modules / components

This project will be broken into 3 primary functional subsystems:

• Graphics
  • Manages graphics resources
  • handle 'pick' operations
• Sound
  • Manages audio resources
  • provides a functional base for other components to play sounds in a simple manner
• User Input
  • gathers and maintains state of input devices
  • abstraction for mouse and Wii Remote hardware to be accessed via the same interface

The game itself will be be built on top of this framework and will include the following components:

• Player
  • holds player info (name, score, etc)
  • holds player-specific input data (cursor position, button states, etc)
  • maps hardware input events to player actions (static)
  • manages player-specific graphics elements (cursor, icons, etc)
  • holds chain of notes (completed puzzle elements)
• MusicTrack
  • holds/manages/outputs information about the current music track such as event timing, sound samples, etc
• MusicBar
  • creates a bar which will show information about the current song (similar to the guitar-hero fret-board thing)
• puzzle field
  • holds puzzle elements and handles puzzle-rules

2.2 Structure and relationships

The 3 primary functional subsystems above will be entirely orthogonal and have no dependence or use of the other components.

The game-play components will be organized as follows:

• Game
  • PuzzleField
  • Players(1-4)
  • MusicBar
  • MusicTrack

A primary Game component will contain, initialize, manage, and clean-up all gameplay related components.

A Menu object will manage all functions related to the options menu and will be responsible for instantiation of the Game object.

2.3 User interface issues

The Main Menu will be a simple hierarchical menu with game settings, etc.

The main game interface will be appear as follows:

3. Detailed description of components

NOTE: This section is the main focus in version 2.0 of the SDS, the detailed design. This section will provide most of the basis for implementing the product.

3.1 Component template description

This section is not part of your design. It is the pattern you will use to describe the components given in subsections 3.2 - 3.n. Each part of the template will be identified by a label. Here in 3.1, you must briefly explain the purpose of each point. To make the presentation clear, use a table or bullet list. You may adapt the template suggested below to your particular needs (although deviations from the suggested template should be minimal and well motivated).

3.2 X Component (or Class or Function ...)

Use exactly the template you define in 3.2. If a part of the template is not applicable, then mark it N/A rather than omitting it.

3.3 Y Component (or Class or Function ...)

...

3.n Z Component (or Class or Function ...)

4.0 Reuse and relationships to other products

For teams doing enhancement work, reuse is an important issue. Most enhancement work should focus on extending, rather than replacing, the design and product development from earlier semesters.

For teams doing new development, reuse can also be an important strategy. In some cases, there is freeware that could be incorporated. In other cases, there are existing modules or classes that could be adapted. Another possibility is the use of special tools that produce open source results and thus permissible under the terms of this course.

This section should include the following subsections as appropriate:

• how reuse is playing a role in your product design
• how reuse is playing a role in your product implementation (and the motivation for changes)
• if you are not reusing material that is available, then give motivation for why it is being thrown out.

5.0 Design decisions and tradeoffs

Use this section to motivate any decisions that will help the reader understand the design that your team is using. This section can also capture good ideas that were abandoned and the reasons for leaving them out of the design.

6.0 Pseudocode for components

7.0 Appendices (if any)

---

SDS component template

The template given below suggests a reasonable structure for giving a thorough description of each component described in Part 3 of the SDS. The specific information depends in part on the design approach. Your team must adapt this template to your needs and describe it in section 3.1 of your SDS.