Final Report:一三三七
From CS 160 Fall 2008
Contents |
The Team
Problem and Solution Overview
A growing number of people in the United States are either overweight or obese. Contributing to this trend is the constant arrival of new video games, which makes the idea of going outside to exercise less appealing. Our solution to this problem involves directly rewarding people for doing real cardiovascular exercise in the form of a game called FitWars. In FitWars, a user plays a fighting video game while running, either against the computer or against another human; in addition, the player earns points for his efforts, and can apply these points to in-game item purchases or transfer points to other video games.
Target User Group
The target user group of this game are people who like playing games. They wish to maintain their fitness, grow their fitness, or just be fit, and avoid a stereotype. They love games and having fun, but are under peer pressure, and are conscientious about their appearance. For them, exercise and becoming fit is hard work, and is rarely fun. Games and exercise can each be very time consuming so for our target user group, its usually one choice or the other. Often the choice is to have fun in the most direct and quickest way possible, game play.
Tasks
Easy: Register a username and log in
The first representative task involves registering a username and password with an e-mail address, and logging in with the newly registered username. We chose this task because the user must first be able to register and log in before he can access any other part of the interface.
Medium: Sending a message to a friend
The second task involves sending a message to another user. The messaging interface is another integral part of the game, because it provides the user with a way to organize competitions as well as a way to have friendly chat with other users. This task helps test the ease with which the user can navigate through the menus of the interface.
Hard: Playing against another person and going through the game itself
The third task is the gameplay itself - the user must enter the name of another user and play against that user. This is the central task of the game, since the user will be going through this task while exercising.
Design Evolution
Initial sketches and low-fidelity testing
In our earliest version of the interface, the user was presented with a simple login screen and could choose to either register or log in with the entered username. During our low-fidelity testing sessions, one major problem that testers faced was the ambiguity of the opening login screen: it was not clear that the "register" button took the user to a separate registration screen in which he would have to reenter a username and password. In addition, testers were confused by a screen asking for the name of a referring user.
With our main menu, our goal was to provide the user a direct way to accomplish all of the major tasks (play against the computer or another player, send messages, check stats, and transfer points). Our low-fidelity testing showed that this menu was unclear, as well: there appeared to be two separate buttons to access mail, and the meaning of "CPU" was unclear to one tester.
 The login screen of the paper prototype |
Our idea for the gameplay involved the simple left-to-right movement of a character across a two-dimensional course. At random times during a run, the user would be told to do certain physical actions (run, jump, or spin) - the purpose of this was to keep a jog entertaining and unpredictable. We did not have a clear theme for the gameplay in mind - two ideas we had in mind were a "hardcore" Warcraft-style character, or a more cartoon-like character.
 The gameplay of the paper prototype |
Another general problem we found during our low-fidelity testing was that users were unsure of the results of their actions: when sending messages, testers said that they preferred to have confirmation screens; and some users had trouble remembering exactly where certain buttons took them.
 The messages interface |
 Points management |
Pilot usability test
With our next version of the interface, we sought to fix the problems we discovered through low-fidelity testing.
Major changes
General changes
- Moved the "back" button on most screens to the lower right corner, for consistency
- Made the pathway of each "back" button more clear
- Added confirmation screens following the sending/deleting of a message
Main menu changes
- Removed the "messages" button from the menu, since there was already a mail notification button at the top
- Changed "CPU" to "computer" for clarity
- Added small descriptions below each button when that showed when the user hovered over it
Gameplay changes
- Changed the game theme from a more serious style to one with a more cartoonish appearance
- Changed the gameplay from a simple left-to-right character movement to one in which the user will occasionally have a one-on-one, first-person fight
 The main menu |
 New one-on-one gameplay |
 Example confirmation screen |
We found that the low-fidelity prototype testing brought gave us more information than the pilot usability tests. This is largely because we went through with our pilot usability tests individually - it was difficult to organize the tests and keep note of all of the important observations individually. The low-fidelity testing sessions, on the other hand, were slower (since a human was acting as the computer), and involved more observers, so keeping track of significant observations was easier.
Final Interface (4 pages + screen shots- reference figures!)
Functionality
Create a virtual character and compare with other users
By registering a username in Fit Wars, a user is creating a virtual character. The character starts out with an avatar, and with earned points, the user can purchase items to add to the character (as described below). The game keeps track of the user's exercise statistics, and allows the user to compare his statistics with others'. This functionality provides the user some motivation, since improving one's ranking among users gives the user incentive to exercise and go through the game.
Communicate with other users
Fit Wars allows the user to communicate with other users through the game's messaging system. This operates in a similar way to the Mail application on the iPhone and iPod Touch. The game provides this functionality for convenience: it provides users with an easy way to organize battles with each other, and it also provides an easy way to do send simple conversational e-mails without having to switch to another e-mail application altogether.
Play a game while exercising
Fit Wars provides the user a way to play a game while running. The user has two choices: he can either battle the computer, or he can battle another human player, in which case he can choose between entering the username of another player and having the game choose a random opponent. The gameplay is driven the the user's movement (in the intended iPhone application; since we are using Flash, we are substituting arrow key presses for actual movement).
Buy items with earned points
Through successful gameplay, the user accumulates points. With these points, the user can purchase items in the virtual store provided by the game. Items that the user can purchase include swords and armor, and purchasing these items builds up the user's virtual character.
Transfer points to other games
The user can also transfer earned points to other games. The use for these points in other games is open-ended - developers can choose to allow points from Fit Wars to be applied to their games; and by entering the name of a game, a Fit Wars user can transfer points to it. The reason for this is motivation - if a player is used to playing conventional video games, the point transfer system can provide an incentive for the user to exercise and earn points to apply to another game.
Interface design
Create a virtual character and compare with other users
The user begins by registering a new username and password. This is done by pressing the "register" button and following through with the registration instructions. During the registration, the user can choose from one of four avatars to represent the user.
 The opening screen |
 Username, password, and e-mail address input |
 Avatar selection |
After logging in, the user reaches the main menu, from which the user can access all of the main functions of the interface. To compare his statistics with other users' statistics, the user clicks on the "game stats" button. The user can then choose to view various statistics, as well as his user ranking.
 The stats menu |
Communicate with other users
To read messages and to write messages to other users, the user presses the "messages" button from the main menu, which will take him to a messages screen. This screen contains a list of received messages, and distinguishes new messages from old messages by the color of the "envelope" image. From this screen, the user can write a new message by pressing the "create new" button.
 The main menu |
 Screen to write a message |
To read a message, the user taps over the message preview. This will take the user to a larger "read message" screen, from which the user can choose to reply to the message.
 Screen to read a message |
 Screen to reply to a message |
Play a game while exercising
The most important part of the interface is the gameplay itself. To engage in a virtual battle, the user clicks the "battle" button from the main menu, and is then given the option to battle either the computer or another human player. If the user chooses to battle the computer, he is given a choice of courses to run.
 Battle menu |
 Fight Computer menu |
 Running scene |
 Fight battle scene |
If the users chooses to battle another human player, he can choose between entering the username of a specific user to battle or allowing the computer to choose a random opponent.
 The options for battling a human |
 After a player is found |
After an opponent is chosen, the player goes through the gameplay itself. As the player runs (or in this case, alternates left and right arrow key presses), the game keeps a step count and also displays the progress of the user on a bar at the bottom of the screen.
 The gameplay |
Occasionally, the user will reach a "chance" section, at which the gameplay will switch from left-to-right movement to a one-on-one battle. During this battle, the user will receive indications that he should do some physical movement (jump, spin, run, or skip). If he fails to do so enough times, he will lose the battle. After going through the course, the game will indicate the number of points and experience earned by the user.
 A "chance" section |
 A command to do a physical movement |
 The screen following level completion |
Buy items with earned points
To purchase virtual items in the game, the user clicks on the "buy & sell" button, which will take the user to a menu from which he can choose to buy either weapons or armor. By pressing one of these buttons, the user will reach a menu of items, from which he can select an item to buy.
 Shop menu |
 Weapon Shop |
 Armor Shop |
Transfer points to other games
The final functionality provided by this interface is the ability to transfer points to other games. To do this, the user presses the "buy & sell" button from the main menu, and then chooses the "transfer points" option from the following menu. Finally, the user enters the name of a game and the number of points to transfer to that game.
 Point transfer instructions |
 Screen to enter the name of a game |
Implementation
This application was developed with Adobe Flash. In general, each screen in the interface was represented as a separate Flash scene.
A large number of screens in the interface are menus, which consist entirely of buttons that take the user to other screens. These were the simplest parts of the interface to implement, since their functionality could be implemented with a few simple functions. Also relatively low in difficulty were screens taking user input, such as the login screen. Implementing these required keeping track of some state (for example, keeping track of the username that the person entered).
The most difficult part of implementing the interface was the gameplay portion - the part involving the movement of the character across the screen. The left-to-right character movement was implemented as three different scenes (each separated by a one-on-one "chance section" battle). There are also several Flash scenes corresponding to the "chance sections". During the left-to-right movement portion of the gameplay, movement is simulated by left and right arrow key presses, which cause the background to move right-to-left. Implementing the gameplay also involved putting in various sounds and images. Because the complexity of the gameplay far exceeds that of the basic menu screens, it was the hardest part to implement.
What was left out
The absence of certain features in this interface is primarily due to the fact that we implemented an iPhone application with Flash. The following are features that we left out:
- Actual motion detection: Because the iPhone can detect certain types of motion, the intention for the iPhone application is to translate human (running) motion into motion of the virtual character. However, since common personal computers obviously lack this functionality, we replaced this with a simple alternation of left and right arrow key presses.
- Vibration of the iPhone: Another feature of the iPhone that is to be used in this application is vibration - the phone will vibrate during battle. Since PCs do not have this functionality, we cannot include it here.
- "Keyboard" functionality of the iPhone: The final iPhone application should display a pop-up touch-screen keyboard for text input, since iPhones do not have physical keyboards. Since implementation of this would not have added much to a Flash application, we did not implement it.
- A website to keep track of statistics and points: We initially had a website in mind, on which users could log in and transfer points to games, as well as track statistics. Since creation of a website on top of the implementation of a Flash application would have taken too long for this time frame, we did not make it.
Wizard of Oz techniques
For this interface, we used Wizard-of-Oz techniques to simulate the actual Internet-related aspects of the game. Since enabling these aspects would require an Internet server (whose setup would be far too time-consuming), the following were simulated in Flash:
- Message functions: The process of sending a message would require an actual connection to a server.
- Finding another human player: Having the computer find a random human player for the user to battle would require a server as well as some sort of player selection algorithm.
- Transferring points: Transferring points to another game would require a server as well as an actual game to which the user can transfer points.
