Prototype Testing with the Kids

On Saturday, November 22, our team met with our kid design partners Rolanda, Garreth and Steven for the purpose of testing our game prototype. Design team members Amy, Larry K, and Larry W conducted the test with Amy serving as team spokes person, Larry W as game play controller and moderator, and Larry K as the observer and note taker for the test.
During the audio/visual set up, before the kids arrived, we experimented with various projector setups. Various ideas had been discussed at previous meetings about the best way for the team to simulate an Eye Toy interface. We eventually came to the conclusion that a single projector set up was the best solution. Positioning the player between the projector and the screen allowed us to use the player’s shadow as the ‘avatar’ for the game. The player was then able to interact with the game interface by ‘touching’ the screen with the shadow of their hands.
We started the test with team member Amy explaining the story line of the game. She then showed the kids the game screen, explaining how each of the elements on the screen facilitated the game play. After explaining how the game works, the initial feedback from the kids seemed positive. Garreth especially like the idea of how the pitch control mechanism worked, noting that he had some experience reading music.
At this point, we let the kids actually play the game. First up was Garreth, who seemed to get the hang of the required movements of game play fairly quickly. He was particularly successful at using the pitch control mechanism. Although the musical staff of the game was fairly high on the wall and seemed difficult to see from the players standpoint, Garreth still was able to ‘read’ the music on the staff in an efficient enough manner to successfully execute game play.
At one point during Garreth’s first round of play, he discovered the part of the game where bottles are thrown from the audience – a game element triggered when a player is doing particularly poorly. At this point, the player must dodge the bottles by moving their bodies out of the way of the bottles trajectory. For a while, Garreth intentionally did poorly so that he could dodge the bottles. The team feared that this aspect of the game may coax the player into intentionally doing poorly to trigger this ‘fun’ part of the game. Fortunately, the reward of getting a higher score outweighed the temptation to dodge bottles, and this part of the game play did not become problematic.
Garreth eventually finished the game with a score of 16,000 points in his first round of play, and 28,400 points in his second.
The next kid to play the game was Steven (aka ‘Bob the Chicken’). Like Garreth, he too quickly acclimated himself to the movements required to play the game, although he had more trouble with the pitch control aspect of the game. When a pitched song event was indicated in the game play, Steven was more likely to just hold his hand over the pitch control without making the required up and down movements. Since our game feedback mechanism was being particularly generous, it is likely that Steven was not being properly penalized for this inaction. As a result, he did not work to improve this aspect of his game play.
Steven finished his first round with a score of 17,400 and his second round with a score of 25,100.
Next up was Rolanda. She too had problems grasping the pitch control aspect of the game play, but still was able to quickly figure out the other elements of the game. The way she played the game brought out an interesting phenomenon. Because this game was quickly prototyped, the music events on the screen (especially the drum parts) didn’t always match exactly to the song that was being played. When Rolanda played the game, and there was a long string of drum events to be played, she tended to hit the drums in rhythm with the audio track. The team found this observation to be interesting in that it demonstrated that the kids where not only reacting to events on the screen, but also acting on what they were hearing as well. This was a satisfying finding, proving to the design team that kids where making the audio/visual connection imbedded into the game play.
Rolanda’s first round of play netted her a score of 23,300 points, while her second round netted 32,000 points.

Sticky Notes Session
Some interesting comments were made by the kids during the sticky notes session. The most illuminating positive comment was made by Garreth, who remarked that the game was ‘fun right now’. He further clarified this point by saying that other game prototypes that he had encountered seemed like they would be fun after further development, and that this game really fun even though it was still an early prototype.
The kids also noted that the game was easy to understand yet challenging to play, making playing it for the first time fun. They also like the part of the game where the audience throws money and bottles. These extra bonus game play events seemed to make the game more challenging and rewarding. The kids also like the fact that the game was physically engaging, and found value in the exercise that playing the game provided.
Even with the mention of exercise as a positive aspect of the game, one kid commented that getting tired was a bad aspect of the game. Other negative comments included that fact that the game only had one song. It was explained to the kids that this was only a prototype, and that the final product would include a multitude of songs of different genre. Another negative comment was that there was only six possible interface items on the screen. The kids thought that more interface widgets would make the game more challenging, making the game more fun.
The kids also had many helpful suggestions for features to be added to the game. They all agreed that having different career paths in the game would be fun. These career paths could include different genres of music and playing concert circuits appropriate for that style of music. The kids also suggested the game should be challenging right away, but not so hard that it would make them give up. They talked about games that they had played in the past that were too easy in the beginning, making them not very fun. The kids agreed that our song was challenging enough for a first attempt, and that the songs should get more difficult as the game progressed.
Other suggestions included making the crowds more unforgiving as the game progressed. This suggestion coincides generally with the concept of making the game more challenging as the player moves farther into the game. There was also a suggestion that called for giving the player the ability to throw things back at the audience, or to be able to crowd surf and stage dive. Multiplayer game play was also recommended by the kids.

Conclusion
Overall, the prototype seemed to be a great success. This was proven by the kids desire to play the game again and again. The kids input before and after the design of the prototype really helped the design team find game play that would be fun for the kids. The entire process seemed to be both productive and successful.

Kids Team Ramp-up & Assignments

The RockStar prototype session on the 12th was a success in that it revealed a number of areas needing revision/improvement before bringing it to the kids.

LWaldman is incorporating the following revisions to the animation…
1. A visual cue is needed to indicate that vocals (in the song) = words (on the musical staff) = microphone (on the playing interface). A microphone icon will be added to the front end of all vocal sections to indicate that the players should “grab” the microphone during the vocal sections.

2. An icon for Cymbals is missing and will be added to the interface.

3. The pitch feed on the musical staff and pitch interaction scale need a visual concept to reinforce their “sameness”. The indicator on the pitch interaction will be rendered as an orange rectangle (the same color and basic shape) to show the relationship between the two items.

4. There are too many drum beats (right and left drums indicated by drums scrolling across the muscial staff feed) for the player to possibly keep up with at this phase in game development. Drums will be pared down to a more playable level.

Sound effects are needed to indicate successful and unsuccessful game play. LK will produce boos, cheers and pitch shift tracks that can be cued manually during prototype play.

AK is handling AV equipment and will bring the portable projector and a red-lamp that may be used to reinforce shadowing.

During KidsTeam prototyping, LWaldman will act as The Computer, translating player motions to keyboard strokes. AKnox will Narrate the process and LKing will take copious notes for post-prototype briefing and future development.

EyeToy Prototype

You can download the exe version from http://student-iat.ubalt.edu/classes/waldman/etmusic1.exe

I tried making it playable in the browser, but when I tested it the sync between music and animation was way off.

A lot fewer drums in this version.

Sorry Larry K for not using the different pitches. I would have had to added more buttons to press during gameplay. I figure the fewer buttons I have to press the better.

Keyboard commands:

‘spacebar’ to start.

‘r’ to reset game during gameplay or after game finishes.

‘j’ player hit button at correct time. +100 pts.

‘h’ player missed. -100 pts.

‘n’ for animation of bottle hitting player. Best to press ‘n’ while bottle is in air. -100 pts.

‘m’ for animation of player catching money. Best to press ‘m’ while money is in air. +100 pts.

Bottle animation plays when this score reaches 2500 pts. It plays again every -500 pts below 2500.

Money animation plays when score reaches 7500 pts. It plays again every +1000 pts above 7500.

Have fun.

Larry W.

11/15 Prototype Update:

The bottle will throw after 5 boos in a row regardless of score. Player will not loose points if money isn’t caught. And there are some other minor changes.

Game sounds

Links to game sounds:
http://extrafancy.net/idia612/audio/don’tFunkWithMyHeart_pitchUpLittle.mp3
http://extrafancy.net/idia612/audio/don’tFunkWithMyHeart_pitchUpAlot.mp3
http://extrafancy.net/idia612/audio/don’tFunkWithMyHeart_pitchDownLittle.mp3
http://extrafancy.net/idia612/audio/don’tFunkWithMyHeart_pitchDownALot.mp3
http://extrafancy.net/idia612/audio/boos.wav
http://extrafancy.net/idia612/audio/applause.wav

Events of the Nov. 5 pre- and post-class meetings

AUDIO: LK’s audio analysis is complete and has been forwarded to LW for incorporation into the animation. LK will also develop four alternative tracks to use for error indicators.

VIDEO: LW is hot on the trail of Flash 8 capabilities and may be able to craft a “playable” prototype by next class. At the minimum, he’ll know by Tuesday (Nov 11) if it’s do-able and, if so, will head down the interactive animation path.

VIDEO ALTERNATIVE: If the playable prototype is not to be, the Team will still use Flash animation in the prototype but take a different route for the interaction – using the camera/ projector/ monitor set-up AK has been formulating as a contingency.

Regardless of prototype option, team will conduct preliminary testing on Nov 12.

What’s new this week

This week we decided on what to do next for our project.

Larry K will make notes specific notes about the game play and send them along with is art to me.

I will take Larry K’s art and use his notes to make the game interactive in Flash.

Amy will look into how to make this game prototype into a EyeToy game.

Amy I just found something that may make your job a lot easier. Apparently, you can make an EyeToy games in Flash 8 (I don’t have it yet. I might try to pick up a copy on Saturday at the school book store). Examples are at http://www.playdocam.com/ (a webcam is required). You can read how they created the games here.

UPDATE: I just ordered the upgrade (there was a $60 difference between the academic and upgrade). I’ll see if I can make any EyeToy effects with at after it arrives.

EyeToy Game Story

This is not set in stone.

There will be four sections to the game:
1. The Tutorial, which will teach the player how to play the game and the Tutorial will be presented as an audition to the band.
2. Free Play, where the player has a choice from 57 venues and what song to play.
3. Battle of the Bands, where the player can play against another player.
4. Tour, where the band goes on 20 or more show tour (depending on how well the player does). Can be played with 1-4 players. In single player mode, one player plays all the instruments. In multi-player mode, other players play other instruments.

Two venues in Tour can not be played in Free Play: The Best Venue and The Worst Venue.

In Tour, there are 59 possible venues. The venues will be ranked, from best to worst. Before each gig, the player will have a choice of three venues. Each of the three venues will have the same ranking, but different types of music will be played at each venue.

The player’s tour begins with the choice of three 19th ranked venues.

If the player does well, three better venues will be unlocked. The better venues will be larger with a harder song to perform.

The audience will let the player know if he/she is having a good or bad performance. If he or she is having a bad performance, the audience will boo and throw stuff at the player on stage. The player must dodge the objects.

If a bad object hit’s the player, game play will become harder.

If the player is having a good performance, the audience will cheer and throw things the player will want to catch.

If the player has a bad performance in one venue, the next performance will be at a worse venue. At a bad venue the songs will be easier, but the audience will be more willing to boo and throw bad things.

If the player has three bad performances he/she ends up in The Worst Venue, which is the 20th ranked venue. If the player performs well at one of the Second Best Venues (2nd rank), the player will perform at The Best Venue (1st rank).

First Interface Mock-Up

Ok, here it is. I will show you an image first and explain it second:

Eye-Toy Interface
Click on the picture for a larger image

So, this is how it works:
The music staff at the top of the screen moves from right to left, with the dotted line located on the left hand side of the screen staying stationary. On this staff, there are various icons that represent what instrument is to be played at any one time. For instance, when the drum marked ‘L’ reaches the dotted line, the player must ‘hit’ the left drum.

The next icon on the staff indicates the synthesizer part in the song. To play the synthesizer, the player must ‘grab’ the synth icon with his left hand. The player then must ‘control’ the pitch of the synth by following the musical note on the right hand side of the screen with his right hand by moving his right hand up and down. The closer the player comes to following the pitch of the synth with his right hand, the better he will do in the game.

Next on the musical staff is the microphone icon. This signals the player that it is time to ‘sing’ the song. The player ‘grabs’ the microphone and follows the pitches of the vocals with his left hand. Also, there is a bouncing ball that helps the player follow along with the melody of the vocals.

During the game, there must be some sort of real time feedback as to how the player is doing. For drum parts, an exaggerated audio sound of the drum playing out of sync with the game’s music will indicate that the player has missed the beat. The farther off the beat the player plays, the more exaggerated the bad note will sound.

A similar phenomenon will happen when the player is using his right hand track pitches. For instance, when the player is ‘playing’ the synth and his hand is below where the proper pitch should be, a pitch that is slightly below the proper pitch will be played, signaling to the player that the have missed the mark.

Example Music

So, it appears from the three previous posts that we are in agreement with the overall high level concept of the Eye Toy game in which we are working. In short, we have decided to create a game where a player or players are aspiring to be musical superstar. To achieve this end, the player must work his/her way through the live music circuit, playing show venues that span from the smallest, seediest nightclubs, all the way to the largest, most prestigious arena venues. During these ‘shows’, the player must ‘play’ along to the game soundtrack by activating and ‘playing’ each of the instruments and ‘singing’ the vocals. These interactions will be activated by the player using his/her whole body, with the Eye Toy as the interactive medium. The more accurately the player ‘plays’ the song, the more points he/she will score. The more points the player scores, the faster he/she will move through the concert circuit.

Now that the basic concept of the game is completed, we must now figure out how the player’s interactions will control the music in the game. This has proven to be a bit difficult, so we as a group have decided on a two prong approach to solve this problem.

First, we looked to another game with a similar theme. The game Donkey Konga is a game where the user plays a conga interface (the conga controller is included with the game) to play the beats that accompany the game soundtrack. The more accurately the player plays along with the music, the more points he/she scores. This is similar to our game concept, yet the Donkey Konga only has to deal with the rhythm of one instrument. Our game will not only be tracking the rhythm of multiple instruments, it will also have to track melodies as well! And, our controller is the entire human body put in front of a video camera.

Where Donkey Konga did give us a good idea was in the way the music is ‘notated’ in the game. The player must follow along with the music by following the rolling barrels. A set of color coded barrels roll from right to left on the screen. At the left hand side of the barrel’s path is a target. When the barrel reaches the target, the player must hit the appropriate conga (congas come in pairs). A barrel of one particular color indicates a hit on the left conga; another color indicates a hit on the right one. Still another color indicates hitting both congas, while a fourth color indicates that the player must clap his/her hands. What we must do now is find a way to modify this indication mechanism to fit our game where both rhythm and pitch must be performed by the player.

Our second strategy was to pick some songs to listen to, and come up with ways that we could have players ‘play’ the songs with there body movements. For this exercise, we picked the following songs:

Songs for Prototyping
We Will Rock You
Bohemian Rhapsody
Devil Wen’t Down to Georgia
Is This Love
Don’t Funk With My Heart
Black Magic Woman

So for next week, each of our group members are going to take these songs, listen to them, and come up with ideas for the interface of the game. Our biggest challenges will be to figure out how the player will indicate pitch and rhythm, how the player will determine which intrument they will be playing at any one time, and how the game will ‘notate’ on the screen what they player’s next gameplay musical action will be.

-LK

Larry W’s Kid’s Team

I liked many if the ideas from the Kid’s Team meeting including the story of trying to become a big band, the dodging or catching of things the audience throws at the player, changing the player’s look, Guitar Smashing and the Head Cutting contest.

Most of these ideas can be easily incorporated into an EyeToy game. But, it does leave some technical questions. Should the player in the game be represented by his/her video image or by an avatar? If the video image is used, the main image on the screen would probably be a static shot (no camera movement). It would look like the audience was behind the player, unless the player physically places the camera to shoot him/her from behind (problems might occur if the camera has the monitor in the frame).

If the player is represented by an avatar, then options like EyeToy Cameo can be used. EyeToy Cameo allows the player to create an avatar which looks like himself/herself. But, the process looks a little boring and technical (one of the steps is putting plot points around an image of the players face). Other avatars should be available for players who don’t want to go through the EyeToy Cameo process.

Having the player represented as an avatar would free up the game visually and allow for some camera movement. The avatar could face the audience, which would look better. But, what if there was a little of both the avatar representation and the video image? Have the player be the avatar he could control by dodging and have a faded video image to hit the hot spots. I think that interface was used in the game EyeToy MonkeyMania (not available in the US).

I think the problem is how the player plays the instruments. Moving hands over hot spots at the right moment can work, but we have to be careful to place the hot spots where they wouldn’t be activated while the player is dodging stuff thrown at him/her.

This is going to be fun.

Next Page »