FinalPrototype-Group:Orquesta

From CS 160 Fall 2008

Team Roles

Each team member’s name and role in this assignment

Stuart Bottom

• Final prototype upgrades / refinements
• Wizard of Oz Techniques, Target User Group, Tasks, and Problem and Solution Overview writeup sections
• Poster edits
• Presenter

Anthony Kilman

• Final prototype upgrades / refinements
• Design evolution

Greg Nagel

• Final prototype upgrades / refinements
• Presenter

Jimmy Nguyen

• Final prototype upgrades / refinements
• Presenter

Vedran Pogacnik

• Final prototype upgrades / refinements
• Functionality, User Interface Design, Items Not Implemented writeup sections
• Created Poster

Problem and solution overview

(1 paragraph - 2 points)

Aspiring Disc Jockey's (DJ's) face substantial challenges, including high fixed costs and a difficult learning curve, as they seek to acquire and develop the skills necessary for professional success in the entertainment field. DJ equipment - such as turntables, mixers, amplifiers and speakers - may cost thousands of dollars. Expensive, heavy, and difficult to use, this equipment makes it difficult for people to get started as a DJ, or try DJ'ing to see if it is something they like. Even with the proper hardware, the learning curve is steep; developing essential DJ skills and perfecting technique may be difficult without performance-based feedback or helpful tips from knowledgeable DJ's. To address these challenges, our group has developed a serious game called "Orquesta," designed to teach basic DJ skills for free. It does not require any hardware other than a personal computer, and since it is implemented in Flash, it can be distributed over the Web for free. The skills it teaches are essential for any successful DJ, and include such concepts as following a beat and making musically-correct transitions between tracks in a "beatmix." Additionally, it provides a practice mode to allow free-form creative expression and skill development, emulating a real mixing board controlling different musical inputs.

Target user group

(1 paragraph - 3 points)

Orquesta is designed for users who are interested in exploring the world of DJ'ing, or who want to learn and practice DJ'ing skills. There are two main types of users we target:

• Novice users may be seriously interested in DJ'ing as a career or hobby, but due to financial constraints or physical space limitations are unable to purchase or store actual DJ hardware. They may want to investigate DJ'ing more casually, and our game provides an ideal way for them to try it out without a large investment in hardware. Players may also be more interested in the gaming or entertainment aspect of the game, playing it because it gives them a fun way to learn musical concepts.
• Amateur DJ's are current DJ's wishing to brush up on their current skills, interested in learning new skills, or wanting to play a fun game related to their work that has concrete metrics for success, like scoring. They may use the game simply to practice their skills without the need to set up all their equipment. The game is also designed to teach more advanced techniques and professional best practices in upper levels (not implemented in the prototype, but the game framework makes it easy to add more levels to teach additional skills).

In summary, Orquesta is designed for a wide range of target users, wishing to learn and practice DJ skills seriously, or just for fun.

Tasks

(1/2 page - 5 points) 3 representative tasks to test your interface (easy, medium, hard). Remind us why you chose these tasks.

Complete the tutorial (Easy)

This task requires the user to complete Orquesta's built-in tutorial, in order to familiarize himself/herself with the game and how to play it. To successfully complete this task, the player must step through each stage of the tutorial. We chose this task because we believe it is important to understand Orquesta's interface and objectives before beginning actual gameplay. Since some players may not already be familiar with music theory or DJ hardware (which the interface mimics), they may be confused about the game's operation or goals if immediately presented with Orquesta's main gameplay screen. The tutorial is designed to remedy this by giving a full overview of Orquesta's interface, gameplay, and objectives - when a user completes it, he/she is well-equipped to use Orquesta's framework for learning DJ skills.

Obtain the power-up in Campaign Mode (Medium)

This task requires the user to complete at least three transitions (that is, turning one instrument off and another instrument on) in a row in Orquesta's "Campaign" mode. These transitions must be performed "on beat" in order to be counted. The power-up grants the player 2x the normal score they would get, and is only activated if three successful transitions are performed in a row (with no off-beat transitions or mistakes, denoted by "broken vinyls"). We chose this task because it is representative of one of the new scoring and feedback features in Orquesta; these features have two main goals. The first goal is to reward and recognize consistent good performance by providing the player with additional feedback when they do the right thing. The second goal is to promote greater immersion in the game by increasing its "fun" aspects. In turn, these can result in a richer learning experience: as the player is encouraged to spend more time in the game, they are encouraged to continue honing their skills.

Successfully complete Level 1 in Campaign Mode (Hard)

The last task requires the user to successfully complete Level 1 in Orquesta's Campaign Mode. This is done when the player successfully performs 8 "on beat" transitions without running out of vinyls (a vinyl is broken every time the user performs an unsuccessful, off-beat transition). This task was chosen because Level 1 teaches the most basic of DJ'ing skills: following a beat. The player will have great difficulty completing this level unless they have some grasp of the essential musical concepts of beat and tempo. By providing visual feedback to guide the user as they learn and rewarding correct transitions, the game allows players to build a solid foundation for future DJ'ing success.

Design Evolution

(2 pages + sketches & screen shots - 15 points) How did your UI change from initial sketches, low-fi testing and pilot usability test? Show what the major changes were and why they were made Explain which evaluation technique was most valuable to your prototype's usability and why.

Images

Fig 1a: Contextual Inquiry: Main	Fig 1b: Low Fidelity: Main	Fig 1c: Interactive Prototype: Main	Fig 1d: Final Prototype: Main
	Fig 2b: Low Fidelity: Pre Campaign	Fig 2c: Interactive Prototype: Pre Campaign	Fig 2d: Final Prototype: Pre Campaign
Fig 3a: Contextual Inquiry: Campaign	Fig 3b: Low Fidelity: Campaign	Fig 3c: Interactive Prototype Campaign	Fig 3d: Final Prototype: Campaign
	Fig 4b: Low Fidelity: Pre Practice	Fig 4c: Interactive Prototype: Pre Practice	Fig 4d: Final Prototype: Pre Practice
	Fig 5b: Low Fidelity: Score	Fig 5c: Interactive Prototype: Score	Fig 5d: Final Prototype: Score

Initial Sketches

Our initial Group Brainstorm described a general DJ serious game to appeal to a wide range of users. From the aspiring DJ to the seasoned beat-mixer. The functionality of our initial sketch was designed around the same logical progression a professional DJ would use while mixing in a studio, thus enabling players to explore each step of the beatmixing process. This can be further divided into 5 categories:

Beat Counting

A user is given a track that does not have a previously calculated BPM (Beats Per Minute) value associated with it. The user would then record an approximate BPM by hitting the spacebar each time a beat "hits" in the music. This would not only give the user more experience in detecting beats in music, but additionally create useful metadata for each track to facilitate matching tracks by BPM into compositions in the future. Once Orquesta has locked onto a BPM value, the track is paused and then saved.

Song Matching

Underlying this initial design of Orquesta would be a database of tracks; some with associated BPM values and some without. For those with defined BPM values, the song matching functionality enables the user to select a "mixing palette" of desired tracks with the same BPM which will later be transferred to the primary beatmixing interface.

Beat Mixing

This element is where the user will be able to exercise the most creativity (see Figure 3a). From the pre-selected "mixing palette" of tracks with matching BPM values, the user may now switch on tracks at the desired intervals to create a unique composition. Additional controls will enable each individual track's sound to be adjusted. These controls will range from volume settings, to equalizer settings (for example boosting bass and/or treble). Once the user is finished composing, they are able to save their track and submit it to the accompanying website for rating amongst other Orquesta users.

Mix Rating / Feedback

Here the player is prompted to play, rate, and give feedback on submitted compositions via Orquesta's accompanying website. This site will allow users to create their own DJ profile, view other DJ profiles, and additionally submit and rate compositions from other DJs on the site. From a general standpoint, the site will have 3 main interfaces: (1) displays recently submitted compositions, (2) displays previously rated compositions sorted in descending order based on positive ratings, and (3) for viewing DJ profiles. The rating system would borrow from that which is used on a popular rating site, Digg.

Track Browsing

This final element allows DJs to explore compositions by BPM, rating, date, user, etc. The idea is that as a finished product, Orquesta will facilitate music selection through attached rating and BPM metadata. In the process of generating this metadata, beatmixing principles are developed by the beginning and intermediate Orquesta user. Not only as an end product will this attached metadata make a DJ's task of music selection an easier one, but educate new and intermediate users in the process. For example a list of potential compositions organized by BPM can be sorted by average rating so only the best mixes are used for a particular performance.

Low Fidelity Testing

Our initial design turned out to be quite ambitious. Though we successfully acquired a genre for our serious game that we all would enjoy working with, we proposed enough functionality to frighten an entire army of programmers. In this iteration we honed our goals towards a more feasible, game-like implementation, and more or less decided on Adobe Flash as a platform for Orquesta.

Our revamped Low-Fidelity Prototype consisted of 3 different modes of play: Tutorial, Practice, and Campaign. Tutorial mode was a semi-interactive guide to give the user a solid foundation in the Orquesta interface. Campaign mode teaches and reinforces beatmixing skills through rewarding the user for successful track transitions "on beat." At the end of each level, a user is given the option to save their composition to play at a later time. Finally Practice mode is more of a freestyle mode, which allows the user to mix tracks together without any time or beat constraints. At the end of a Practice session the user is also able to save their composition. Additionally, a user is able to replay a previously saved composition by importing the composition from the Main Menu.

Major Changes

This iteration involved discarding a fair amount of functionality. We decided to do without: beat counting, song matching, mix rating / feedback, and track browsing. Our focus for this iteration primarily emphasizes the practice of beat mixing. As a consequence of Adobe Flash being new to us as a group, we did without the equalizer functionality for each track and drag and drop functionality. This was for the most part a result of managing complexity for a semester-long project, while still allowing us to implement an entertaining serious game.

Evaluation Techniques Used

We utilized the Low Fidelity Interview techniques addressed in lecture. Our group was broken down into several observers, greeter, facilitator, and computer. Key points that we had emphasized to each interview candidate was that the purpose of the interview was to identify potential issues before they occur in development. So they should not hesitate to identify any problems they might come across during the debriefing session after completion of the 3 tasks described below.

Each candidate was asked to complete the following 3 tasks: (1) complete the tutorial, (2) successfully transition twice in campaign mode, and (3) save a composition from campaign mode. These tasks were intended to exercise a majority of the interface in addition to being broken down into easy, moderate, and difficult tasks respectively. Each time we detected some kind of event (i.e. "oh" or "that's cool") this item was logged and discussed during the debrief session.

In total we selected 3 interview candidates, each with a varied amount of experience with DJ equipment and/or software. Luckily we found subjects that perfectly matched our intended audience. One experienced subject, a moderately experience candidate, and finally a totally inexperienced candidate. Based on their varied amounts of exposure to traditional DJ software, we gained some really valuable feedback which resulted in a fair amount of refinement for the next iteration.

Goals For Next Iteration

The interviews have shown that for the most part our design is on the right track, with the exception of visual feedback, and saving functionality. In particular, visual feedback should be utilized to notify the user a track is or is not (see Figure 3b) playing. Though our design included the affordance of GREEN corresponding to ON and RED for corresponding to OFF, this was still not entirely clear to our audience. Additionally there was some ambiguity regarding saving a composition versus saving progress in Campaign Mode. We aimed to solve this confusion by notifying the user they are able to save their composition after a level in Campaign Mode in the preliminary instructions screen, and in the preliminary Practice Mode screen as well.

Interactive Prototype

As a consequence of the previous prototype being a pen and paper prototype, the Interactive Prototype likely involved the most work as the entire interface now needed to be implemented in Adobe Flash. This involved a number of obstacles, the largest including as a team becoming acquainted with the Flash development environment and how to implement the audio functionality for our project. In regards to the number of changes since the last iteration, there were a few but not any significant enough to merit any major overhauls to the interface.

Major Changes

Changes in to our design can be broken down into 4 categories: (1) saving, (2) objectives, (3) visual elements, and (4) low fidelity specific issues. (1) Saving as was mentioned in the previous section was slightly ambiguous to several of our interview candidates. This was solved by explicitly directing the user is to save a composition at the Scoring screen after completion of a level in Campaign Mode. These directions were included in the preliminary Campaign Screen where objectives are described and instruments selected. (2) Additionally, level objectives were not entirely clear to our interview candidates. To resolve this issue we clarified objectives in the Tutorial Mode as well as the preliminary level screen for Campaign Mode. (3) Regarding visual elements and notifications, we resolved to add elements to the interface to indicate that an individual track is playing ON or OFF. This was achieved by placing labels on each knob for each of the individual tracks, as we unofficially decided to do without key bindings and the RED/GREEN indicators. (4) Finally, there where some issues with the Low Fidelity Prototype which were unavoidable: latency with audio, click-ability of elements, etc. These were not interface issues in and of themselves, but required some time to work out whether or not we needed the cursor to change for some action, notification for another action, etc.

Evaluation Techniques Used

Our evaluation for this iteration was based off of the group TBD's Heuristic Evaluation based on the criteria learned in class. Since the evaluations were easily prioritized by heuristic violation severity, it was a trivial task to realize what was most important to change for the next iteration.

Goals For Next Iteration

After group discussion of the TBD's Heuristic Evaluation, we resolved that most of the modifications required were trivial. None of which really merited significant modification to the overall interface. In order of decreasing priority, the categories of violations can be ordered as follows: visibility and system status, user control & freedom, and finally consistency and standards.

Regarding visibility and system status, we were still in need of additional visual indicators to notify the user if a transition was made on or off beat. We already had the record vinyl icon breaking, but this wasn't entirely obvious. Additionally, the knobs used to switch tracks on and off weren't sufficient indicators to our evaluators.

For user control and freedom, although we had thought we addressed the issue in this iteration, it still wasn't clear what save meant to TBD. Additionally, TBD recommended to include a separate list of tracks that may be imported into Orquesta. To address this issue, and to reduce the overall complexity of our project we decided to scrap the entire notion of saving and importing. This was also a consequence of Flash having limited access to the local filesystem, and our unfamiliarity with Flash as a group. By discarding saving and importing we not only were able to deal with that particular subset of heuristic violations, but reduce the complexity of our project significantly as this was left an unimplemented wizard of oz technique for this iteration.

Finally, regarding consistency and standards: in a nutshell our buttons were all over the place. Some were a dark blue, some where the native white Flash component buttons. Return to main menu buttons were not consistent, and button alignment was not standardized throughout the interface. This should be easily remedied by using only Flash component buttons and aligning buttons to give a standardized feel throughout the interface.

Pilot Usability

This iteration was primarily composed of fixing the heuristic violations from the previous iteration, and testing our interface yet again with a new set of volunteers. In addition to the changes identified in the previous section, the overall look and feel of Orquesta was updated. Particularly the color scheme was updated for consistency, and we adopted a vector illustration of a turntable for our logo (see figures [1-5]d).

Major Changes

See the previous iteration's list above for this iterations updates. As a group we decided to update each violation that was identified by TBA. In addition to the violations, we also addressed several issues that were listed as recommendations. These include: further clarification of level objectives in Campaign Mode and including a back button in the Tutorial Mode. One last item we assumed but never formally clarified was that there will be no key-bindings after this iteration. Previously we had left this item as a wizard of oz technique, but as a group agreed that key bindings where not necessary.

Evaluation Techniques Used

The evaluation techniques used for this iteration are very similar to those techniques used for the Low Fidelity interviews. In order to exercise most of the interface, the candidate is asked to complete three tasks. In this case, the three revised tasks were: (1) complete the tutorial, (2) obtain a power-up in Campaign Mode, and (3) successfully complete level 1 in Campaign Mode. We were required to modify the original three tasks as one of the tasks was saving a composition, a functionality we decided to do without.

In addition to the traditional interview techniques, particular heuristics where focused on to hopefully benchmark the effectiveness of the Orquesta interface. This assignment was completed individually, but across our group we each tended to focus on an event log and time it took to complete the requisite tasks. The event log allowed further analysis to examine which parts of the interface the user might be struggling with. For example, Anthony attempted to extrapolate the learning curve of the Orquesta interface by measuring the interval between transitions and comparing those results between the first attempt and the second attempts of completing tasks 2 and 3 (see Pilot Study Results).

Goals For Next Iteration

As we as a group would have hoped, most of the required functionality for the game was successfully implemented without any major flaws. Additionally most of our users indicated that the interface was relatively straightforward. The only area we still seemed to be lacking in was visual feedback. Particular events didn't quite jump out enough to the user, and across the board our results for the Pilot Usability Study reflected this. For our Final Prototype, we should address the lack of adequate visual feedback and from a general standpoint focus on enhancing gameplay.

Final Prototype

As this is our last iteration, the Final Prototype included the finishing touches required to polish off the interface. Again, most of the updates had to do with visual feedback in addition to an easter egg feature included in the Practice Mode section of Orquesta. To balance the workload, each member of our group participated in a subset of the updates which we agreed upon were necessary. Each of these major updates are included in the section below.

Major Changes

The updates we've included in the Final Prototype are as follows:

• Cursor changes on mouseover of volume sliders
• Score indicator is now more integral to the interface, with animations emphasizing positive transitions and negative transitions (red tint of controls + strike indication)
• For our first level, "Bonus Transitions" are included to allow the user to accumulate additional points after they have complete the objectives for the level
• Beat assist indicator, so the user knows when Orquesta believes it is a valid time to switch on a track
• Added theme music
• Updated the tutorial to reflect the changes made to the primary interface

Evaluation Techniques Used

As this is our last iteration, our only benchmark is to successfully implement as many suggestions provided by the CS 160 staff as feasibly possible. Also from the standpoint of a semester-long project, our aim is to have a working serious game with at least one level.

Final Interface

(4 pages + screen shots- reference figures!)

Final UI Design

Describe the final UI design

Functionality

Describe the functionality (i.e., what are the operations you can do with it) (5 points)

Main functions

• CAMPAIGN

Campaign mode features sets of objectives associated with each level. Campaign mode is meant to gradually introduce the player into the art of DJing. Every level has a time constraint and a possible mistake allowance (strikes: see UI Design section).

• LEVELS (campaign only)

The player can complete levels in campaign mode. They increase in difficulty each has a set of objectives to complete. For now, only level 1 is implemented, so there is only one (basic) type of objective: transitions.

• PRACTICE

Playing the practice mode is much like playing campaign mode in its core, but without the constraints of objectives and time limit. There are no rules, and the user creates a mix however he likes by transitioning between instruments.

During Gameplay

• CREATE MIX

The player can create a mix in two different modes of the game, campaign and practice. Additionally, the tutorial is there to sequentially guide the user through the interface by gradually revealing more parts of the interface. Having completed the tutorial, the user should have a solid understanding of how to create a mix.

• MAKING TRANSITIONS

Another functionality is making on-beat transitions- in other words switching between instruments. Utilizing more transitions helps make the mix sound more interesting. In campaign mode only on-beat transitions can be made, with a helpful error message in case of fault. In Practice mode this constraint doesn't apply.

• POWER-UP ACQUISITION (campaign only)

Power-ups are closely related to transitions in campaign mode. They create an incentive for the user to continue playing, by making in-game rewards (for now, only 2x points multiplier is implemented).

• ADJUST VOLUME

The volume of each instrument can be adjusted. Alternatively, the sound output can be turned on-off instantly (without modifying the volume per se).

• INSTRUMENT SELECTION

Prior to level start the player can also select the instruments that he wishes to utilize (a set of default choices is provided). In the campaign mode, he chooses three instruments, while in practice mode he chooses six. There is a total of seven instruments to choose from.

• QUIT / RESTART

If the player wishes to stop mixing, in campaign mode level results will be displayed. They contain objectives, completion times, points, etc. The player may also wish to restart the mix, in which case the level will revert back to instrument selection & level prompt.

UI Design

Describe the user interface design (i.e., how you use the functionality) (5 points)

Main functions

• CAMPAIGN / PRACTICE

Starting any mode of the game requires clicking the “start” button on the main screen. Campaign mode has an additional step of selecting which level to be played.

• LEVELS (campaign only)

The player starts a level by selecting it in the list that is displayed upon entering campaign mode of the game. Levels are started by clicking "GO" button on the "instrument selection screen". The player completes a level by following the objectives presented on the "instrument selection screen". Each level has a different set of objectives to complete.

Instead of penalties per se, there are strikes. There is a total of ten of them, giving the user plenty chance to fault before completing the level. The amount of unused strikes is displayed in the bottom part of the screen, in the form of unbroken vinyls. Upon a fault, each strike breaks the vinyl and is noted in the upper right quadrant of the screen, and explained. The explanation message disappears after a few seconds, in order to not disturb normal gameplay.

Each level has to be completed in a given time. If the time runs out before objectives are completed, level will fail.

During gameplay

• CREATE MIX

On the "instrument selection screen" the player clicks "GO" button, which starts the game in either modes. The first instrument starts outputting its track. Thereby the mix has started to be created.

• MAKING TRANSITIONS

Instruments are toggled on-off by clicking the button underneath each instrument. The button illuminates if on, dims if off. A transition is made by pressing the dimmed button underneath an instrument. Upon clicking it, the button illuminates signaling "on" state. There is a beat "assist" button towards the bottom of the screen, that helps visually match the beat of the sound, so that the player can make on-beat transitions easier. That button flashes to the beat.

• POWER-UP ACQUISITION (campaign only)

Power ups (only available in campaign mode) are achieved by completing three consecutive objectives. The acquisition of a power-up is displayed in the upper right corner. The acquisition message is displayed until the power-up is active.

• ADJUST VOLUME

Volume of each instrument is adjusted by adjusting the toggle on the scale that is above the instrument on / off button.

• INSTRUMENT SELECTION

Before starting gameplay of either campaign or practice mode, the player selects instruments from drop down menus. That screen, "instrument selection screen" is presented after the player has chosen which mode of the game he wants to play.

• QUIT / RESTART

On the right-hand side of the screen there is a stop button, with a restart button next to it. Each button has a label below it, identifying its purpose. The stop button stops the mix and, if it is campaign mode, displays level results. The restart button reverts back to instrument selection for either mode.

Implementation

Describe your implementation. What was most difficult to implement and why? (10 points)

Implementation: For the implementation of our game, we developed everything in Flash and ActionScript 3.0. The menu screens are essentially all different scenes that provide navigation throughout the options and game modes. Our actual game implementation consists of three game modes: tutorial mode, practice mode and campaign mode. Tutorial mode is a frame by frame navigation that will help the user learn how to play and succeed in Orquesta. It consists of many frames and adds on different implementations and features of the game as you progress through the tutorial. Users will be able to see transition successes, transition failures, see the game timer implementation, beat map assisting (described later), volume control sliders, and "DJ Power Up" mode (3 successful transitions in a row, thus resulting in doubling of points). Practice mode is intended for players to tone their skills, allowing them to play the whole game without a time out, too many transition failures, nor game level objectives. In the campaign mode, we implemented pretty much all the scoring with transition success and failure feedback, as the player try to complete the objectives of the level.

Difficulties: The most difficult things to implement were the sound and the timings of the gameplay. Sound was difficult because it involved multiple tracks and ActionScript 3.0 forced us to use multiple libraries to implement sound channels and volume. There are a lot of different resources for older versions of ActionScript, which would have been incompatible with our project, so a wrapper class was needed to facilitate the usage of our sound library as needed. What made our game as a whole difficult was the timing of everything, especially having to play 6 simultaneous tracks at once. To make sure everything was synchronized, every sound clip was made into a 4 measure mp3 sound clip mapped to 115 beats per minute. Upon initialization of our game, we would play ALL 6 tracks at once, but at zero volume. In our game, when a player clicks to play a song, it is actually just turning the volume from 0 to whatever the volume is mapped to on the volume meter. On top of this, there was a timer constantly needed to keep track of the beat of the composition. To do this, we had a timer go, but also allowed an adjustable window for error. You can see the window turn on and off by observing the track assist button and seeing when it blinks on and off. It was necessary to sync up to the entire composition, otherwise the gameplay would not be able to function as a game.

Screenshots

Provide clear and well-referenced screenshots and figures (5 points)

Captions provided below each screenshot.

Orquesta Game Modes: To begin, choose between Tutorial, Campaign and Practice modes

Tutorial mode: Complete Tutorial mode to get a better understanding of the gameplay and all the cool features of Orquesta

Pre-mode Instructions and Instruments: Before starting Practice and Campaign modes, choose which instruments you would like to use for your gameplay compositions

Campaign Mode Game Screen: In the game mode, if you score points by making transitions on beat (perhaps with the help of the Beat assist. With 3 consecutive successful transitions, earn power up mode to score double the points. Complete the objectives and score as much as you can before breaking 10 vinyls or having the time run out.

Score screen: After completing campaign mode, see how well/badly you did by looking at the explicit game stats and scores

Wizard of Oz Techniques

What was left unimplemented Any wizard of oz techniques that are required to make it work (5 points)

Strictly speaking, Orquesta does not require any Wizard of Oz techniques to make it work - it is a fully functional game that can be played on its own. Orquesta's level-selection framework and synchronization issues are worth discussing, however, as they include Wizard of Oz techniques that are not essential to game operation.

While we designed Orquesta to have multiple levels in Campaign mode, we have only implemented Level 1 to demonstrate the user interface. The level-selection framework uses two Wizard of Oz techniques:

• Level Selection Screen. The user is presented with a level-selection screen at the beginning of Campaign mode, which allows them to select which skill level of Orquesta they want to play. Presumably, the button for each level will be enabled as it is unlocked by a player. "Unlocking" is accomplished by successfully completing the prior level, denoted by a green "Success" title on the Stats screen. This can be considered a Wizard of Oz technique, since there is no way for the player to select a level other than 1 in the current implementation.

• "Game Not Saved" Warning Dialog. After completing Level 1, if the user tries to return to the main menu, they are presented with a warning dialog that tells them they haven't saved their progress yet (they'll have to redo Level 1 later if they don't save). This, too, can be considered a Wizard of Oz technique; because there is no level greater than 1 in our final prototype, there is no mechanism to save the level progress in the Stats screen. However, the warning is still there (as if there were multiple levels).

We included these Wizard of Oz techniques in the game because we still wanted to demonstrate what Orquesta might look like as a finished product with the ability to choose from multiple levels of play. The last Wizard of Oz technique used in Orquesta deals with the synchronization of visual beat indications with the actual music:

• Synchronization: Flash has synchronization issues, so the timing of visual indications is not fully synchronized to the music. We managed to get it close, but the difference may be more noticeable on some computers. We believe this to be more a limitation of Flash than anything in our control. Thus, the visual indicator itself may be considered somewhat of a Wizard of Oz technique as well, since in our implementation it is not strictly "locked" in synch with the beat of the music.

Items Not Implemented

What was left out and why (5 points)

While we had to implement most game functionality because of its fast pace, we did omit a few additional features so that we could focus on making the game itself more enjoyable.

Multiple Levels were not implemented. This way we could focus on the interface elements of that level and abstract them to the whole game, which is the focus of this course.

Saving was left out of the final game. A computer program can only teach fundamentals and sharing the samples would have been beneficial. However, the implementation of this feature would have been infeasible due to flash limitations, and users were confused when we included it with Wizard of Oz techniques in our first high fidelity prototype. Additionally, it diverted our attention into making Orquesta into a full mixing application--not a game. We decided to focus our efforts elsewhere.

Importing Tracks was a third feature we wanted to players to have. However, this feature was also difficult to implement, and its benefit would be marginal. We again had trouble with Wizard of Oz techniques in the first prototype, so we decided to remove it from the final version.

Multiplayer was another feature that was discarded. In previous versions of the game there was talk about making an online rating system where the players can vote on each others' tracks. However, for the purposes of this class, we stuck to user interfaces instead of going off creating a cool game. The emphasis of this class is on the interface itself, so we chose to stick to it. Whether to include the multiplayer feature or not would not change Orquesta in-game interface whatsoever was and hence discarded.

Finally, there were many minor features we wanted to implement. We had many ideas for bonus levels, high score screens, flashy graphics, alternate forms of input, and more. There was only so much we could test, and we tried to focus on the feedback that we received. In the end, we are happy with how Orquesta turned out.

Final Prototype Demo

You can try the latest version of Orquesta yourself online here.