FinalPrototype-Group:Phi-tus
From CS 160 Fall 2008
Contents |
Each team member’s name and role in this assignment
- Kevin Friedheim - Implementation of final design interface.
- Frank Yang - Final Write-up, helped discuss finalizing the interface
- Xuexin Sean Zhang - Final PowerPoint, Poster, helped discuss finalizing the interface
- Haosi (Jason) Chen - PowerPoint slides, helped discuss finalizing the interface
- Juan Padilla - Implementation of final design interface.
Problem and solution overview
When learning a new language, students are forced to completely change the way they formulate a word or sentence. Translating a sentence is like deciphering a code. It has been understood that one key way of improving a student’s conversational skills in a foreign language is simply through practice. However, in a classroom environment, students are limited to practicing with only their peers during class or organized practice sessions that are hard to schedule. Furthermore, the act of practicing vocabulary words in a classroom is typically monotonous without a casual environment. The system we created aims to take advantage of the accessibility of the internet and open up possibilities for students to easily practice their learned language. Furthermore, by creating a “serious game” the students are provided with a casual environment that encourages the student to do well to win the game.
Target User Group
Our "serious game" was created with the typical student in mind. The game was not geared especially for young students or specifically toward a mature audience. Our goal was to create a game that could potentially unite all the people in the world learning the same language by taking advantage of the giant network that is the internet. People begin learning languages at all different ages and different reasons, whether it be for a course in school or personal reasons, such as travel. Despite the different reasons and background, as mentioned before, providing the opportunity to actually practice the language and receive feedback is the goal of our proposed system, and to keep with the availability theme, we did not choose to focus the target user group on a specific age range. Any person learning a language should be able to benefit from the game, as the game can be played by people of all ages.
Tasks
Rate the drawings (easy task):
The user is simply presented with a screen showing all of the drawings that have been submitted from the last round with a set of an unfilled stars used to perform the rating under each drawing. therefore, the user must simply hover the input device over the stars and once the amount of the stars is “filled”, the user then clicks to lock in the result. The user repeats this process over the number of drawings then selects the submit button for the results to be tallied.
Create a new game (moderate task):
Game creation was chosen as our moderate task because it requires the user to interact with elements not used in other parts of the game; namely, the information form that is presented to users in order to choose the basic parameters of the game such as language and difficulty level. This form is reached by selecting the “create a new game” button form the main screen. Once here, the user chooses the game’s parameters, which are mainly guided through a set of drop down menus for easy setup. Once the user is satisfied with their choices they can click the “create” button and are then taken to the waiting room where they await other player to join their newly created game.
Draw a picture (difficult task):
The screen we used is very simple and familiar to that of most drawing programs such as Photoshop but not nearly as robust. The task simply requires the user to select the mostly familiar tools in the left hand toolbar such as the shape or pencil tool and use them to draw a picture. The task of selecting the proper tools to create the desired effects was the crucial step for this task. Once the image is drawn, the user can either wait until the timer runs out or submit the picture early for possible bonus points.
Design Evolution
Coming out of our brainstorming stage, we had the idea of providing some sort of flashcard game that could be used for students that needed to memorize key facts or data through repetiion. We recognized that although many students have different methods for studying, flashcards are a very common and effective method. We attempted to use the idea of flashcards in a Simon-like game where the player would be quizzed with flashcards that players could quickly and easily make within the game (Figure 1). However, it became quickly apparent that the "fun factor" of the game would be extremely low.
As soon as we realized the limitation of the flashcards idea, we decided to turn our project in a new direction. From the idea of memorizing vocabulary words, we shifted to the idea of actually using the words in practice. From here, we shifted to the idea of melding concepts from the game Taboo and Pictionary to keep the player engrossed in the game. By creating a multiplayer aspect, the player is exposed to peers of his own skill level, creating a casual atmosphere that promotes a camaraderie where players must help and depend on each other to learn and succeed. With the idea of the game set, we created our lo-fidelity prototype. While basic concepts remained the same from the lo-fidelity prototype, many aspects of our interface evolved as we went through the steps from our low-fidelity prototype (Figure 2) to interactive prototype (Figure 3), and pilot usability test. We knew we wanted to incorporate the speaking and listening comprehension in to the game as much as possible, but still provide some sort of method for the players to improve their skills.
Our design of the drawer's part of the game was at first a little cluttered compared to our final prototype (Figure 4).
As soon as we received feedback from our low-fi prototype, it became clear that in the given time span for drawing, more than half of the available tools were mostly unused. We quickly found out that although the tools that were available in the low-fi prototype would be useful in a paint application, given the time-sensitive nature of our system, only the basic tools and colors are needed. We removed the polygon tools that we originally had in the toolbar as well as the select tool. These tools, we found, were almost completely ignored due to the nature of the player's assignment at the time. Since the player only has one minute to try and translate the description being spoken to the player, most player's put more emphasis on making the picture as nice as possible with the given pen tool, only changing tools to try and erase or clear the board. We also noticed that some of our users had expressed annoyances with the color selection being in a button with a dropdown menu. In order to reduce the accuracy needed to select a new color, we removed the menu and placed each color as it's own selectable button along the bottom of the window. However, to further decrease the time wasted maneuvering to a color, we enlarged the color buttons and moved it to the right side of the window.
Although it was not listed as one of our three tasks, we also updated the design of the tasks involved with being a dictator in the game. Going with the idea found in the popular games Taboo and Scattergories, our initial idea simply involved the dictator describing a given picture in the foreign language. Depending on the difficulty, the dictators may be forbidden to use certain words. However, after various rounds of experimentation, we found that while this is the chance for a player to improve on his or her speaking skills, there is nothing implemented in the game for the player to improve on the player's current skill level. For example, if the player sees a picture and has not learned the proper vocabulary words to even describe the picture, the player would not learn the word as well as perform poorly in the round.
In order to address this issue, we added the ability for the player to sacrifice some of his or her own points for a hint word that would help the player describe the picture and finish the task. By providing this function, even the most clueless players would have the opportunity to learn new vocabulary words as they play the game.
We found each evaluation technique to be extremely useful, as each of them brought about many changes. However, we found the results of the low-fidelity prototype to be the most useful in the evolution of our system. Although the lo-fi prototype was not an electronically functional prototype, the insight of a user outside of our design group brought up flaws in our design that we would not have noticed ourselves. Our most significant changes had been in the drawer's screen, all of which were a result from the lo-fi prototype evaluation that we conducted. This helped us be more efficient with our design, having not wasted any time coding a function that would not be used.
Final Interface
Basic Overview
Our system provides the interfaces for the typical functionalities of a browser based community web game. The user can login with a created account and join existing games or create a new game with the user's personal settings. Once a game is ready to start, the admin of the room will begin the game.
The rules of the game are simple. For each round, a player will either take on the role of the dictator or the role of the drawer. Each player will be paired with another player in the same game that has the opposite role. The dictator must describe a picture to the drawer and the drawer must listen and draw the described picture to the best of his or her ability in the given time. After time is up, the dictators of the round will rate each of the drawings individually and the highest rated drawer and paired dictator will be the winners of the round and receive points.
After a round, the players are brought back to the waiting room where a new round will start if all players are ready.
Login Screen
At the very beginning, players are presented with a login screen (Figure 7). The login screen has the name of our game, as well as a short mission statement under it. There are the typical username and password fields, as well as a link at the bottom of the screen that players can click on to read the rules of the game. This screen was kept relatively simple. The player can easily recognize the required task that must be completed based on the norm that has been created by other systems with login screens.
Home Screen
Upon logging in, the player is presented with a Home screen. The screen shows a table of currently active games for the player to join. The table provides the player with information about each of the games, such as the language, skill level, and number of players. Each available room is listed by row in the table, and at the end of the row there is a button to select to join the game. Below the table there are buttons that provide the options to log out and to create a new game. The buttons are rectangular with rounded corners with text in the middle, which is standard in interfaces today. The user should have no trouble recognizing what to select. In the top right hand corner, there is ? button that can also be pressed to provide the player with more information about the screen, should it be needed. We decided to have the help button as a last resort to the completely lost user. We did not the button too big as to distract the player from the task at hand, but was made a different color (blue) in order for the player to know of its presence. The screen also displays the player's statistics (Figure 9) at the bottom of the screen, to provide statistical feedback of the player's status in the game.
Creating a New Game
At the Create New Game screen (Figure 10), the system allows the players to set the options and settings of the room they are about to create. The players are presented with a form with several fields that they must fill out. Each of the fields sets a different option of the game. The information is presented as a standard online form, with empty fields next to the setting. However, to further encourage the using of the help button as last resort, the hovering action over each of the fields causes a description of how the setting will affect the game. Language selection, difficulty selection, and number of players selection were all presented as drop-down menus, due to the low number options for each of the settings. While the data could have been presented using radio buttons, it would be more confusing for the players to check the form if all the options were on screen at once. We also made sure to include a way for the player to leave the menu without creating a game just in case the player so desires to do so. We wanted to make sure the player had full control regarding the navigation of our system.
Game Waiting Room
After the player presses the create button, a room is created and the user is taken to the waiting room of the newly created room. The interface allows for the user to see which players are in the room as well waiting to play the game. While the players are waiting for the game to fill, they are free to chat with each other using the chatbox on the lower half of the screen. The player that created the game has admin rights in the game, with the power to kick and ban players from a game. Once everyone is ready, the admin will be able to start the game.
Half of the players are randomly assigned to be drawers and the other half dictators. The dictators and drawers are then anonymously paired up for the round. To notify players what role they will be taking, there is a transition screen that doubles as a "loading" screen for players to sync with each other, if the time is necessary. During this screen, players can only wait for the timer to countdown. When the timer is up, players are presented with the screen reflecting their role. By providing the timer, the players are not thrust into their role unexpectedly, and minimal time is wasted trying to figure out what to do.
Drawing
The drawer's screen has the most functionality in the game. As mentioned before, the drawer's task is to listen to the dictator and draw the picture that the dictator is describing. Since there is only one minute to complete the task, we wanted to minimize time spent navigating the interface as much as possible. The interface allows for the drawer to select a selector tool, a pen tool, a line tool, and an eraser tool. The player can also customize the width of the brush, as well as the color. We kept the toolbars to the left and right of the drawing window instead of keeping it all on one side. This allowed the buttons themselves to be larger so the players would not lose valuable time misclicking a neighboring button. To prevent forcing players down a path in the game, the player can exit the game at any time via the Home button (Figure 11) at the top right button on the screen, as well as access a help menu, should it be needed. The Home button is a distinct red color in order for the player to associate the button with a sense of stopping and leaving the game. The player is encouraged to draw quickly and will receive bonus points if the player submits the drawing early and wins the round. A timer (Figure 12) is placed on the top of the window, allowing for the player to keep track of the time that has elapsed. The timer is not large enough to distract the player, but enough for the player to easily keep track of elapsed time. Also, in the cases that the players are engrossed in drawing the picture, the timer begins to flash when time is running out. After the timer runs out, a follow up message stating that the round is over appears. After a few seconds, the drawer is taken to the drawer rating screen (Figure 13), where drawers can watch their drawings are being rated by the dictators. During this time, drawers have take no action in the process of rating, but are still free to talk to the players in the game via the chat window on the screen. After all ratings have been submitted, the highest rated drawer/dictator pair is announced for the round in a results screen. All players are then brought back to the waiting room screen, where players are free to start a new round.
The drawer's screen proved to be the most difficult to implement, having the most buttons and interactivity with the interface itself. Not only did the design need constant adjustment, as can be seen in the evolution of our system, but it also required technical skills to code. Working in the completely new environment of Flash, creating a basic paint applet with tools proved to be the toughest of all of them.
Dictating
If the player is assigned as a dictator, the player is routed to a dictator screen (Figure 6) when the round begins. Here the players are presented with a picture that they must describe to the unknown drawer. In the case where players feel they do not know enough to properly describe the picture, players can click on the hint button (Figure 14), which provides players with a key vocabulary word to describe the picture with, while deducting points from their score in the game. At the top of the screen, the player is provided with the timer, score, home and help buttons as the drawers did. Upon the completion of the drawing/dictating phase, the dictators are brought to the same drawing rating screen as mentioned before. While the drawers could not rate any drawings, the dictator's role at this point is the rate all the drawings that have been produced by the drawers of that game instance. The rating is based on a five star system. When players roll over the blank stars, stars fill in from left to right and a quick description of the stars representation appears to aid the drawers' in judging (Figure 15). The stars remained filled after the player has clicked on the star to indicate the recognition of the rating. After all the pictures have been rated, the player submits the vote and waits for all other players to do the same. The ratings are calculated, and the winner is revealed via the results screen stated before. Players are then taken back to the waiting room, where another round can start.
Unimplemented Parts and Wizard of Oz Techniques Used
We decided to leave the networking parts of the system unimplemented. Given the time and lack of knowledge regarding networks that our team possessed, we did not feel it would be wise to spend too much time trying to develop the game with a game server. In result, while the interface is implemented, the mechanics behind the interface are not. In order for it to fully work, we would need to implement a server to hold all the game instances, as well as be able to properly connect each dictator/drawer pair so audio and drawing updates could be recorded. Since the goal of the course was to provide the best interface that the players interact with, we decided to not spend too much time researching the topic.
As a result of this, the parts of the game requiring a server and networking are implemented with "Wizard of Oz" techniques. Game instances are not truly created on a central server, and scores are not recorded on the database of the server. Similarly, the drawings on the ratings screen are not drawn by other players on the server. While this makes the game largely unplayable, the surface interface is implemented completely.
