FailBall
The Game
FailBall is a game that myself and 4 others (Mike Lippold, Stephen Damm, Nelson Wong and Andre Doucette) built in October 2009 for a competition at UIST 2009. The challenge was to design and build an application for the new Microsoft pressure sensitive keyboard. After a number of brainstorming sessions we decided to make a game, and that game was Failball.
In FailBall you must balance a ball on a teeter-totter longer that your opponent. To accomplish this the players must perform a twister like challenge using their fingers (one handed, using two hands was considered cheating). Each player uses one side of the keyboard, and has an equal number of keys.
At the start of the game players would be presented with two keys each, which they had to press and maintain a constant level of pressure on. When the game began a ball would fall from the top of the screen onto the teeter-totter. Players were each given three lives, the first player to lose all his or her lives failed at the game. :)
There were two challenges that players had to constantly deal with. First, every few seconds one of the keys that the players had to press would change, forcing the players to move one of their fingers. Pressing the wrong key would cause the teeter-totter to wobble (and their meter to drop) and eventually topple (when their meter reached empty). Second, each end of of the teeter-totter had a weight attached to it. Players had to adjust their pressure accordingly. The side with the smaller weight needed more pressure than the side with the bigger weight in order to be balanced correctly.
Visualizations
The game offers three forms of visual feedback to players. The teeter-totter is the primary visual feedback, showing the player how well they are performing. The teeter-totter is designed to be the main focal point for the players attention. The keyboard shows the player the current key they are pressing and how hard. The visualization accomplishes this by adjusting the alpha value on a coloured tile covering the currently pressed key, the more solid the colour the harder the key is being pressed. The keyboard visualization also acts as a reference map because players can determine where they need to move their finger next with respect to the current position.
The meter represents both a timer visualization and a way to modifier an undesirable strategy. During early playtests we realized that the best method of play was to constantly tap the keys making small adjustments to the teeter-totters position. However, this wasn't how we intended the game to be played, so we needed a way to ensure that players kept their keys pressed rather than simply tapping. The meter decreases whenever the correct button is not pressed. The player is shown visually when they are not pressing the correct key. If the meter is fully depleted then the ball is automatically dropped, causing the player to lose a life, or perhaps the game.
Playing
Each game takes about 1 to 2 minutes to finish, depending on the performance of the players. The engaging aspect of the game is found in the direct competition between players. Players will often play many games in a row for a chance to beat their opponent. However, scores are not maintained between games.
Contribution
In this project I acted as a designer, illustrator, and developer. Each of these roles were shared between the team except for role of illustrator. All the art was original and created by me, using adobe Illustrator. We wanted the overall style of the game to look kind of like pencil drawings on a piece of loose-leaf paper, and I think we were successful. The design of the game was a collaborative effort, I think this made the game better overall and I don't think it's possible to separate out individual part.
In development I was co-responsible for the physics of the ball and the teeter-totter, graphic integration, the implementation of the meter, and other little bits here and there.
Once we really started working we built the whole game in just over two weeks. The whole process was intense, but a ton of fun and I learned a great deal about XNA through the project.
Conclusion
I'll conclude by answering some questions that you as a reader may have:
Did you win?
We didn't. There were many entries into the competition. While I do feel that our project was better than most there, the judges didn't agree. In hindsight, we may have made the game a touch too hard for beginners to play, because it required a few tries to get the hang of it.
Can I download and play FailBall?
No, unfortunately you can't. The game can't be played without a pressure sensitize keyboard, the game will not start without one. If you remove the pressure aspect the game becomes super lame.
Can I download the source?
Again no, this was the first XNA game that I and all but one member of the team had built, so the code is a mess and in many respects done incorrectly. Also I wasn't the only developer on the project so it's not solely up to me.
