Final Report-Group:Group Ate
From CS 160 Fall 2008
Group Ate's Final Report assignment.
Group Members, contributions
- Jonathan Fong - final presentation PPT; "Target User Group" and "UI Design" (6.1.2) on final report
- Joshua Kwan - final code release; discussion about implementation
- Kevin Lam - general edits on final report, namely problem and solution overview and final UI design
- Jacek Wnuk - general edits on final report, wrote Design Evolution section; image editing support for final release; poster work
- Nathan Yan - general edits, mostly to Design Evolution; presenting oral report
Problem and solution overview (1 paragraph - 2 points)
Growing up, many people's exposure to food is confined to what they experience eating at home or within their local community. As a result, many people are unfamiliar with foreign food culture and etiquette. In addition, today's fast-paced world that emphasizes a "casual" dining atmosphere (fast food, take-out, no sit-down dinners at home) has led to overall unfamiliarity with general food etiquette. Both issues can lead to significant consternation as diners realize they have no idea how to "eat properly" at foreign and/or sit-down restaurants to avoid social embarrassment!
To make up for the lack of education in that regard, we've designed a game that can familiarize people with the behaviors deemed appropriate for formal dining occasions. The game aims to simulate a supervised dining experience where the player controls an avatar in a formal dining setting. The player is coached to behave correctly by an on-screen instructor who voices his concerns about the player's table manners. Additionally, the player must correct his mishaps in order to prevent a faux pas during the meal. The game is controlled using the mouse and is built on the C# .NET platform.
Target user group (1 paragraph - 3 points)
Formal Logic is for casual "Generation Y" users who are interested in learning about dining ettiquite. Specifically, the users are English-literate, of either gender, and have a basic computer-literacy and comfort-level with interacting with computer interfaces.
As we discovered in our Contextual Inquiry, Generation Y users are inherently comfortable with technology. Our intended users currently use computers in a task-oriented manner: word processing, research, communication (email and instant messaging), and entertainment (videos and games). They play simple computer games, like the built-in solitaire in Windows.
The target users learn through clear diagrams and visual instruction. Many use video walkthroughs that can adjust to the user’s learning speed allow the user to follow along. Others have experienced (or strongly prefer) personal instruction from a credible authority (a parent, grandparent, or trained expert).
Tasks (1/2 page - 5 points)
3 representative tasks to test your interface (easy, medium, hard). Remind us why you chose these tasks
These are the same tasks we used for our lo-fi prototype, though the pausing was replaced with Salt & Pepper passing (previously labeled as a Medium task under our Contextual Inquiry and Task Analysis, but downgraded to Easy on account of its easiness and higher level of interestingness than pausing).
Easy: Passing Salt or Bread around the table
Task summary: Every 30 seconds or so (this time depends on the stage the player is at), the player is presented with an arrow containing either a Salt & Pepper icon or a Bread icon, and must pass it using our input mechanism (the mouse).
The salt and pepper passing is mostly used during gameplay to up the difficulty by giving the player many things to think about. The process of actually passing the salt or bread, however, is very simple. Once the arrow with the Salt & Pepper or Bread icon appears, the user must simply click on the arrow within the time allotted. The arrow contains a timer (albeit unwritten in the prototype), and if said time counts goes down to zero, the instructor will become unhappy, and points will be taken off from the player's end score, but the arrow will disappear. If the player clicks it, a passing animation will take place, after which the player can continue with the rest of his challenges.
Medium: Successfully complete meal without distractions
Task summary: The player is presented with a plate of food and must eat it using the affordances provided by our input mechanism (the mouse.) Unlike the Hard version of this task, there are no additional distractions; the goal is simply to wolf down your food.
We intend to present this task in the form of a tutorial stage to get the user accustomed to the input scheme. To eat the food, the user must learn how to conceptually map the mouse buttons to the utensils in his/her avatar's hands. The right click button uses the knife in the right hand; the left click button uses the fork in the left hand. The player is presented with a simple steak. To successfully consume the steak without any errors, the player must repeat the following steps:
- Use the fork to stab the steak (thus holding it in place). (left click)
- Use the knife to cut a piece off the steak. (right click)
- Use the fork to stab the piece of steak (left click)
- Click on the avatar's mouth. (left click)
- Repeat until steak has been entirely consumed.
During our lo-fi prototype evaluation, we discovered that once people understood the input scheme, this was relatively straightforward. But that was the entire problem; people didn't immediately catch on. People tried to click the fork and then the steak, which would result in an animation of the player's avatar stabbing the table. Or, they tried to drag the fork to the steak, which resulted in something similarly perplexing. Thus, in the real game, we will attempt to detect these common mistakes and pop up help bubbles to make it clear to the user what each mouse button does. As of now, however, the prototype does not have these.
Hard: Successfully complete meal while dealing with environmental challenges
The hard task has the same objective as the medium task: the user must consume all the food on their plate. However, the hard task also introduces various obstacles representing what a diner might encounter. Two obstacles we are including in this prototype are:
Posture
During the game, the user's in-game character will begin to develop a poor posture (slouch). The user will need to notice this (if the posture becomes very bad, the "instructor" may pop-up a dialog to tell the user explicitly) and correct the posture.
The control scheme for correcting posture is as follows:
- User mouses over the in-game character's body. The cursor should change from the utensil icon used on the table to a "finger pointing hand" icon that indicates a click is possible.
- The user can click any part of the character's body to fix the posture.
- The instructor will indicate his approval if the player fixes the posture and continue nagging if the player does not.
Eating Pace
Another aspect of good dining etiquette is eating food at a similar pace as the rest of the table. The game interface will feature a "progress bar" for the amount of food that the character has eaten. If the user eats too fast, the instructor will pop-up a dialog to tell the user to slow down. If the user eats too slowly, he will not finish his meal, which will result in a poor end rating.
Overall objective: Keep instructor happy
This is the overarching superobjective reflected by your instructor's feedback area in the upper-right corner. Your performance on other tasks is reflected in this supertask (except for pausing the game, which does not and should not have any other effect on game play) - a poor job in eating food for whatever reason will result in a negative reaction from your instructor.
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.
From the Contextual Inquiry onward, we had a pretty clear view of what we wanted in our project. The majority of the changes made were to how a particular challenge was completed rather than a radical change of the challenge itself. However, over the course of all the prototypes, we have made some rather large changes nonetheless.
Changes: Group Brainstorm to Contextual Inquiry
This is actually where some of our biggest changes (idea-wise) were made. Initially the game was going to fully cover the entire culinary experience of a certain culture, starting with choosing dishes from a recipe book, shopping for ingredients and cooking the food, and then dealing with proper table manners for eating the food. The initial idea was to center the game around running a restaurant of a certain culinary style, to introduce different culinary cultures to users and to also teach proper dining etiquette in different environments, through eating mini-games.
Group Brainstorm Mockups
 |
 |
 |
 |
 |
 |
 |
As it turned out, the initial restaurant manager idea which was produced during the Group Brainstorm turned out to be far too vast in scope, both in terms of allotted time for the project and effective instruction for users. We decided to return to one of our original brainstorm goals - teaching users proper eating manners - and concentrate our efforts on the dining aspect of the restaurant. By the time the Contextual Inquiry rolled around, we had a general idea of the gameplay for the game: the user would be presented with a view of their in-game character and the table with food, and complete various "tasks" that would serve as obstacles to eating and tools for teaching certain etiquette concepts, such as keeping a straight posture or passing condiments around the table.
After feedback from actual prototype testing, we made changes and refinements to the control scheme, but the core gameplay model did not change much after the contextual inquiry.
Contextual Inquiry Mockups
 |
 |
 |
 |
 |
 |
 |
 |
Tasks chosen
This was the first time we introduced this selection of tasks, which would remain with us in some form or another throughout the rest of the project.
Easy
- Choosing a game mode
- Pausing the game
Medium
- Eating Food
- Passing Salt/Pepper
Hard
- Keeping posture up as you eat
- Keeping pacing of eating correct
Changes: Contextual Inquiry to Lo-Fi Prototype
Lo-Fi Prototype Screens
 Paused |
 Slouching challenge |
 Eating too fast challenge |
 Beginning the level |
 Halfway through eating |
Between the Contextual Inquiry and the Lo-Fi Prototype, we made some changes in implementation, and made some more during the Lo-Fi prototype interviews. Here those changes are chronicled:
Changes Made Before the Interview
- Slouching was changed. Instead of a slider interface, we opted to change it to a more intuitive interface in which the player's avatar's shoulders droop and head wobbles down to indicate slouching, which would be fixed by the player clicking and dragging those body parts to their correct configurations. We thought this would help users to keep posture in mind by providing a visual cue for the player's posture status, rather than some abstract slider.
- Originally we planned an intricate eating system where the user would be able to directly manipulate utensils to use them (for example, dragging a knife back and forth to make it "cut" through the food). We dropped this idea in favor of a system of left- and right- mouse clicks to "use" the utensils, which have predetermined actions based on the location of the cursor and the state of the food. We made this change mostly for feasibility reasons; during our low-fi prototype, we had no way to simulate the wide range of possibilities that could occur were the user given freeform control over manipulating the food. In addition, a simple two-button mouse wouldn't be able to fully simulate the range of freedom allowed with utensils without a complicated combination of clicks and holds, which we felt would be too complex for most users and require memorization of the scheme rather than an intuitive design.
- We decided on the placement of the pause button
Changes Made During the Interview
The changes described below were made between experiments. User reactions to these changes are noted where applicable.
- Instructions on using fork and knife: Because our first two interviewees found the application of the fork and knife confusing, we created dialogue boxes with instructions on how to use the utensils. Two boxes were made, one for the left hand and another for the right hand. We noted in the boxes that to use the utensils, the user would have to operate two buttons (or mouse clicks). Based on the user feedback, we found it was most helpful to have the instructions displayed at the beginning of the game or at least in the tutorial.
- Click and drag body parts to fix posture: Initially, we had the user click on the various body parts (i.e. head and arms) to correct the character's posture. However, through the interviews we saw that the users were inclined to drag the body parts as opposed to simply clicking on the parts.
- Changing cursors: The cursor was made to change from a utensil cursor when on the table area, to a "grabby hand" cursor (indicating click+drag ability) when hovering over the character's body, and a neutral pointer (indicating nothing to click) when in other areas. This should serve as an indicator to clue the user in on what can be done with the control scheme.
Changes: Lo-Fi Prototype to Interactive Prototype
The Interactive Prototype was the next evolutionary step in the design of our game. One important decision for the Interactive Prototype was choosing C# .NET rather than creating a flash animation. The decision was based on the familiarity of the group members with C# .NET compared to Flash and the inability to use right clicks as controls in Flash. The general structure of the game remained the same as in the Lo-Fi prototype; however there were also changes.
Storyboards of tasks (annotated screenshots)
Task 1: Passing Salt or Bread
 Figure 1-1: Title Screen |
 Figure 1-2: Game begins |
 Figure 1-3: Player is asked to pass bread to the left |
 Figure 1-4: Player is asked to pass bread to the right |
 Figure 1-5: Player successfully passes the bread |
 Figure 1-6: Player does not pass the bread |
 Figure 1-7: Player is asked to pass bread and salt simultaneously |
Task 2: Eating Food
Figure 2-1: Title Screen |
Figure 2-2: The Game Begins |
 Figure 2-3: Fork is stuck in food |
 Figure 2-4: Knife is used to cut food |
 Figure 2-5: Fork is used to pick up food bit |
 Figure 2-6: Fork is used to bring food to mouth and eat, amount of food has decreased |
 Figure 2-7: The fork/knife cursor the mouse turns into while hovering over food |
Task 3: Eating Food with Complications
Figure 3-1: Title Screen |
Figure 3-2: The game begins |
 Figure 3-3: The player is eating too quickly |
 Figure 3-4: The player continues eating too quickly |
 Figure 3-5: The player stops eating too quickly |
 Figure 3-6: The player is notified he is slouching |
 Figure 3-7: If the player does not stop slouching, he gets a sterner warning |
 Figure 3-8: The player has successfully stopped slouching |
 Figure 3-9: A random scene in which the player must multitask |
Changes Implemented as a Result of Lo-Fi Testing
- The etiquette coach, as represented by the smiley face and speech bubble at the top of the screen, was added to the game to give the user instructions and feedback. The smiley face icon can either be happy, neutral, or unhappy. This provides the player with a way to quickly see how he/she is performing. The reaction time is minimal for the player to glance at the face and recognize the "expression" depicted. The speech bubble provides a means to praise the player when he/she is doing well (positive reinforcement) and guidance on how to improve when the player is performing poorly. Our Contextual Inquiry and Task Analysis interviews showed users trust authority figures and/or "experts", so the instructions, tips, and guidance provided in this area will use that tone (e.g. the "coach" will not be overly-friendly or act as a peer of the user would act).
- The cursor gives specific affordances on what actions are available, depending on the game state and location of the cursor.
- Fork and Knife - used to indicate eating-related options are available
- Hand cursor - used to indicate something is clickable.
- Regular mouse icon - used for all other situations, typically for administrative tasks (menus, setting options), whereas the previous two icons provide in-game affordances. An exception currently is the "pass the X" task in the gameplay. We recognize that the cursor does not give affordance to the fact that the arrow itself should be clicked to complete the task.
- The timer at the bottom-right corner of the interface is a countdown until the level ends due to running out of time. The fact that the timer counts down gives the affordance that gameplay is not open-ended. However, the goal is not to complete the level/tasks in the shortest amount of time, because this represents that the player is "eating too fast". As discussed below, the "Food Remaining" bar (when fully-implemented) gives more specific information to the player about pacing.
Changes: Interactive Prototype to Pilot Usability Study
The top two main concerns in the Heuristic Evaluation were that (a) the game wasn't very effective at teaching good dining etiquette, and (b) the game's controls were somewhat unintuitive and hard to understand immediately. The first concern was valid, and we attempted to encompass more etiquette material by adding a utensil selection component. In general, however, we decided to not focus greatly on making the game more educational and instead put our efforts towards refining the interface for the game we already had, since the purpose of the class/project is not really to make the best game but to design the best interface possible.
Utensil Cursor
As for the unintuitiveness of controls, we did a lot to address this. Initially the game's fork-knife utensil cursor (displayed when hovering over food) has lost some of its confusing nature. In the Lo-Fi prototype, the cursor had been merely an idea, and was just a crossed fork-knife combination on a post-it note. This evolved into the below icon for the interactive prototype. Finally we discovered that the order of the fork and knife was the opposite from the head-on view AS WELL as the actual controls (as in, the fork was on the left in the cursor icon, but it was on the right side in the actual gameplay, and was controlled by a right click). This was initially remedied by flipping the icon. Eventually we flipped it back and settled on a left-click-controls-object-in-left-hand while right-click-controls-object-in-right-hand setup, which works well also for continuity for the utensil-selection screen.
Utensil-Selection
 |
 |
A component of the game we had intended to implement from the start but did not have time to until this stage was a utensil selection stage. This stage takes place after the user has selected a dish and begun a game, but before the player can start eating - the point is for the user to recognize the proper utensils to use for certain dishes. The interface uses a buzzer if the user chooses the incorrect utensil, and if there's a left-hand utensil as well, it goes onto that after having selected the right-hand one already. This actually somewhat addresses problem (a) of our Heuristic Evaluation concerns by introducing more material for the user to keep in mind.
Salads & Pies
 |
 |
Finally, the game has the option of other meals besides steak/potatoes. This also means different control schemes; the salad does not need cutting at all, and the pie does but the cutting is done with the fork (so clicking with the fork first cuts it, then clicking again sticks it on the fork)
Tutorial
 |
 |
Last but not least, a Tutorial section was implemented to introduce the user to the game. The tutorial explains the interface components and control scheme, which will help with any user who is unsure about how the game works. The instructor for the tutorial also talks in the context of the game, explaining the real-life reasons behind various tasks and things to do in the game. The tutorial goes through everything step by step, so the user can understand what he/she needs to do when it comes time for the actual game. It is selectable from the game's main menu and presents the user with an example main game screen in which the tasks are laid out one at a time.
Passing Occurance
The "pass the salt/pepper/bread" events used to happen more often and some students commented on it being unrealistic, so this was changed to occur less frequently.
Changes: Pilot Usability Study to Final Project
Ultimately, the Final Project implemented the items that were seen as problematic in the Pilot Usability Study. Thus the majority of the changes are merely fixes of past issues.
 1. Utensil Choosing corrected |
 2. Urgent Coach alert |
 3. Level Choice |
 4. Next button for tutorial |
1. Utensil Choosing corrected
Strangely enough, our previous prototypes actually had the layout of the utensils slightly incorrect, as we had gone from memory rather than checking again. This was caught by one of the Pilot Usability Study interviewees and the layout was corrected, also removing an extra knife that was not necessary for any of the dishes.
2. Urgent coach alert
Some users in the Pilot Usability Study complained about too many messages going in at once and not knowing which are time-sensitive. Now, urgent, time-sensitive comments from the coach as highlighted in red and stay up longer, solving this issue.
3. Level Choice
Previously our special goal tasks have dealt with separately eating the food and then eating the food with all the distractions, two very different experiences. Originally we had planned out a long game in which each new stage introduces new etiquette-related distractions from eating. By giving players a level choice at the beginning of the prototype, we can test these tasks separately and we can ease in new players.
4. Next button for the tutorial
Many of the interviewees for the Pilot Usability Studies had attention issues in that the tutorial was too slow-paced, and they kept trying to click places to make it go faster. A next button immediately solves this issue. It also grays out when the player needs to do something else (e.g. cut meat) to advance the tutorial.
Final Interface (4 pages + screen shots- reference figures!)
- Describe the final UI design
- Describe the functionality (i.e., what are the operations you can do with it) (5 points)
- Describe the user interface design (i.e., how you use the functionality) (5 points)
- Describe your implementation. What was most difficult to implement and why? (10 points)
- Provide clear and well-referenced screenshots and figures (5 points)
- What was left unimplemented
- What was left out and why (5 points)
- Any wizard of oz techniques that are required to make it work (5 points)
Final UI Design
Functionality
Each of the main functionalities of Formal Logic are described in detail in this section.
 1. Main Menu |
2. Tutorial |
3. Difficulty & Meal Selection |
4. Utensil Selection |
1. Main Menu
When Formal Logic is launched, players are welcomed by a main menu that contains links to a tutorial, the game itself, and a quit option that terminates the game. The tutorial is described in its respective section below. The remaining sections pertain to the game.
2. Tutorial
For beginning players or people who need a refresher course on how to play Formal Logic, a tutorial is offered from the main menu. The self-paced tutorial walks players through each of the steps required to complete a meal with and without distractions. The tutorial includes an explanation of how to use the utensils, how to pass salt & pepper, and how to fix the avatar's posture. All three of those tasks are critical to completing the game.
To proceed from one part of the tutorial to the next, players must either click on the "Next" button or complete the immediate task at hand (i.e. passing the salt). By allowing players to navigate through the tutorial at their own pace, they can take the necessary time to learn how to play the game.
3. Difficulty & Meal Selection
As suggested by the interviewees in our heuristic evaluations, we have implemented three different difficulty levels: easy, medium, and hard. Each difficulty offers different challenges to players. The easy mode is a straight forward application of a simple dining experience free of distractions, whereas the medium difficulty introduces the passing of salt and pepper at the table. Finally, the hard difficulty adds an additional distraction, posture interruptions where the avatar begins to slouch and it is the player's responsibility to fix the poor mannerism.
In addition to selecting the difficulty, players can choose from one of three meals: a salad, steak, or pie. Like the difficulty levels, the meals affect the game play. More specifically, the type of meal that is chosen affects the utensils that are used by the avatar. Giving players this option also creates more variability in the game, thus exposing players to a broader range of dining tools.
4. Utensil Selection
For any given meal, players must choose the appropriate utensils to use. The screen shown is where players must select the avatar's utensils. Only after the right utensils are chosen are players allowed to proceed to the next part of the game: eating the meal.
5. Complete a Meal (with or without distractions)
Formal Logic is aimed at teaching players dining etiquette, so it is only appropriate that the majority of the game play is spent eating a meal, with proper table manners of course. There are several components that make up the dining experience. Each of those parts are described in the following sections.
5.1. Eating |
5.2. Passing Salt & Pepper |
5.3. Fixing Posture |
5.1. Eating
First and foremost, the player's primary objective is to complete a meal. That would involve eating a selected dish, regardless of the difficulty level that is chosen. To complete a meal, players must operate the avatar's hands by using the mouse. The left and right mouse buttons are linked to the left and right hands respectively. By using a combination of left and right clicks (or in some cases only the right button), players can cut, fork, and eat the food on their plates. Each plate consists of several portions and although they can be consumed relatively quickly, doing so will yield a low score. Instead, players are encouraged to eat at a moderate pace. The pace is dictated by the instructor, who informs the player if he or she is eating too quickly or even too slowly.
5.2. Passing Salt & Pepper
A common request at the dining table is to pass the salt and/or pepper. As such, we have added this feature in the medium and hard difficulties. Periodically, players will be asked to pass the salt and/or pepper. An arrow is displayed as in the following figure:
Once the arrow appears, players are given a short amount of time to click on the passing icon before the opportunity passes. Completing the task earns the player more points, whereas failure to comply irritates the instructor and can lower a player's ranking.
5.3. Fixing Posture
Because maintaining your posture is so important at the dining table (after all, who wants to eat with a sloucher?), one of the distractions presented on the hard difficulty is slouching. As the game progresses, the avatar loosens his posture and begins to tilt. When this happens, the player must correct the avatar's posture by clicking on his body. Failure to do this will result in getting scolded by the instructor and receiving a lower ranking at the end of the game. The need to constantly keep an eye on the avatar's posture will hopefully instill in the players the importance of keeping up your posture in a formal setting.
6. Pausing
During the game, players may want to pause the screen to take a break or to attend to a distraction. Taking into consideration these scenarios, we created the "Pause" button. When the pause button is clicked, a menu is displayed giving players an option to resume the current game or to quit the game altogether. One thing that was not implemented, however, was an option to return to the main menu. Instead, the "Quit" button closes the entire game. To return to the main menu, the player simply needs to close the game menu but this is not very intuitive. The main menu is hidden behind the active window.
UI Design
Etiquette Coach
The etiquette coach, as represented by the smiley face and speech bubble at the top of the screen (Figure 4-0CB). The smiley face icon can either be happy, neutral, or unhappy. This provides the player with a way to quickly see how he/she is performing. The reaction time is minimal for the player to glance at the face and recognize the "expression" depicted. The speech bubble provides a means to praise the player when he/she is doing well (positive reinforcement) (Figure 5-1), and guidance on how to improve when the player is performing poorly (Figure 5-2). Our Contextual Inquiry and Task Analysis interviews showed users trust authority figures and/or "experts", so the instructions, tips, and guidance provided in this area will use that tone (e.g. the "coach" will not be overly-friendly or act as a peer of the user would act). Sometimes this means being strict, as shown in Figure 5-3, where the user has consistently been underperforming. Additionally, to draw the user's attention for messages that are urgent (e.g. require action), the coach's speech bubble flashes red (see Figure 5-4).
 Figure 5-1: Coach in a happy mode |
 Figure 5-2: Coach in a neutral mode |
 Figure 5-3: Coach in a sad mode |
Figure 5-4: Coach's speech bubble with an urgent message |
Cursor
The cursor gives specific affordances on what actions are available, depending on the game state and location of the cursor.
- Fork and Knife (Figure 6-1) - used to indicate eating-related options are available
- Hand (Figure 6-2) - used to indicate something is clickable. Also, in future iterations, the animation of the cursor itself will give feedback that a grabbable item has been "grabbed."
- Regular mouse icon (Figure 6-3) - used for all other situations, typically for administrative tasks (menus, setting options), whereas the previous two icons provide in-game affordances. An exception currently is the "pass the X" task in the gameplay.
Figure 6-1: The fork/knife cursor |
 Figure 6-2: The hand cursor |
 Figure 6-3: The regular mouse cursor |
Timer
The timer at the bottom-right corner of the interface is a countdown until the level ends due to running out of time (Figure 4-0F). The fact that the timer counts down gives the affordance that gameplay is not open-ended. However, the goal is not to complete the level/tasks in the shortest amount of time, because this represents that the player is "eating too fast". In the future, if this project were to continue, we see great promise in a "Food Remaining" bar with graphical feedback about pacing, and would put that high on the priority list of things to implement.
Food Remaining Bar
The Food Remaining bar at the bottom of the screen represents how much food is left for the avatar (Figure 4-0G). This gives direct feedback to the player about how much progress has been made. For example, after successfully eating one bite, the Food Remaining bar in Figure 2-4 has decreased (compared to its previous position in Figure 2-5). As implemented, the bar makes larges discrete jumps for every bite of the food consumed; this is a rough implementation and as the interface is further developed and more code written, the bar will decrease in smaller increments.
Controls
The interaction with the interface is through mouse clicks.
- When "eating" the left mouse click represents executing an action with the avatar's left hand and vice versa. This control mode is afforded by the fork and knife cursor shown in (Figure 6-1).
- To manipulate the posture of the avatar, the user omnipotently wields the "hand" to correct the avatar slouching position (Figure 6-2). This is done with the left-click, as this is the natural button for selection tasks (versus the right-click, which has a standard use for bringing-up contextual menus). As discussed below, the intended implementation is for the player to click and drag the avatar. In this prototype, however, posture is correct with a single-click (i.e. dragging is no supported).
- For all other uses, the cursor is a regular mouse pointer (Figure 6-3). The left-click can be used to click on the pause button and navigate menus. By standard and practice, contextual menus are rarely used in simple interfaces/games such as ours; we follow this standard, and so there is minimal possibility for confusion in this regard.
Implementation
The program was designed in Visual C# .NET, initially with the 2005 version and now with the 2008 version. Microsoft's "Visual" family is well known for its role as a fast prototyping tool (Alan Cooper, whom we read about, designed what became Visual Basic for Microsoft almost 20 years ago!) and we embraced it when we were not ready to put in the time to learn Flash. For better or for worse, though, we completed the interactive prototype and decided to stick with the codebase and it does persist now. However, at this point we started running into barriers that we could not overcome with any reasonable amount of language trickery. Visual .NET programs suffer from the lack of fluid animation capabilities that Flash has. As a result, our final product is not particularly attractive, as games go, but it is complete.
Certain features were left out as a result of being unable to fluidly animate certain actions. Namely, the multi-colored food-remaining bar and "slouch recovery". These two are discussed at length in the section below.
The project itself consists of a number of forms serving various functions: greeting screen, level selection screen, utensil selection screen (the pre-game), main game screen, winning screen, pause screen, and tutorial screen (which is a fork of the main game screen at a point in the past; the codebases were not kept in sync to avoid massive overhead.) All the graphics are implemented using simple picture boxes loaded up with PNG files with transparent backgrounds. The flow of the game is implemented using timers that cause events to happen, and make certain screen elements visible, such as the arrows that show up when you have to pass something across the table. Many of the forms pass data to another form via custom constructors that accept variables. For example, when you start the game, you choose your level and difficulty in one form. That data is passed on to the utensil selection screen so it knows what combination of utensils is the appropriate one for your meal. After you get it right, it passes the meal and difficulty information on to the main game form.
A couple of tricks are used to minimize the number of graphics that must be loaded into the program. For example, your avatar, so-called "The Eater", is composed of a head and a body graphic that are directly adjacent to each other. This way, the head can be doing something while the body is doing any number of things. Unfortunately, this resulted in a minor gradient mismatch, so the split line is somewhat obvious. We chose to maintain this for the prototype, however, as it would make it easier to fix any potential graphical errors related to the lining up of the head and body graphics.
Most of the graphics were designed by Jacek in Adobe Photoshop.
Unimplemented Features
Food Remaining Bar: One of the features that we had hoped to implement in our last iteration was a bar that indicates the desired pace of eating. Shown below, this green bar would illustrate to the player how much of the meal he or she should have completed given the current time remaining. A vertical line along the bar would indicate your progress with the meal. The idea is that it is preferable for that line to remain within the green bar for a good score. Eating faster or slower than this pace will result in a lower score. This feature was not implemented due to time constraints and because creating moving animations in C# presents a big challenge.
Fine-Grained Slouch Recovery: Our initial lofty idea for slouching involved The Eater's head slowly going out of posture, until a point where the instructor would notice. The desired affordance to fix this would have been the ability to readjust specific body parts - head and arms mostly - by dragging them around with the mouse. Unfortunately, rotating and dragging around picture widgets in .NET is fraught with pitfalls and missing features that are greatly desired to make this sort of thing happen.
Note that our current design does not require any wizard of oz techniques to work. Each of the functionalities described in section 6.1.1 work to the best of our knowledge.
Project Files
The Final Project .zip file can be found here. To play the game, unzip the file using WinZip or a similar program, and double-click FormalLogic/bin/debug/FormalLogic.exe to run it.
Requirements
Windows 2000 or higher, Microsoft .NET framework.
