Project Plan

1.0

1.1 Project Overview

Our goal is to build a rhythm game that allows you to plug in your own music. We strive to reach out to a broad range of users from beginners to enthusiasts. That way, whether for fun or education, a user can fully involve themselves in the game.

Objectives:

Extensible – We plan to build the project in a highly extensible way, allowing easy addition of new input/output devices. Our objective is to allow the player to play the game using one of the following devices: keyboard, 360 controller, USB guitar, MIDI device.

Enjoyable – We strive to make this game as enjoyable as possible. This will be achieved by paying close detail to scoring, gameplay, and replayability. We hope to test this with a moderate subset of people to see their opinions on the game, and make changes accordingly.

Customizable – We want to make it easy to insert custom songs or custom skins. We hope to do this through an easy import functionality, allowing the user to browse their imported songs. This will allow our user base to increase as the community adds to the song library.

Deliverables: Rhythm game – We plan to deliver a completed and polished PC/Xbox 360 game.

Built in songs - This game will have several built in and attuned songs to play, that will consist of the default gameplay.

1.2 Definitions, Acronyms, and Abbreviations

Guitar Hero (aka GH) – Activision's line of guitar centered rhythm games. Microsoft XNA – Microsoft's platform that allows code to be developed for the Xbox 360 and PC concurrently. Midi Device – Any number of Midi Controller's such as Midi Keyboard, Midi Drums. Rock Band (aka RB) – Harmonix's rhythm game allowing multiple simultaneous instruments being played. Synthesia – Piano based rhythm game primarly focused on teaching piano. Xbox 360 (aka 360) – Microsoft's game console.

1.3

Chen, James “Rhythm Games - Part 2: Establishing My Rhythm” http://jchensor.blogspot.com/ 2007/01/rhythm-games-part-2-establishing-my.html Guitar Hero, http://www.guitarhero.com Oguro, Collin “Top 10 Rhythm Games,”, Gamespot http://www.gamespot.com/features/ 6142896/index.html Piegdon, Nicholas “Synthesia, Piano for Everyone” http://www.synthesiagame.com/ Rockband, http://www.rockband.com/ XNA Creator's Club, http://creators.xna.com

1.4

First we will give a concise overview of the direction of the project. As well as who is in charge of each of the separate tasks. Along with a teaser for what to expect in our upcoming demos. Then we'll go over some explanations about our team's skills, goals, and and priorities. Lastly the document will cover some of the requirements our game will hopefully achieve and how the user will be able to use it. 2.0 Project Organization 2.1 Process Model Process Model Description

Our overall process flow will be incremental due to the nature of our project design. This design includes an early milestone that will require an entire iterative step. After that, each additional milestone requires new analysis, design, coding and testing. This makes an incremental approach desirable.

Project Management will occur throughout the entire process. Management will consist of assigning tasks as they arise. The incremental flow for an addition to the project will begin with an assessment of the most desirable feature to be added to our game. We will then analyze what changes must be made to the existing project to satisfy the new requirement. Given the overall impact of the new feature, we will adjust the existing project, represented above in the Project Support step. Object-level coding will then begin on the new feature in parallel with testing on the existing project. Integration with the existing project(rollout) and final testing will complete each iteration of our incremental process.

Projected Process Flow Our first milestone is a minimalist version of the game. It will include 2D graphics, simple graphics for the HUD, one song and the keyboard as input. We will only concern ourselves with point notes (not sustained notes), and the scoring will be geared towards debugging purposes. Our process to reach this milestone is to split the project into equal parts and delegate the roles to group members. Communication regarding interfaces and other issues will be resolved through email and weekly team meetings. Our first team review will test this milestone, and is scheduled for February 20. After the first review is satisfactorily completed we will move forward in a few different directions. Each new development in this phase will be made to fit into existing interfaces. Additional songs will be parsed and stored in the same note format. Developing 3D graphics will also begin here and will still take as input a collection of note objects from the MIDI parser. Alternative I/O controllers will be interfaced and set the same type of data structure that the keyboard controlled. Gameplay and scoring will also become more refined. Review in this stage will consist of testing each additional element to ensure it doesn’t contain new special cases or unleash existing bugs in the system. Any bugs will be fixed at this point, but the goal of this process is prevent new bugs from developing due to quality abstraction of modules. Once we have satisfactorily added each additional feature, all components will be rigorously tested by someone who did not write the original code. The game at this point will be a good looking single player game with multiple skill levels, songs and instruments. Graphics and gameplay will then be extended to support multiple simultaneous players. Once controllers are developed, graphics support multiple players, MIDI files can be parsed multiple tracks, and gameplay supports multiple players we will update the game to allow multiple instruments playing together. Our process from this point is still largely undefined, and we expect to have a much clearer idea of what details will be relevant by the time we complete our second review. 2.2 Organizational Structure and Responsibilities Our team management will include one designated Team Leader to design the code modules and interfaces. The Team Leader will write much of the code that handles core gameplay like detecting hit or missed notes and calculating score. The Team Leader will most likely be the same individual throughout the semester. Another role is graphics manager. This role includes designing the layout of the game screen and displaying the notes for the current song in real time. The notes will be generated by the third role, the MIDI Manager. This role requires the parsing of a MIDI file into a sequence of notes for each difficulty level and instrument combination. We will also have a role named the I/O Manager. This role requires code to maintain the state of each player controller and interfacing with each I/O device. Another role is tester, but most testing will be done by the original coder. For non-coding roles, we have Set List Coordinator and Track Editor. The Set List Coordinator is responsible for finding songs in the formats we need and coordinating voting amongst the team. The Track Editor is responsible for editing .mp3 and .wav files as needed when attempting to remove the lead guitar track. For administrative roles, we have Webmaster and Progress Reporter. The Webmaster is responsible for storing and backing up the website, but all team members have access to the site and are responsible for posting anything they need there. The Progress Reporter is responsible for submitting the weekly progress report. He also delegates sections of other deliverables as appropriate. Brad – Team Leader, Webmaster Derrick – Graphics Manager, Progress Reporter Jaden – I/O Manager, Set List Coordinator Brian – MIDI Manager, Track Editor 2.3 Organizational Boundaries and Interfaces There is no customer for this project. The only relationship exterior to the team is the one with the instructor. We have communicated regarding deliverables, and the emails have generally been brief and concise. That has been the only communication so far because we haven’t asked for any specific guidance yet because we haven’t had any significant problems. 2.4 Reviews, walkthroughs, inspections, and audits 2.5.1 Procedures for reviews, walkthroughs, inspections, and audits Demonstrating Gameplay To demo the game, start the main song and describe what the graphics in the HUD are for. Describe how the scoring works. Allow notes to pass by and note the absence of the guitar music and the decreasing health meter. Begin playing notes and note the presence of lead guitar music and the now increasing health meter. As appropriate, demonstrate and note sound effects and special items. Demonstrating Music Synthesis Prepare the corresponding .mid and .mp3 files. Load the MIDI file into the Note Generator App. If possible, remove or dampen the lead guitar on the .mp3 file to create a second .mp3 file. When the notes are generated, save the Notes file and .mp3 files and load them into the core game. Play the song for all difficulties and instruments, taking note of the rules for the given circumstances (minimum note distance, number of keys, etc). 2.5.2 Schedule of reviews, walkthroughs, inspections, and audits First team review for first milestone: Feb 20, 2009

3.0 Team-specific aspects

3.1 Management Objectives and Prioritories

Management Philosophy

As a team, we demand professionalism from our teammates.

Agree to communicate honestly and openly with all personnel.

Willing to work with others as well as work individually.

Understand success requires action.

Goals

Our goals are to gain as much experience as we can, while passionately deliver a complete product.

Priorities

Our priorities are the quality of the product and quick response in communication.

3.2 Team name

Grim Tides:

Taken from the last name of team member Bradley Grimm, Grim Tides was selected for its irony. For while the Tides may be Grim, one can always stay inside and play our game.

3.3 Possible Meeting Times

▪ Wednesday: 5:30 pm – 7:00 pm 3.4 Team's Range of Skills and Experience

Glossary: 1 = very experienced, 3 = some experience, 5 = no experience

Bradley Brian Faires Derrick Birkes Jaden He Grimm C 2 1 3 3 C++ 1 2 1 2 Game Design 2 3 3 3 Game Mods 3 2 2 2 HTML 4 4 4 4 Java 1 3 3 3 C# 1 1 3 2 Maya (Autodesk) 3 5 2 1 MySQL 5 5 4 5 Photoshop (Adobe) 3 4 4 3 PC/Windows 1 1 1 1 Software Testing 2 2 3 1 XNA 3.0 2 3 3 3

4.0 Preliminary Sketch of Project Requirements

4.1 Overview of Functional Requirements

The function of our project is to provide entertainment for the users of our game. This enjoyment comes from playing the game and interacting with other users.

4.2 Overview of Data Requirements

The core game does not require any input from the user and does not output any data. The users will have the option to provide their own songs to play in the game.

4.3 General Constraints, Assumptions, Dependencies, Guidelines

Our game will only work on Window’s operating systems and on the Xbox 360. To be able to work on the Xbox 360 we will have to conform to the standards set forth by the XNA framework.

4.4 User View of Product Use From the users point of view our project is a simple rhythm game that also has the option for users to supply their own songs to play. A user can get their favorite song and add it to the game so that they can play it. They will also have the option to choose different input methods such as a keyboard, controller, guitar, or a midi keyboard. Here is a typical scenario, Fred hears an awesome song on the radio and he really would like to play it in the game. He goes and buys the song and then loads it into the game. Fred really likes to play the guitar so he chooses that as his instrument. He then plays the song in the game with the guitar.