Final Report-Group:Lucky Seven
From CS 160 Fall 2008
Contents |
Each team member’s name and role in this assignment
James Yeh: Tested game and evaluated interface, worked on final report.
Michael Boulos: Worked on final report, created presentation slides.
Antony Setiawan: Worked on debugging and added extra features to gameplay, created instructions slideshow.
Yuta Morimoto: Worked on improving game interface, including settings screen, upgrades, etc.
Problem and solution overview
The system being evaluated is Defend Your Body, a serious game that aims to improve its audience’s eating habits through feedback provided during gameplay. The game is a strategy type game, and the main goal of gameplay is to defend a human body from taking in an excessive amount of food, while helping it consume a healthy balanced diet. Extra features such as upgrading the body’s organs help familiarize the player with the functions of these organs, while enhancing gameplay by aiding in tackling the increased difficulty of each new wave. In addition, the settings feature allows the user to enter his or her age, height, weight, and level of physical activity; these stats are then integrated into gameplay such that the player is given a realistic view of what nutrient levels are required for his or her body type. Lastly, the highscore feature allows the users to compete with other players online. Since many college students lack the knowledge of keeping track of a healthy diet, our game is designed to simulate choosing the healthier options and eating the right portions of food (i.e. balanced diet). Our goal is to provide an entertaining but informative tool for users to learn about creating a healthy balanced diet, and we want our users to not only become more familiar with regulating a balanced daily intake of nutrients, but also be able to make quick and subconscious decisions on which combinations of foods will satisfy the daily requirement of nutrients. Since most college students find games amusing, we believe that the entertainment factor of the game will make learning about eating well enjoyable, and allow players to be exposed to information that they probably wouldn’t otherwise seek out. Since a healthy or unhealthy diet could have lasting effects on a human body for many years down the road, ignoring the habit of keeping track of what we eat could have severe consequences. We believe with this game, our target users will be able make better decisions about what they eat by just playing the game a few times a week.
Target user group
Our target users are college students within the age group of 18-25, who currently do not eat very healthy and unbalanced diet, but would like to have a more healthy and balanced diet. Rationale behind choice of target users: While the "Freshman 15" is just an expression that people often laugh about, the truth is that many students actually gain weight during their time in college. This is because a lot of college students either do not have the time or information to make healthy eating choices--and as a result, their bodies suffer from poor choices. If these students were educated about a what kinds of food were healthy and what unhealthy foods could do to your body, they would be more aware of what they are eating and make smarter decisions about their daily diets.
Tasks
Playing the Game (Hard difficulty)
This task involves performing the main goal of our game: the gameplay (i.e. defend the body against attacks from unhealthy food). This is done in the main gameplay screen, in which waves of foods will enter the stomach; the player must selectively allow a combination of foods that will add up to a healthy diet to pass through the stomach, while eliminating the rest of the food (by clicking on it). The mouse clicking mechanism can be switched between an “absorb” mode and a “delete” mode; the user can switch between these two mouse abilities by pressing the Ctrl key and the Shift key, respectively. The user must be able to quickly alternate between these modes when decided which foods for the stomach to ‘absorb’ and which foods to ‘eliminate’ from the stomach. When a food is absorbed, its calorie, fat, carbohydrates, and protein amounts will be added to the total nutrition for that wave. The goal of each wave is to get as close to each of the target nutrient values (displayed in the top left) as possible. At the end of each wave, life will be subtracted if the food ingested for that wave deviates too much from the target values; on the other hand, if everything nutrient is within a certain range its target value, the player will be awarded with bonus points (aka positive feedback).
Upgrading Organs (Moderate difficulty)
At the end of each wave, the gameplay screen will switch to the upgrade screen. This screen contains the pictures of three organs—the heart, liver, and stomach—each of which can be upgraded by allocating points (acquired during gameply) to those organs. When the mouse rolls over the image of each organ, a small window of text will pop up and display real-life information about the organ, as well as its in-game effect. Upgrading the three organs have these effects:
Heart: repairs life
Stomach: decreases the speed of all food
Liver: doubles the maximum life
To upgrade an organ, the user clicks the “upgrade” button under the organ.
Submitting a High Score (Easy difficulty)
Submitting score should be easy and pretty straightforward. There are two conditions that have to be satisfied for a player to submit his/her score: either the player quits in the middle of the game or the player loses the game. If the player wants to quit in the middle of the game, the player must click the menu button (available in the gameplay and upgrade screens) and choose the appropriate option to submit his or her score. In addition, if the player dies (the health bar goes to zero), the player will automatically be given an option to submit his or her highscore. The actual process of submitting the score is done by typing a nickname or initials and clicking submit button.
Reason for choosing these tasks
The reason for choosing these tasks is because they reflect the understanding of our game and the flow of our design through out the game. For example a usual user will want to of course play the game, but would also like to explore more options within the game or things that will enhance the game which is the upgrade screen that we have. Also after the user has played the game, s/he would mostly be interested in comparing their skill/score with other players, and this can be done by submitting the high-score. The high-score can be submitted when the user wants to quit the game, or if the user dies. We felt that the set of these three tasks provides a good representation of the different aspects of the game, and if the user were to complete these three tasks, would demonstrate a good understanding of how the game works.
Design Evolution
Our UI has undergone widespread changes since our initial sketches, particularly in the gameplay mechanisms that we used to convey our message. Surprisingly, however, the general layout in each of our interface screens have remained roughly the same; in fact, screens such as main menu screen and submit high score screen have remained nearly unchanged. Below we will briefly describe the changes we made during each phase of the design:
The interface design of our main menu has remained the same since our initial sketches (above).
Initial sketches: From our initial sketch of our gaming interface, many of the navigation buttons/paths were already fleshed out, thus setting up much of the interface framework that we still use now. Our main goal of the gameplay was to have players look at the nutrition facts of a food and then based on that information, make a decision on whether or not to eat that food. One element of the game that we also had at this stage of the design was a recovery system where if the player died in the game, they could answer a set of quiz-like problems where they would select the healthy food out of a pair of foods. At this point, foods were classified as healthy or unhealthy in absolute terms.
The recovery mechanism represented our absolute view of healthy/unhealthy foods; this idea would later be scrapped as we realized it is more important to have a balanced diet.
lo-fi prototype: After paper prototyping the interface we had envisioned with the initial sketch and testing on our users, we came up with the first set of changes that we made to our design. Most of the changes were minor interface changes to improve the visibility and consistency of our game; we had not discovered at this point a better way to model a balanced diet or ways to enhance gameplay. Our changes included changing organ “info” buttons to mouse-rollover pop-ups, increasing the size of playable area (stomach), as well as changing the wording of various navigational buttons to make the interface more intuitive. One notable change done during this phase was substituting actual nutrition facts tabs (which contained all the standard nutrition info) into bar graph format, complete with an additive total, that we use now for our final design. This was done because our user testing proved that it simply took too long to read the nutrition facts, so a more concise and easy-to-interpret representation was necessary; plus we felt adding the nutrients of a food to a running total made more sense than isolating the consumption of each food as an individual event (this was one step closer to our “balanced diet” implementation). However, due to the limitations of lo-fi prototyping, we were not able to test some aspects of our design, such as the recovery system; it was also during this phase that we were presented with the “compelling” aspect of the game- but we brushed this concern aside by attributing it to unrealistic gameplay that may be associated with a paper prototype.
We migrated from displaying the entire nutrition facts tab to displaying abridged statistics in bar graph form, which was easier to read.
interactive prototype: The interactive prototype was the first chance for us to actually see how well our game would implement on an actual computer interface. That said, we still had a few wizard of oz techniques, namely the dynamic settings, the instructions, and the effects of upgraded organs. Notable changes, or new features, include the nutrition facts “previewing” of a food by mouse-rollover, food speeds and life that increase with each subsequent level (to make the game more challenging), and a life subtraction mechanism that makes the player lose health if too much food is consumed. It was also at the point that was decided a keyboard control scheme was not necessary—so instead, in the settings screen, we allowed the user to enter their physical characteristics, which would later to be used to calculate the goal nutrient levels (this was still a wizard of oz technique). We also decided to scrap the recovery mechanism altogether, because based on the feedback that we got, it seemed as if the system promoted an absolute view of healthy/unhealthy food, whereas we were aiming more for striving towards a balanced diet of proportionate nutrients.
In the interacty prototype, the settings screen went through a complete makeover, allowing users to input their physical characteristics.
Prototype used for pilot usability study: Based on the heuristic evaluation of our prototype, we conducted our next round of design changes and also added a few new features. In particular, we finally integrated the physical characteristics set by the player in the settings screen with the target nutrient levels presented during gameplay. This way, we could specifically model the target goals according to the player’s characteristics. We also made minor tweaks to the gameplay and upgrade screens to increase the visibility of the system status, such as changing the fat/carb/protein nutrient bars from percents to numbers, displaying the in-game functionality of organs on mouse rollover, and using two scores, “score” (for the actual score) and “upgrade points” (for the upgrade currency). In addition, we implemented the functionality to switch between the two different mouse modes, “absorb” and “eliminate”; this was due to one of our heuristic evaluators noting that our screen was too cluttered with food—as a result, we decided to provide a mechanism for the player to consume food quickly.
One of the main changes resulting from our pilot usability study was the addition of the statistics screen, which displays and overview of the results of the wave.
Changes from pilot usability study (final prototype): Most of the feedback that we received at this point in the design dealt more with the implementation of the gameplay than the navigational interface. One thing that was noticed during our usability tests was that during the later waves, the users were focusing more on clicking the food (since the food required many clicks to eliminate) than actually reading the and interpreting the nutritional values of the foods. This was probably partially due to the fact the nutrition facts for pretty much all of our foods were incorrect; as a result, we not only changed the nutrition facts to the correct values but added another 20 foods into our food collection to provide a greater diversity, higher randomness, and ultimately better representation of the variety of foods that might be encountered by the typical person. However, we also didn’t want our users spending too much time actually clicking the food (since that wasn’t the main purpose of our game), so we reduced the action of both absorbing and deleting a food to one click. Furthermore, we added a statistics screen at the end of each wave, something that we felt would provide helpful feedback to our users on what foods they should and shouldn’t eat for the next wave. The statistics screen displays the total nutrient levels consumed for that wave, the icons of the foods that were consumed, and reasons for any lives that were lost. We also fully implemented our life subtraction mechanism, such life would be subtracted if either too few or too much nutrients were consumed.
We felt that the evaluation technique that was most valuable to improving our design was both the lo-fi prototype testing. First, we felt the lo-fi usability test was a useful and crucial step in the design process because it was iteration right before we had to deal with bugs, errors, and compatibility issues that we would likely encounter when trying to implement our design on a computer. As a result, it a relatively much easier and quicker to get a “working” prototype of our game set up and start testing. Also, with the lo-fi prototype we did not have the issue of getting attached to a particular aspect of the game; since we did not spend hours trying to code an implementation detail, we were able to focus more on the overall design and gameplay aspect of our prototype, while scrapping any unnecessary functions or features. While lo-fi prototype certainly has its limitations and is mostly used for the earlier stages of design, we felt that out of all the evaluation techniques we used, lo-fi prototyping was the one that provided us with the most improvements for the time that we spent designing the prototype to be tested.
Final Interface
Final UI design
Functionality
Our game includes the following functionalities:
1) Integrate the players’ physical characteristics with gameplay:
Our game allows the user to insert their age, weight, height and the number of physical activity per week. These values will later be manipulated by some table lookups and calculations behind the scenes to provide the target calorie, fat, carbohydrate and protein levels for each wave specifically for this user. What makes this feature useful is that since each wave of the gameplay represents a day in time, the target nutrient levels for each wave reflect the ideal nutrient intake levels for the user in real life.
2) View the nutrition facts for a variety of different foods: Throughout gameplay, the user is exposed to a diverse collection of foods that they are likely to encounter in real life. During gameplay, when the user rolls his mouse over a piece of food, an abridged version of the food’s nutrition facts (i.e. calories, fats) will be displayed as a "shadow" of the current nutrient level bars in the top left corner. This way, the user can easily view what their total nutrient levels would look like if they were to ingest that food. In addition, the mouse rollover functionality lasts for a full 2 seconds, such that even if the user were to move the mouse away from the food, he would still have some time to read its nutrition facts. We have implemented 26 different types of foods, and each food’s nutrition facts provides an accurate representation of approximately on serving of that food.
3) Switch between two mouse abilities to absorb and eliminate food We offer the user two opposing mouse functions, ‘absorb’ and ‘eliminate’, that the user can quickly switch between with the press of a key. This allows the user an intuitive and easy mechanism to consume and expel foods from the stomach. When a food is absorbed, its corresponding nutrients will be added to the bars in the top left corner (the shadow displayed during mouse rollover will become solid). When a food is eliminated, its icon will disappear and nutrients will not be added to the wave totals. The “shift” key switches the clicks to absorption mode, while the “control” key switches to delete/eliminate mode.
4) View details of the results of each wave through the statistics screen At the end of each wave, the user will be prompted with a screen displaying all foods consumed during that wave, the stats of each of those foods (can be accessed by mouse rollover), and why have the user lost life (if any) from the health bar. Since this screen is displayed every wave, the user can keep track and understand how the food combination that was absorbed affects the score. Furthermore, the user can roll his mouse over any of the consumed foods to view the individual nutrition facts for that particular food. If the user clicks on any part of the screen, they'll be brought to the upgrade screen.
5) Upgrade body organs that change/enhance gameplay: Between each wave, the user can choose to upgrade three body organs, each of which would different affect a characteristic of gameplay. In particular, there are three organs: the heart, the stomach, and the liver. Upgrading the heart essentially repairs life that has been lost in previous waves, while upgrading stomach decreases the speed of all foods entering the stomach, and upgrading the liver doubles the maximum life. In addition, the user can mouse rollover the images of any of the three organs, and will be presented with both factual information about the body organ as well as the effects of upgrading that organ in game.
6) Submit a high score to an online server: Whenever the user dies or chooses to voluntarily exit out of gameplay, he or she can submit his final score. The list of highscores is maintained on an online server, and displays the top score achieved in the game. With this feature, multiple users across the network can compare their scores to see who is the best at playing the game.
User Interface Design
The numbers in this section correspond to the functionalities listed in the previous section. 1) This functionality is accessed from the setting screen (main menu->settings). Below the mouse sensitivity scroll bar, there are 4 fields for the user to set his or her age, weight, height, and hours of physical activity per week. There are reasonable range limits on each of the physical characteristics, such that the user can’t set them to infeasible values (i.e. having an age of 243). Once the user has finished setting his or her characteristics, they will click “apply” to save these values. These values will then be used to calculate the appropriate calorie, fats, carbohydrates and proteins needed during gameplay. The resulting nutrient values can be seen in the gameplay screen, in the bars in the upper left hand corner.
2) The nutrition facts of a food are displayed on a mouse rollover event, which means that if the user wants to view the nutrition values of a food, then he should hover his mouse over the food. As a result, a “shadow” bar (i.e. bar of different color) will be shown to display the additional increase in nutrient levels afforded by consuming that food. In addition, the actual numerical nutrition values of the food will be displayed right next to the corresponding bar. In addition to the nutrition values, the name, or type of food will also be displayed under the food.
3) Switching between the ‘absorb’ and ‘eliminate’ mouse click abilities is done by using the Ctrl and Shift keys—Shift changes to ‘absorb’, while Ctrl changes to ‘eliminate’. The mouse mode is also displayed on the left to provide visual feedback. Since we are combining mouse and keyboard inboard, we chose two keys that were next to each other to provide to easy toggling. Both mouse modes if used to click a food, remove the icon from the stomach in one click; however the ‘absorb’ mode adds the nutrients of the food to the wave totals, while the ‘eliminate’ mod does not.
4) We implemented a screen that will pop-up at the end of each wave and display the statistics and results of the wave. This screen displays the icons of every food that we have consumed for that wave; furthermore, if we mouse rollover any of these icons, the nutrition facts will be displayed on the top left, just as during the game. In addition ,the calorie, fat, carb, and protein totals for the wave will be displayed in numerical form. Lastly, the amount of lives lost (if any) will also be displayed in the screen, as well as the reasons that those lives were lost. As a whole, all the information displayed on this screen can be used to provide additional feedback to the player on which foods they should plan to consume for the next wave. Clicking anywhere on the screen will bring the player to the upgrade screen.
5) The upgrade screen consists of an image of each of the three organs (heart, liver, stomach). Below each image is displayed the level (of upgrade) of the organ, the cost (in upgrade points) to upgrade the organ to the next level, and the actual upgrade button . The cost to upgrade the organs increases linearly, to model a game of increasing difficulty. In addition, the total score, as well as the upgrade points the player has accumulated, is displayed in the top left of the screen. When the player upgrades an organ, the upgrade cost will be subtracted from the upgrade points. Finally, a mouse rollover on each of the images will display information – both factual real-life info and the organ’s in-game effects.
6) The screen to submit a highscore automatically pops up when the player dies, or the player can choose to go to this screen by choosing quit from the in-game menu. At the submit high score screen, the final score is displayed, and the user is prompted to enter a nickname for the highscore table. After a nickname is entered, clicking the “submit high score” button will submit the high score.
Implementation Description
For our project, we used Adobe Flex for the interface framework, and Adobe Flash for the actual interactive gameplay. Since our Flash used ActionScript 3 while our Flex used ActionScript 2, much of the troubleshooting of the implementation involved integrating the Flash interface into the Flex framework.
Menu
Our implementation starts with the main menu screen, which serves as the foundation of our interface. From this screen, we provided buttons to navigate to the instructions, settings, and high score screens, or to choose to start or quit the game. The “view high score” button brings the user to the high score list, which uses an online server to display the top scores that people have achieved in the game (one of our group members had access to a server, so he was able to store high score table there). Our instructions are displayed in slideshow format; we took screenshots of the game and added helpful notes so that the user could be familiarized with both the gameplay and the game interface.
Settings
The settings screen allows toggling of mouse sensitivity (a wizard of oz technique), but the main function of this interface is the allow the user to enter and save their physical characteristics for the game. Here, they can enter their age, weight, height, and hours of physical activity per week. We used special input boxes (found in Flex) such that the user could type their inputs, but also that would automatically check for out-of-range inputs (i.e. weight over 300). After the user finished entering values and clicked “Apply”, we would take the values that the user entered and run them through condition checks to update the appropriate amount of calories/fat/carbs/protein that the user should consume within one day. For example, if the user weighed less than 130 pounds, we would multiply each of calories/fat/carbs/protein by 0.9 of the default values (which were [2300, 70, 300, 65]. In other words, each of the physical characteristics would go through its own set of condition checks and be assigned a multiplier; in the end, each of the four multipliers would be multiplied with the default array (the multipliers would stack). The resulting array values would then be passed to the flash interface to be used for gameplay.
Gameplay
The gameplay was the bulk of our implementation. We implemented our gameplay screen in Flash and passed variables between Flash and Flex through function calls in order to smoothly transition in and out of the gameplay screen. For instance, we took the nutrient levels calculated from the Settings screen and displayed them in bar graph form in the upper left corner of the gameplay screen (refer to screenshots). In addition the Flash screen had to pass variables such as life, score, upgrade points, food speed, and wave number to the upgrade screen so that the latter screen could work with those variables. For our actual gameplay, we displayed a randomly generated sequence of foods coming in through the top of the screen, and following a set path through the stomach before exiting out of the bottom of the screen. Since we decided to have our implementation support 26 different types of foods, there was a wide representation of foods, but also a large degree of randomness. Each food has its own nutrition facts, which would be displayed on mouse rollover in the top left corner of the screen. The mouse mode (absorb or eliminate) is displayed on the left, and can be easily and quickly toggled by the Ctrl and Shift keys. The food icons disappear when they are clicked (in either mouse mode), but their nutrient values only get added to the wave totals if the mouse mode is set as ‘absorb’.
For our earlier prototypes, we implemented the life subtraction mechanism to happen during gameplay; however, for consistency purposes we later decided to do all life subtraction at the end of a wave. This is because there are two conditions for life loss: the player could either have consumed too much food/nutrients, or to little of a particular nutrient. Since we would not be able to determine the “too little” case until the end of the wave, we decided to do life subtraction only after a wave ended, even if this seemed a little counterintuitive. Nevertheless, when we summed up all the statistics at the end of the wave (displayed in the statistics screen that pops up), we were able to tell the user which nutrients were deficient or overconsumed, thus providing them the reason that they lost life (if any lives were lost). To determine exactly how much life the player should lose, we set ranges (around the target value) for each nutrient such that if the player consumed out of this range, we would subtract one or more life. For example, say the target fat level is 70g per wave, and our range was 20g. That means that if the player consumed 70 +/-20g fat, they would lose no life; otherwise one life would be subtracted for every 20g above or below 70g. One additional implementation detail is that if the player consumed with the target range for every nutrient (calories, fat, carbs, and protein), we would reward the player with an additional 500 bonus points (also upgrade points).
To implement an increasing difficulty of the game, we increased the speed of all foods for each subsequent wave by 20%. In addition, we increased the amount of food that entered the stomach; this design was so the user would have to make faster decisions for later waves, while increasing the accuracy of their clicks. However, each food still took only one click to absorb or one click to eliminate, because we didn’t want the player focusing all his attention on once click.
Upgrading Organs
In order to allot the user with a currency to upgrade the organs with, we had to keep a running tally of two score, one called “Score” and the other called “Upgrade Points” (both are displayed in the upgrade screen). Both would be increased at the same rate (more precisely, whenever a food is absorbed or eliminated), but the Upgrade Points would be subtracted accordingly whenever the user spent points to upgrade an organ. Also, we chose to display the organ information with a “mouse-over” format, to reduce the clutter that the text would cause if they were simply pasted onto the screen.
The organs were upgraded by clicking the “upgrade” button below them. When upgraded, each organ had a particular effect on gameplay; more specifically, the heart replenished health lost from previous waves, the stomach decreased the speeds of all food, and the liver doubled the maximum life. This meant that we had to modify variables passed from Flash and pass them back into Flash when starting the next wave.
Most difficult to implement: Gameplay + Flash/Flex integration
The most difficult aspect of the implementation was coordinating everything correctly between Flash and Flex. We encountered numerous bugs while going through the iterations of our design, and every time we added a new gameplay feature or decided to change an existing feature, we had to reconfigure the variable passing between the two interfaces. While Flash provided a great platform for us implement the moving objects and interactive nature of the gameplay, Flex was more practical for creating the various menus that the user could navigate through; thus, while the two applications were strong in certain areas, their differences meant that some of the functionalities were incompatible with each other.
Implementing the Gameplay in Flash alone was also a difficult task, as we constantly had to change our features from going through design iterations. We had to come up with clever workarounds in Flash to implement some of the features; for example, we especially had a hard time coding the food path and implementing the effect of the mouse clicks. Since this class only provided us with a limited base knowledge of Flash (through one discussion session), we often had to search online for additional help with Flash.
Provide clear and well-referenced screenshots and figures
| The Game starts with the initial screen given the option to change the settings, read the instructions, view the high score or play/Start the game. | 
|
| If the user chooses to change the settings, the user will be able to change the age, weight, hight, number of hours spent on physical activity and mouse sensitivity | 
|
| Once the User clicks on "apply" the confirmation window will be displayed, Letting the user know that they have successfully changed their settings. These settings will affect the users target calories, fats, etc. | 
|
| When the user starts playing the game the user will see the following screen which will show the target calories, fats, carbohydrates and proteins, it will also show the health bar/ number of lives left. The food will go through the stomach wondering in it till it leaves the stomach, absorbed or eliminated. | 
|
| Note here: the mouse is hovering over the juice (mouse couldn't be viewed, because macs don't show mouse when taking a screen shot) but as you can see the word juice appeared on top of that icon letting the user know which food item are they hovering on. also if you look on the nutrition bars on the left you will notice that it has a light brown "shadow", meaning that the user hasn't absorbed this piece of food, but if they do this amount will affect their nutrients | 
|
| This shows that if you hover over another item it will change the "shadow" nutrition effect. | 
|
| Once the user has finished a wave the user won't know what happened with their score and thus we added the result screen which is a transition screen between a wave and the upgrade screen, to hep them understand the scoring mechanism. For example here it tells the user in red color on the right side that they need more calories (-3) and carbohydrates(-1) and hence out of their lives (5) we took out the 3 and the 1, so the new number of lives left are 1= 5-3-1 |
|
| The user might not know why they have been transitioned to this screen, so a simple message telling them that they "..can upgrade organs" will be enough hint to keep them updated with the flow | 
|
| Note here that when the user hovers over an organ, a pop up message will be displayed letting them know what is the functionality of this organ and if chosen to be upgraded, what its effect on the game will be. They can then choose to go to the next wave or quit the game | 
|
| Now we are shifting to the other part of this scenario which is the user dies after a wave. Letting just the user dies or going to submit your score screen without knowing what has just happened frustrated our users. So a message explaining the reason of their "death" or was added to aid their understanding of this transition within the game. | 
|
| The user can submit their scores using this screen, just by adding their initials or typing their name. | 
|
| This screen can be viewed by clicking on "View High Scores" from the initial screen. It will display the top scores in descending order. | 
|
What was left unimplemented
What was left out and why
What was left out and why As far as the general user interface goes, we were able to incorporate most of what we wanted our interface to do into our flash/flex application. More specifically, the main interface functionalities are all present; the things that were left out related more to additional features in our gameplay. In particular, we left the pause functionality, sound effects, and other minor gameplay enhancements to our game. Each of these are described below:
Pausing the game: We actually originally implemented a pause functionality to pause the gameplay screen in the middle of gameplay, but later realized that it cause a few non-deterministic bugs with our flash implementation. We spent a lot of time trying to eliminate these bugs, but eventually just ran out of time. Thus, for the aspect of keeping our game more bug-free, we took out the pausing functionality, because in the end pausing the game was just too small detail that wasn’t worth the time we would have to spend to fix the bugs it caused.
Sound effects: This was another aspect of the game that was present in our earlier designs. We decided to remove sound for our final prototype because it simply made the flash file too big (up to 90MB). Loading such a large file would take too long, especially over a slow internet connection, so we took our the sound files from our game.
Other gameplay enhancements: These were not really things that we left out, but rather features that we didn’t have time to implement. We originally were going to create special effects for the mouse cursor whenever a food was eliminated or absorbed, as well as create screen or animation effects on certain types of foods. Since we felt that these features that did not add that much to the compelling aspect of our gameplay (and also introduced many bugs when we attempted to implement them in our gameplay), we left out these features in our final design.
Any wizard of oz techniques that are required to make it work
As mentioned above, we implemented pretty much every functionality that we chose to include in our interface. The only wizard of oz technique is the variable mouse sensitivity characteristic in our settings screen. Currently, it appears as if the user can increase or decrease the mouse sensitivity by scrolling through values from 1 to 5 (5 being the most sensitive); however, the mouse sensitivity is never actually changed. It was hard for us to find a mechanism in Adobe Flex (the platform we chose to build our game on) to alter the mouse sensitivity, so we decided to keep it as a wizard of oz technique.
