Software Design Specification - University of Utah

Software Design Specification Version 1.0 February 13, 2009 CS4500 - Software Engineering Lab Grim Tides Bradley Grimm Brian Faires Derrick Birkes Jaden He

1.0 Introduction 1.1 Purpose of this Document The purpose of this document is to give a more in depth understanding of the design and architecture of the rhythm game known as Fortissimo.

1.2 Scope of the Development Project The game would use both MP3 and MIDI format of a song to implement the game. First, the game would use the MIDI format of the song to generate a set of notes according to the rhythm. The game would use the MP3 file to play the song, while displaying notes simultaneously for the player. The player would listen to the song during one game session, and try to hit as many notes as possible to win the game.

1.3 Definitions, Acronyms, and Abbreviations Description

CEO

Chief Executive Officer, who is Professor Henderson

VS

Visual Studio

MIDI

Musical instrument digital interface

MP3

MPEG-1 Audio Layer 3. A digital audio encoding format

1.4 References 1.4.1 Articles · Packer, Mike, Handling a Keyboard properly XNA. Available @: http://www.ziggyware.com/readarticle.php?article_id=174

1.4.2 People · Henderson, Thomas, University of Utah Computer Science Professor.

1.4.3 Web Sites · Wikipedia: http://www.wikipedia.com · ZiggyWare: http://www.ziggyware.com · XNA Creators club online:

http://creators.xna.com/en-US/

1.5 Overview of Document Part 2: System architecture – This section explains the system we're planning to develop for and on. It explains the relationships and structure of the project. Part 3: Detailed description of components – This section explains the different sections of the code along with their reactions to each other. Part 4: Reuse and relationships to other products – This section gives a look into open source formats to which we have decided to adhere to. Also explanation about open source code available to our disposal. Part 5: Design decisions and tradeoffs – This explains our main design format along with design styles that we decided against. Part 5: Pseudocode for components – Some pseudocode is given for better understanding of component interaction.

2.0 System architecture description 2.1 Overview of modules / components This project consists of three major components: Game Client, Musical and Input Device components. The game client handles the single player logic for actual game play. It can be broken down into the following modules: Menus, Notes, Player Scoring, and Graphics. The menus allow the user to interact with any accessible part of the game. A Notes object describes the actual notes the player is expected to play for any particular song and difficulty pair. The scoring and graphics deliver information to the user and are inferred from the active Notes object and the Input Device component. The Musical Component handles the processing of songs that must be done before they can be played. It generates a Notes object that is used by the Game Client component. The Input Device module reads values from the XNA game controller driver and stores the events that the Game Client cares about. 2.2 Structure and relationships The Game Client components are central to the project design. The central Game Client logic controls all other sections of code. When prompted by the user through menu selection, the Game Client prompts the Musical component to parse MIDI files and/or return Notes objects. This is represented by the Game Client->Musical and Musical->Notes component edges in the figure below. The Input Device component stores many I/O related values and returns them when polled by the Game Client. These values include currently pressed and last pressed timestamp. This is represented below by the Game Client->Input Device and Input Device->Player Scoring edges below.

2.3 User interface issues There are three I/O actors in all scenes described below:  



Graphics – The user receives output from the system via graphical menus, meters and displays. Auxiliary Sounds – The user will also receive information in the form of sounds generated by the Game Client. The music track that the user is playing will cut out whenever a required note is not successfully hit. Additionally, when an incorrect note is played by the user, a short sound effect will be played. Input Device – The user can use any supported controller to both traverse menus and play the game. This is the only input that the player has to interact with the game, and will consist of six keys.

Scene 1: Startup Menu

In this scene the user can set up basic settings or start a play mode (career or free play). The graphics and sounds inform the player of the current state, which is changed with the Input Device. Selecting a menu item will move control to another menu. Scenes 2 & 3: Career & Free Play modes These scenes contain menu screens nearly identical to the startup menu screen. The difference is that these menus contain lists of playable songs. Selecting a menu item will start a Game play scene. Scene 4: Game

In this scene, the player can see the notes moving down the screen. When the notes line up with a clearly designated spot (the blue stripe is an example above), the player must play the corresponding key on the input controller. The health meter, score and multiplier are displayed and updated.

3.0 Detailed description of components 3.1 Component template description

Name Type Purpose Function

The unique name for the component and the location of the component in the system. A module, a subprogram, a data file, a control procedure, a class, etc Function and performance requirements implemented by the design components, including derived requirements. What the component does.

Structure Dependency

Interface

Requirement Implementation Data

The internal structure of the component. How the component's function and performance relate to other components. How this component is used by other components. The other components that use this component. Detailed descriptions of all external and internal interfaces as well as of any mechanisms for communicating through messages, parameters, or common data areas. A complete description of all resources (hardware or software) external to the component but required to carry out its functions. The full description of the functions presented in the Function subsection. For the data internal to the component, describes the representation method, initial values, use, semantics, and format.

3.2.1 Client Name Type Purpose Function

Game Client Module Allows user to interact with the environment. 1. Display all visual information of the game. 2. Play data files (Musical Component) during the game. 3. Implement the game according to user’s input through Input Device.

Structure

The Game Client is made up of several classes that are written in C#, XNA 3.0, Microsoft Visual Studio 2008 The Client reads in data from two resources:

Dependency

  Interface Requirement

Implementation

Musical Component Input Device

The primary interface is the visual display of the game where all of the objects and action is drawn to the screen.  A regular PC (such as PCs from computer labs of the University) that meets the system requirements of the game.  Speaker or headphones  Input Device 1. Set up all components specified in Requirement. 2. Run the game, follow the instructions in the game to start a game session. 3. User use Input Device to interact with the game. 4. The Client returns information (such as score, etc) to

user’s by the end of each game session. Data

The Client returns data (such as score, etc) to user’s by the end of each game session.

3.2.2 Musical Component Name Type Purpose Function Structure Dependency Interface Requirement Implementation Data

Musical Component Data file Provide data to Client. Major input data for Client. MP3 or MIDI files. Dedicated to Client. N/A MP3 or MIDI files. Built in, multiple files used by Client. Stored in game directories.

3.2.3 Input Device Name Type Purpose Function Structure Dependency Interface

Input Device Module User use this component to interact with Client. Play game. N/A This component output data to Client.  Regular PC keyboard  XBOX 360 game controller: game pad  XBOX 360 game controller: Guitar

Requirement Implementation

Same with subsection: Interface. Please refer to user manuals of devices from subsection: Requirement. All data generated by devices will be sent to Client.

Data

4.0 Reuse and relationships to other products Reuse is very important in our project. We are using the XNA framework provided by Microsoft which provides us with all of the necessary components to build our game. This allows us to focus more on our game and its contents and less on the implementation of basis game components.

We also have to goal to continue expanding on the game so we are trying to generalize our code so that it can be expanded upon later.

5.0 Design decisions Our design is about flexibility. We have decided to use a strong style of inheritance where the game layer has little to no information about each of the components. Using an abstract interface it calls the necessary components. In this fashion we can load in many different song types, instruments, and note formats allowing large amounts of flexibility in the experience. One key component to our design is abstracting out interfaces such that no component needs to know exclusively about the other components. By passing the data through XNA interface classes this allows the program to have a high level understanding of what is happening (while each component is responsible for its own low level execution). We considered using a design less based upon inheritance and more based on aggregation. But decided that the implementation would be costly, and we couldn't afford the development time to do it right. Inheritance provided a nice alternative to the solution.

6.0 Pseudo code for components Input Client   

Handle input from multiple devices (keyboard, controller, guitar) Notify Game Client of input action Keep input state for game client

Musical Component    

Parse Midi files Return current notes that can be drawn Handle hit notes Handle missed notes

Game Client    

Handle menu system Interface with Input Client and Musical Component to get current state of the game Draw graphics Handle and calculate player score