FinalPrototype-Group:Group 4
From CS 160 Fall 2008
Contents
|
Our Team
- Witton Chou - "What Goes There" prototype improvement, poster design
- Kai Lin Huang - poster design, report
- Volodymyr Kalish - report
- Karen Tran - report, presentation slides
- Trinh Vo - "Datris" and "Bug-A-Boo" prototype improvement
Problem and Solution Overview
The primary problem is that the programming learning curve is fairly steep for those who are just beginning to learn Computer Science. It is hard for newbies and children to learn concepts without going through the pain of learning syntax and compilation. Our solution is to make learning the concepts of beginning programming easy and fun, by abstracting away all the hard-to-grasp-at-the-beginning concepts and developing a fun yet intuitive interface conducive to understand the crucial elementary building blocks of Computer Science.
Target User Group
The purpose of this game is to serve as an entry-point and a practice platform for people who would like to get a taste of what programming is. Therefore, the range of users targeted for this game is very broad. Anyone who is interested in Computer Science, in programming specifically, should pick up a copy of ProGaming and start playing/learning.
Tasks
Easy Task: Datris
- Objective: The game aims to familiarize the users with the concept of data types. Datris introduces some of the most common data types used across programming languages: String, int (integer), double (decimal), and Boolean (true/false).
- Goal: Each falling brick falls into one of the four data types introduced above. As each brick appears, the user’s task is to use the keyboard to direct the brick into the correct data type bucket.
- How to Play:
- Once the Datris Task is picked, the User Interface for the game is displayed.
- The game first starts out with a tutorial (of three pages): the first page stating the goal of the game, and giving examples for each data type; the second page describes the mechanics of the game, of how the game is played. The third page clarifies how to change orientation of the Boolean type brick. At any point, there are “back” and “next” buttons at the bottom of the screen to navigate through the tutorial pages. Clicking on “Ready to Play” button at the bottom of the screen will start the game.
- Player can use left, right and down arrow keys on the keyboard to move the falling bricks, which are representatives of data types.
- The task is to drop the brick into the appropriate data-type bucket at the bottom of the gaming area. There are five buckets: String, int , double, Boolean. The description of each bucket is self-explanatory. If a falling brick contains a String, the brick should be directed to fall into the String bucket, etc.
- For Boolean type, user will drop the brick with expression evaluated "True" in a horizontal orientation, with expression evaluated "False" in a vertical orientation. The up arrow key is used to change the brick's orientation.
- For each brick sorted correctly, a green checkmark appears, followed by ‘ding’ sound, indicating that the correctness of the sorting. On the other hand, a red cross is displayed instead, coupled by a “buzz” sound to indicate the incorrectness of the sorting.
- For each brick sorted correctly, 5 points are earned. On the right hand side, the current score of the game is shown at the top corner in the score panel.
- For each ten points earned, the level is increased and the rate at which a brick is falling also increases. For each wrongly sorted brick, a Health Point (HP) is lost; the user can lose at most 4 HPs before the game is over.
- For every 3 consecutive correctly placed bricks, the user will receive 5 bonus points.
- There is no winning score because a highest score record list is kept for the game.
Medium Task: What Goes There?
- Objective: The objective of “What goes here?” task is to familiarize the users with looping/if/while/recursive functions and the coding style and syntax of the Java programming language.
- Goal: The user is given a partially completed snippet of code. The task is to fill in the missing pieces to so that the code produces an output that matches the desired output.
- How to Play:
- Once the “What Goes There?” Task is picked, the welcome screen of the game is displayed.
- Then the tutorial (of three slides) will be displayed. It states the goal of the game, introduction to the game interface and looping statements.
- The first problem is presented with only two missing pieces of code, with the desired output displayed in the “What We Want” window. The user can try as many inputs in the blanks as he/she wants within the time allowed.
- As the player moves higher and higher up the levels, the complexity of the code snippets increases as well as the number of the missing pieces.
- Upon successful completion of the four parts of this stage, the remaining time is converted into bonus points. The point of this strategy is to encourage the players to practice more and be able to finish the task as fast as he can to earn maximum points available.
Difficult Task: Bugaboo
- Objective: The objective of this game is to teach users to identify bugs by just looking at the line of code.
- Goal: The goal of the game is to hunt and shot down buggy hot air balloons.
- How to Play:
- Once the Bugaboo Task is picked, the welcome screen of the game is displayed.
- The game starts with three pages of tutorial stating the goal, concepts and controls of the game. The user can skip the tutorial by clicking on "Ready To Play" button.
- When Bugaboo is started, the task is to maneuver the jet with the arrow keys and to shoot balloons with incorrect statements (bugs).
- The jet can fire at a buggy balloon by pressing the space bar.
- The user will lose health points by crashing into any hot-air balloon.
- The balloons will move randomly around within the bounds of the playing screen. The balloons will also avoid running into each other as a result of such algorithm.
- For each buggy balloon shot down, a "ding" sound is played with a message that tells what's the correction should be, and 5 points are earned.
- For each non-buggy balloon shot down, a buzz sound is played with a message “NO BUG!”, and a Health Point (HP) is lost.
- The player has a maximum of 4 HPs (Health Points) before the game is over.
- The user will earn 5 bonus points for shooting 3 buggy balloons in a row.
- Because the user will be playing for the highest score, so the user can continue playing the game until game overs. This game is open ended.
- If the user breaks a record or earning a score that is higher than any one on the "Hall of Fame" list, the user will be asked to enter name so that his/her name will be shown on the list.
Design Evolution
- 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
The Earliest User Interfaces of ProGaming
Overall, the three representative tasks evolved progressively from purely educational exercises to more fun-approached serious games. Over the course of undergoing several prototype iterations, the tasks have been significantly modified. In the contextual analysis, our easy task aimed to introduce users to the basic usage of Eclipse (saving file, running it, and viewing the results). The second task included working with different data types with corresponding variables and outputting them by using simple for-loops. Finally, hard tasks included nested for loops along with recursive methods calls.
At this point, all three tasks share the same interface, which is the mimicking of a simpler Eclipse Integrated Development Environment (IDE). The interface was designed to have the code section to be on the upper left corner and occupies the biggest portion of the interface, and the output to be shown on the bottom to keep everything on one screen so that players could compare the code and the output at the same time. On the right hand side, we have drop-down menus of different functions , which can dragged and dropped into the main coding area. The aim here was to lower the intimidation of programming by moving away from actual coding and strictly using graphical interface, where the users can simple drag-and-drop.
However, the testing of the interface that we conducted with the interviewees revealed while the code generation task was simplified through our functions list and form fields, users still seemed confused. Moreover, this approach is only appropriate for beginners who want to have a quick understanding of basic programming concepts because it doesn't require the users to know the syntax, or to understand what's under the hood. With this approach, the users won't be able to compile a file themselves because everything is automatically done for them.
Following the feedback that we got from conducting interviews for each prototype iteration, we kept narrowing and redefining our task more specifically. From contextual analysis, we realized that it is much more desirable to present programming concepts rather than programming itself. Therefore, our three tasks were revised to be called Datris, What Goes There?, and Bugaboo. The evolutions of the three tasks from low-fidelity to final prototype are discussed separately below.
The Evolution of Main Menu
Improvement on single player game selection menu.
 Interactive prototype - Single player game selection menu |
 Final prototype - Aesthetic improvement and game descriptions added. |
The Evolution of DATRIS
Easy Task
In contextual inquiry assignment, the task was designed for user to accustom to the Eclipse-like interface by dragging and dropping programming functions' windows. In low-fidelity prototype, the first (easy) task is changed entirely from that of contextual analysis to familiarize the users with the concept of data types. Data types are essential to many computer programming languages. Without them, it becomes very difficult to maintain information within a computer program. Since the main principle behind computer programming is to take information, process it, and deliver the information in a different form to the user, data types obviously play a large part in determining how this is achieved. Datris introduces some of the most common data types used across programming languages: String, int (integer), double (decimal), and Boolean (true/false).
Datris proves to be a success and a big step forward from our context inquiry design. It was quick to introduce the concept of data types to the user and it allows the users to learn the differences between the data types in a very engaging approach. The only mentionable problem here was that we did not have good, obvious indicators to show whether the user made the right decision about where to drop objects into.
Therefore, we added the tutorial to introduce data types and game control operations. To make the game more exciting and interactive, we added a "ding" sound and a green check mark for correct move and a buzzer sound and a red cross for wrong brick placement. This feature was implemented in the final prototype. In addition, we decided to give users some incentive to get more correct answers by awarding bonus points for every 3 consecutive correct answers. It encourages users to get as many correct answers as possible. These features have been proved to be successful as the interviews went very smoothly for this task. Help document has also been rewritten such that it can serve as a quick reference for users while playing the game. Furthermore, as we have taken a suggestion about the Boolean type should be of one bucket in the game because True/False are not a data type. Therefore, the True/False buckets are combined into one "Boolean" type bucket. The user will need to identify whether the expressions are evaluated true or false; if the expression is false, the orientation of that falling brick needs to be changed to vertical, and a true expression should be dropped into the bucket in horizontal orientation. Up arrow key is used to change falling brick's orientation as to follow the convention of the Tetris game.
Changes since Interactive Prototype:
- In tutorial, "Ready To Play" button's color is changed to be very distinct from other buttons.
- In the gaming interface, "Replay" button is renamed to "New Game", and its color has been changed to red to signify it will affect the current game play.
- A few lines that describe shortcut keys are added under the main game play area to help user to play more effectively.
- Revised Help document such that it is more concise.
- Redesign help window such that it stands out more from the background.
- Counting down from 3 after the user clicks on "New Game" button. This is to avoid the long distance mouse moving from "New Game" button to "Start" button.
- "Boolean" bucket will take all Boolean expression data bricks.
- Rotatable Boolean data type brick. The user only earns points when change the data brick evaluated Boolean True to horizontal orientation and Boolean False to vertical orientation,
- Green check mark appears as a feedback to tell users that they drop the brick correctly. Red cross mark appears for a wrong answer.
- "Ding" sound is played for correct answer; buzz sound is played for incorrect answer.
- A sound on/off button is added next to the game play area.
- User earns 5 bonus points if he/she drops 3 data bricks consecutively to the corresponding buckets.
- "Hall of fame" (highest score list) is added. The game becomes an open-ended game as users will compete to earn as high score as possible.
Evolution of DATRIS
 Low-fi prototype - Interface Design. |
 Low-fi prototype - Interface used during conducting interviews. |
 |
 3. Interactive Prototype - Interface Design. |
 4. Interactive Prototype - Shows falling brick that the player has to sort into the correct bucket. |
 5. Interactive Prototype - the player can pause the game and get "HELP" on Datris. |
|
 Tutorial added |
 Bonus points awarded; Visual and audio indicators added |
 Highest Score List Added |
The Evolution of WHAT GOES THERE?
Medium Task
Our second (medium) task, called Coding (later renamed to “What Goes There?”), retained our initial intend of teaching coding to programming beginners. In low-fidelity prototype, we inherited the contextual inquiry’s interface for the task and introduce coding through the loops and print statements. The main problem we found here was that there are too many programming paradigms to account for if we aim to teach general programming concepts without focusing on a particular language. Different languages are built differently and are, hence, used differently. As a solution, we chose Java programming language. Java is one of the most popular languages. It is clean and the programmer does not need to manage memory, making it a great introductory language that is representative of the style of many other popular languages.
Moreover, from our low-fi prototype interviews, we realized that the task created a lot of confusion for the users because it was more advanced than we thought. We found that having the player put together several functions using the graphical interface is still a higher level task. The user has to learn too many concepts at once: what a loop is, what an initial value is, what a step/increment is, what an end condition is, and that other functions can be performed inside the loop. It took too long for the users to even grasp the basic understanding of their task. It overwhelmed absolute beginners by presenting them more materials than needed. Therefore, in the interactive prototype, we redefined the goal of the task: to expose users to the coding style and syntax of Java; and we wanted to do this in a way that would not intimidate the users by showing too many technical details.
As a result, we completely reworked the Coding task to what’s called “What Goes There?” Rather than overwhelming beginners, a better approach to make the game less intimidating is to provide the users most of the code and allow them to fill in the crucial pieces to accomplish the task. We revised the task with the intention of avoiding making the users start from scratch.
In this user interface, as the user fills in each blank, he gets “feedback” immediately because the output window displays the result of the code in real time. As a result, by comparing this result side-by-side the expected result in the “What We Want” window right next to it, any mistake is instantly recognized and fixed. The text input boxes also have regular expression restrictions, which prevents the player from inputting outrageous inputs that could potentially break the game. By allowing real time updates as opposed to having to compile and run the code on button clicks, this task better helps the player associate their changes to the input with the output of the code, further lowering the learning curve presented by raw programming.
One more note to add to the possible effects of this task is that the bonus points earned as a result of left-over time proves to be an effective incentive during the experiment. One of the aims of this game is to encourage the players to practice as much as possible, because that is the only way to improve one’s programming skill. The more the players practice, the faster each code snippet is completed, and the more points the players will get.
Design Change since Interactive Prototype
- "Ready To Play" dialog, "Not Yet" option is renamed to "Ready To Play" to avoid confusion.
- Mouse cursor automatically moves to the text box such that the user doesn't need to move their move across half of the screen
- "New Game", "Pause" and "Help" function buttons added to be consistent to our design
- When the game is paused, the gaming areas will be covered so that the user cannot cheat.
- Green check mark and the red cross mark are moved to be as a background of the user generated output to reduce confusion and make status updates to the validity of the code more easily recognizable.
- More variety of questions were added.
- If the user wins the game, he/she will earn bonus points based on the leftover time that he/she did not use.
Evolution of WHAT GOES THERE?
 The player is dragging the loops box into the main function window. |
 After filling the blanks with correct input, the desired output is shown and the player complete this task. |
|
 1. Low-fi prototype - Interface Design - Graphical. |
 2. Low-fi prototype - Interface used during conducting interviews. |
|
 3. Interactive Prototype - Interface Design. |
 4. Interactive Prototype - When the user inputs values in the appropriate fields, the output dynamically updates. |
|
 5. Pilot Usability Study - Interface Design |
 6. Pilot Usability Study - Tutorial Pages added. |
 7. Pilot Usability Study - Interface Improved for visibility |
 8. Pilot Usability Study - Interface Improved for visibility |
 9. Pilot Usability Study - If all the blanks have been filled out correctly before timer expires, the game is won with the remaining time converted into bonus points. |
The Evolution of BUGABOO
Hard Task
Finally, our third (hard) task is revised to be known as Bugaboo, whose objective is to introduce debugging. Debugging is an essential skill that every programmer must possess. It is something that every programmer should learn as early as possible in their programming path to practice writing robust, concise code. This task was changed entirely from context to user interface. In the very beginning, we had other ideas until we were creating the low-fidelity prototype and came up with the idea of teaching user to debug codes. Hence, we made this "Bugaboo" game on paper, and provided three separate coding functions that contained incorrect statements, or bugs. We also indicated number of bugs. However, we got negative feedback from almost all interviewees because they have no idea how the codes work in the first place and there would be no output for them to look at.
Before we started implementing the interactive prototype, we thought through what we could improve such that the debugging process becomes interesting. In the low-fidelity prototype, the user was presented a long block of actual code segment and would try to fix it until the edited code produced the desired output. However, we had found that this method of “hunting” for bug was not effective, because it has gone too far and advanced for our target users, and the players were confused as to the cause of bugs. It daunted the users when they are just presented a big piece of code and told to fix it without any help, as they did not know where to start.
Therefore, Bugaboo was completely revised in our interactive prototype phase. We realized that the actual coding interface did not provide the fun and gaming atmosphere, so we revised the task to a shooting game to visualize the concept of "hunting for bugs". Each bug was isolated and simplified to that of a single line statement. The players’ task is to identify and shoot the buggy statements as they appear randomly on the game play screen. This approach added an entertaining and exciting element to the task as the concept of debugging is abstracted away.
In our pilot usability study, we took yet another step forward and completely improved the interface of Bugaboo by implementing an interface of a jet firing buggy hot-air balloons game, that is, a bunch of balloons floating with incorrect programming statements. We found that this approach provides a better visual display than that of the shooting idea, and a colorful and active interface always attract players better. However, we noticed another problem, that users tend to think they should shoot at every single balloon that appears. This defeated our initial intention of teaching and practicing user's debugging skills. Therefore, we also added tutorial, audio feedback (buzz sound for firing at non-buggy balloons and "Ding" sound for correct firing) during this phrase.
The changes from interactive prototype to final version:
- In tutorial, "Ready To Play" button's color is changed to be very distinct from other buttons.
- In the gaming interface, "Replay" button is renamed to "New Game", and its color has been changed to red to signify it will affect the current game play.
- A few lines that describe shortcut keys are added under the main game play area to help user to play more effectively.
- Revised Help document such that it is more concise.
- Redesign help window such that it stands out more from the background.
- Counting down from 3 after the user clicks on "New Game" button. This is to avoid the long distance mouse moving from "New Game" button to "Start" button.
- White glow around each code statement above the balloon to help user to see the statement more clearly.
- When the game is paused, the gaming areas will be covered so that the user cannot cheat.
- If the user fires at the buggy balloon, the message of the balloon changes from "BUG!" to the correction of that bug. This will provide an accurate feedback for users to learn debugging.
- "Ding" sound is played for correct answer; buzz sound is played for incorrect answer.
- A sound on/off button is added next to the game play area.
- User earns 5 bonus points if he/she shoots at 3 buggy balloons consecutively.
- "Hall of fame" (highest score list) is added. The game becomes an open-ended game as users will compete to earn as high score as possible.
Low-fi prototype - Interface Design - Graphical. |
 Low-fi prototype - Interface used during conducting interviews. |
|
 Interactive Prototype - Interface Design. Shooting Bugs Game |
 Interactive Prototype - The expression has a bug and player shot it - correct. |
 Interactive Prototype - The expression does not have a bug and player shot it - incorrect. |
 Interactive Prototype - the player can pause the game and get "HELP" |
|
 Pilot Usability Study - Tutorial Pages added |
 Pilot Usability Study - Visual & Audio Indicators to provide feedback when firing balloons |
 Final Prototype Count down added after clicking "New Game" button |
 Final Prototype Message of correction for the bug replaced the "BUG!" message |
 Final Prototype "Hall of Fame" --Highest score list added for replay value |
- Explain which evaluation technique was most valuable to your prototype's usability and why.
Although each and every prototype iteration helped us improve the user interface of our game significantly, the most valuable and useful technique for our group was the low-fidelity prototype evaluation. As described in Design Evolution of our representative tasks above, low-fidelity prototype helped us define our three tasks definitely. It helped us identify our most important concepts. During contextual analysis, the formation of our tasks were still very vague and did not quite convey the true intention of our proposed solution. But low-fi prototype allowed us to recognize the improvements that we should be making, and in which way we should be making those changes. That is, in our opinion, the most important feedbacks we have gathered. Low-fi prototyping helped us find the concrete bases of our game design. The later prototype iterations helped refine and built on top of the result of low-fi prototype.
Final Interface
Describe the final UI design
Functionality
The user can do the following operations:
- Basic operations
- Go through the tutorials by clicking on "Previous" or "Next" Button
- Skip the tutorials by clicking on "Ready to Start" and start playing the game
- Pause/restart the game during a game or after the game is over
- Take a break from playing or start another gaming session
- View the help document in the middle of the game
- Go back to the main menu by clicking on "Back to Main Menu" button on every screen
- Learn:
- View the tutorials as a way of learning programming concepts and learning how to play the game.
- Datris: The user can learn some common data types from the tutorial.
- What Goes There: The user can learn the idea of for/while loop, if/then statements from the tutorial.
- Bug-A-Boo: The user can learn what "bug" means from the tutorial and review data types from the help document.
- The user will receive feedback from the games such that they know if they have made the right move. From the feedback, the user will learn correct syntax, identify data type, evaluate Boolean expressions, and looping/if/then statement usages.
- Improve specific skills by replaying the games and improving the scores
- View the tutorials as a way of learning programming concepts and learning how to play the game.
- Enjoy:
- Progress from level to level
- Compete with others and the user him/herself for higher scores over time
- For taking a break from studying or working and have fun
The User Interface Design
Main Menu
- Single Player
- Displays the Game Selection Menu
- Multiplayer
- The same games as in Single Player mode are offered here with the difference of allowing the player to compete with other users in the network. The progress of each participants are displayed in the form of progress bars on the player's personal screen.
Game Selection Menu
- Level
- Displays the programming games separated by levels. Currently only level 1 with three small games has been implemented.
- Games Selection Menu
- Displays the small games in the current level. In level 1, "What Goes There?", "Datris", "Bug-A-Boo" are available to be selected.
Datris
- Objective: The game aims to familiarize the users with the concept of data types. Data types are essential to any computer programming language. Without them, it becomes very difficult to maintain information within a computer program. Since the main principle behind computer programming is to take information, process it, and deliver the information in a different form to the user, data types obviously play a large part in determining how this is achieved. Datris introduces some of the most common data types used across programming languages: String, int (integer), double (decimal), and Boolean (true/false).
- User Interface:
- Player will be introduced to String, boolean, integer and double variables in the tutorials. The tutorials also instructs players to use the left and right arrow keys to move the falling block, the up arrow key to rotate boolean type brick and the down arrow key to drop the brick to the desired bucket. Then the player can start the game whenever he/she is ready by pressing "Ready to Play" button on the bottom of the tutorial screen. However the game won't start until the users click the "START" button.
- We also added instructions on how to operate the game on the bottom of the play area.
- If the data type brick was dropped into a correct bucket, then the score increases by 5; a green check mark pops up, and dinging sound will be played if the sound is turned on.
- If the data type brick was dropped into the wrong bucket then the user loses one heart; a red cross pops up, and the a buzz sound will be played if the sound is turned on.
- The block falls down faster as level goes up.
- To pause the game, the users can either press P or click on the "PAUSE" button.
- Since the users are also competing for high scores, they will be rewarded a 5 point bonus for getting 3 right answers in a row.
- Help graphics interface are changed to be more salient, and its content is concisely revised as much as possible to quickly refresh the concepts.
- Once the users run out of hearts, they will have a chance to submit their name to see their ranks on the score list. They can also skip this to start a new game by clicking on the "New Game" button.
- After the "New Game" button is clicked, a count down will start from 3 to provide the users 3 seconds to get ready for a new game.
What Goes There?
- Objective: The objective of “What goes here?” task is to familiarize the users with the coding style and syntax of the Java programming language. The player is given a limited time to complete the code snippet. At the end of the task when all the blanks have been filled out correctly, the remaining time gets converted to bonus points in addition to points rewarded for getting the right answers. If all the tasks are completed in the given time, the game is won; otherwise, the player loses.
- User Interface: The game starts out with the user being presented a brief tutorial. The tutorial highlights the goal of the game. In addition to that a step-by-step example of what happens in case of entering everything correctly and making a mistake is demonstrated. At any point of the tutorial the user has freedom to go back or start the game right away, skipping the tutorial. When the game finally starts, the user is reminded of the objective one more time inside the "Code" text box and asked whether he/she is ready to play (The "Output" and "What We Want" text boxes contain a brief explanation of their purpose as well). During any point of time in game, the player has an option to go back to the "Main Menu", "Single Player" menu (with a list of available games). The game can be paused, or display help (the tutorial) upon player's request or a new game can be started at any time. Once the game starts the counter counts down the remaining time. The player will be shown an almost complete snippet of code with blanks, which will be filled in through user input with a text field. Upon fixing every snippet of code, points are awarded and the next snippet is shown. After a certain number of the problems are fixed, the player moves on to the next level.
- The more detailed behavior of this interface goes as follows:
- Text input boxes are placed where code is missing from the code snippet.
- Text input boxes are restricted to characters that are relevant to the solution.
- Length of text input boxes hint the player to what the solution's length should be.
- Current output of the code is generated in the bottom left dynamically updating text box.
- The desired output from the code is placed in the bottom right text box.
- Buttons for pausing the game, help screens, and starting a new game are located to right, under the game name.
- Pausing the game will temporarily hide all text boxes relevant to gameplay to prevent cheating.
- Code correctness of the current problem is displayed through icons behind the current output.
- Current score and time remaining for the stage are displayed to the right, under the buttons.
- Prompts at the end of the stage tell the user whether they have won or lost and provide buttons for playing again or returning to the menu.
Bug-a-boo
- Objective: The objective of this game is to teach users to identify bugs by just looking at the line of code. It was designed in the spirit: "It is better to learn on someone else's mistakes than make your own", so the most common bugs a lot of beginners make will be introduced in thins game.
- User Interface: In this game the user will have to visually "hunt" for the buggy lines of code.
- We made a lot of modifications to this game since the first interactive prototype. In this new version, the users no longer use the mouse device to shoot at blue circles with codes. They must use the arrow keys to move the jet plane around and press space to shoot at hot air balloons with buggy codes on top.
- Before the game is started, the user will be instructed by tutorials. The user can skip the tutorials at anytime by clicking on the "Ready to Play" button. However the game won't start until the users are ready and click on the "START" button.
- On the bottom of the play area, there are also basic instructions to remind users how to operate the game.
- To pause the game, the users can either press P or click on the "PAUSE" button. The play area will be cleared to keep the users from cheating.
- If the user shoots at a buggy balloon, the text on top of that balloon will say what the bug is (e.g. missing: ;) and its color turns yellow, and a ding sound is played of the sound is turned on, and the user gets 5 points more.
- If the user shoots at a bug-free balloon, the text on top of the balloon says "NO BUG" and its color turns green, and a buzz sound is played if the sound is turned on, and the user looses one heart.
- The help graphics interface are also changed to be more salient and its content is also concisely revised as much as possible.
- Since the users are also competing for high scores, we also provide 5pt incentive bonus for getting 3 right answers in a row
- Once the users run out of hearts, they will have a chance to submit their name to see their rank on the score list or they can skip this and play a new game. After clicking the "New Game" button, a countdown starts from 3 to provide the users 3 seconds to get ready for the new game.
Implementation
- We used Flash CS3 with AS3 to implement the whole game.
- We weren't familiar with Flash CS3 and AS3, so we had to familiarize ourselves with the Flash CS3 user interface and self-teach AS3 at the same time. AS3 is not really a scripting language; it is like a whole new complicated programming language with OOP. This learning process was time consuming and frustrating because we didn't have much time and still didn't know how and where to start to implement our games yet.
- The development of the game began with the design of the menu interfaces. However, we wanted to work on the games in parallel so Datris and Bug-A-Boo were created in separate files. The major problem we found is with the difficulty of combining flash files. We initially tried to just copy the library and scenes in but that didn't work. We then tried to use actionscript loaders to load the .swf files of the two externally built stages (Datris & Bug-A-Boo). Here we found that flash has a problem with unloading external .swf files that have event listeners. Our current implementation is hackish and hides the external stages when we navigate out to the menus.
- Datris:
- We started to implement the 'Datris' first and it was the most difficult game to implement and time consuming. We had never implemented video games before, and we used the new Flash CS3 environment to build the game, so we didn't know how to start and what kind of data structures we should apply to make this game working. There are a lot of questions we encountered during the implementation such as "How do we dynamically generate questions? How do we classify questions in AS3?" "How do we compare the data type of the brick with the bucket types?"
- After spending a lot time to brainstorm, we had come up with a way to generate questions by making 5 arrays to store String, int, double, true and false questions. To dynamically generate questions in real time, we simply used the AS3 built-in random fuctions to randomly pick a question out of one these array and used another variable to tell which array we randomly picked.
- The next harder problem was how we would compare the brick type with bucket types to see if the brick was dropped into the right one or not. We were stuck here because we thought we would have to use Polymorphism to solve this problem. However, we came up with a clever solution is to check the position of the brick and the type of the generated question. For example, if the brick gets dropped in the first column and its question type is String then it's a right answer, otherwise it's wrong answer.
- Once these questions are solved, everything became easy.
- What Goes There?:
- Originally, the design of this stage involved dynamically loading questions (code snippets) from external files. However, we found problems in being able to position the text boxes correctly over the areas of missing code. The current implementation still loads the code from external text files, but the positioning of the text input boxes was done manually through the Flash IDE.
- We didn't know how to dynamically insert and evaluate java programs through flash. The implementation used here involves hardcoding the functions that take the user inputted text and running it through actionscript functions. Since we have an exact output that is desired, we hardcoded the evaluation of the text inputs as well so that when the correct answer(s) are entered into the corresponding boxes, we go to the frame of the next question after a brief delay.
- BugaBoo:
- We used the same technique as Datris to generate questions. However, we faced with another problem which was the hit-area of the hot air balloons. We first used the built-in hitTestObject method to check for collision between bullets and balloons, but this method used the width of text box, which is much wider than the balloon's width, as the hit-area's width, so balloons collided with bullets without even touching each other. Therefore, we decided to rewrite the collision detection function and this process was time-consuming because we had to carefully calulate the hit-area to make the collision more realistic.
- After we finished with writing collision detecting method, we then encounter even more frustrating problem which balloons overlapped one another and their codes were not readable. We had to write a piece of code to somehow make those balloons move away from one another, and this process was harder than expected. This piece of code initially messed up the movements of the balloons and made them move out of bounds and disappeared once they touched one another, and the game crashed. After revising and revising plus brainstorming and brainstroming, we finally managed to make them working.
Screenshots And Figures
Main Menu
 1. The first screen of the game |
2. The game/task selection menu |
Easy Task: Datris
Note: The following screen shots were taken with Datris flash file alone; "Return to Main Menu" button will be shown at the bottom of each screen when opening this game from the main flash file.
 1. The initial Datris screen displayed when DATRIS TASK is selected. |
 2. First Datris Tutorial Page. |
 3. Second Datris Tutorial Page. |
4. Third Datris Tutorial Page. |
 5. When a brick is sorted in the correct bucket, a green checkmark appears, coupled with a 'ding' sound. |
 6. When a brick is sorted in the incorrect bucket, a red cross appears, coupled with a 'buzz' sound. |
 7. A rotatable boolean brick is dropping |
8. After getting 3 correct placement of the dropping bricks, 5 bonus points are awarded. |
 9. If the user set a record that is higher than the lowest score on the record board, the user is asked to enter the name. |
10. Hall of fame with highest scores and names |
 11. The game is lost when the player loses all four Health Points. |
Medium Task: What Goes There
1. The initial What Goes There? screen. |
 2. First What Goes There? Tutorial Page. |
 3. Second What Goes There? Tutorial Page. |
 4. Third What Goes There? Tutorial Page. |
 5. When tutorial is complete, player is asked if s/he is ready to play. |
6. If all the blanks are filled in correctly, a green checkmark appears at the Output window. |
7. If the blanks have not been filled in correctly, a red cross appears at the Output window. |
 8. If the player could not fill in the blanks correctly within the time limit, the game is lost. |
 9. If all the blanks have been filled out correctly before timer expires, the game is won with the remaining time converted into bonus points. |
Difficult Task: Bug-A-Boo
Note: The following screen shots were taken with Bug-A-Boo flash file alone; "Return to Main Menu" button will be shown at the bottom of each screen when opening this game from the main flash file.
 1. The welcoming screen of the Bugaboo game is displayed when the game is selected. |
2. First page of tutorial that describes the goal of the game |
 3. A definition of bug, and the expected display for shooting at buggy and non-buggy balloons. |
 4. Third tutorial page that explains health point and what not to do in the game. |
 5. Once the tutorial is complete, the Start page for the game is shown. |
6. If the user selects "New Game", it will count down from 3 before the game starts. |
 7. If the jet incorrectly fires a non-buggy balloon, the "NO BUG!" message appears and a 'buzz' sound follows. |
8. If the jet fires a buggy hot-air balloon, the correction message appears and a 'ding' sound follows. |
9. After making 4 mistakes or losing all the Health points, the game is lost. The "Hall of Fame" chart will be displayed. |
What was left unimplemented
- We designed to exclude real time updates of game competitor's progress bar on the user's screen to see how fast they compare to their rivals in the same set of tasks. Adding the multiplayer functionality is unimplemented because it is not practical given the time constraint and the UI will not have significant changes. Moreover, to incorporate real time updates between two competitors, our networked multiplayer mode would involve networking protocol knowledge that would bring a lot of new problems and has little to do with User Interface Design. It appears to us that it is more crucial to make the game work for single user at this point.
- Animated tutorial is missing because it is too time consuming to make.
- The Settings option on the Main Menu is not implemented at this point because it is not part of the basic blueprint of the game. As the game increases in complexity, more advanced features might be added as part of the "Settings" section.
- Complete level menu for "Single Player": due to time constraint, we were unable to implement more games for higher level.
Wizard of Oz Techniques
We do not employ any wizard of oz techniques in our final prototypes. In our interactive prototype, we used wizard of oz technique to perform most sound effects and audio indications of right/wrong users actions during gameplay. We have implemented those features in our games, as described in the Design Evolution section above (green checkmark coupled with 'ding' sound for right answer, and red cross with a 'buzz' sound for wrong answer). Also, in the previous prototype, we manually handled the transitions between the different games due to the time constraint. However, we have also implemented that feature in the final version.
