FinalPrototype-Group:Group 7

From Cs160-sp08

Jump to: navigation, search


Group Members

  • User:Jiahan Jiang
    • Developed parts of Notification
    • Wrote Design Evolution
  • User:Harendra Guturu
    • Developed parts of Notification
    • Implemented new map view
    • Wrote parts of the final report
  • User:Diane Ko
    • Created presentation slides
    • Created item descriptions and new items
    • Created item icons
  • User:Khoa Phung
    • Initially worked on Settings
    • Server Side Implementation
    • Helped with Ranking and Map browsing
    • Wrote Final Interface -> Functionality/Interface design and part of Implementation

Problem and Solution Overview

There are several problems with the current generation of available mobile games and we wish to address each one of them with our unique game design.

Most mobile device games currently do not take advantage of the fact that they can be "mobile" and utilize the GPS system to its fullest potential. Our game mirrors the real world, and the item-collection process is based on the physical presence in the real world. It is a truly refreshing mobile game that offers a whole new gaming experience.

Another issue with many mobile games is that there is no significance in its design; they merely exist for passing time and curing boredom. This game, on the other hand, promotes real-life interaction and travel. the bulk of the game is played by physically going to places instead of sitting in a chair for five hours pushing buttons on the phone. It is a much healthier and more active game than what is available now.

Finally, most games are extremely time-consuming; this is both unhealthy and unpractical. Mobile devices are used "on the run," and the games should be so as well. The user should be able to start and stop the game whenever they wish without losing any satisfaction from being "in the middle of a game" or "in the process of finishing a level." This game is easy to play and does not require any time commitment from the user. People can play this game any time, anywhere. It is a mobile game that fits today's fast-paced society.

Target User Group

Adolescents and college students are the main focus on this application. Most people in this target group already own a phone and have been using it for several years. This removes the problem of having to reach a completely new market which has had no exposure to mobile devices. Furthermore, since the target group has some foundation on using mobile devices, it will have an easier time using more advanced features of the phone such as this game. The need to explore the world to advance in the game will also keep the fickle audience entertained.


The following three tasks are chosen since they are good representative sample of the different interfaces that can be found in our system.

Easy Task: Entering Username and Choosing an Icon

  • Being able to get started is very critical and can decide whether a user just gives up or continues to explore the software. In our game, the user is able to create a new profile easily by choosing their username and icon without having other options interfering with these two critical steps. The wizard technique was used to make the feature easy to use. Any error messages such as a very long name or invalid characters are made clear and visible for the user to correct.
  • The task was chosen since the wizard essentially guides the user to complete the task and there is very little chance that the user would be unable to complete the task.

Moderate Task: Finding and Picking up Items

  • A moderate task would be to find the items and pick them up. This requires a user to be able to navigate to the needed activity screen, figure out where the item is, navigate to it in real life and then pick it up. Several steps in sequence are involved and the user needs to be comfortable with completing them without getting confused.
  • Since the core game play is contained in this task, it is designed to be relatively easy. The reason it is a medium task is due to it being a sequence of tasks.

Hard Task: Activating and Configuring Notification/Alert System

  • The main feature in this application is to find and collect items in the virtual representation of the physical world. Therefore, several types of alerts or notification will be available so that the user does not miss an opportunity to find items that are in the vicinity. To accommodate different preferences for notifications, users will be able to configure the alerts to their desires. To accomplish this task, the user needs to navigate to the settings menu and access the "Item Alerts" options and customize settings such as notification type, frequency of notification, etc.
  • This is hard task since it was designed as a feature that advanced users can use to stay competitive with other high ranking players. This feature does not need to be used by a regular user until he or she has gotten used to the actual game play and thus requires some exploring before it can be used.

Design Evolution

UI Changes

  • Registration

The Registration UI changed between the Low-Fidelity Prototype and the Interactive Prototype. In the Low-Fidelity Prototype test, we presented participants with a registration UI that gives them button options to choose either first create a Username and then choose an Icon or vice versa. In the Interactive Prototype test we presented the participants with a new UI that asks for a valid Username first and then takes them to the list of Icons to choose from. This change was made based on the feedback we received from the Low-Fidelity Prototype test, pointing out that both options belong to the same action series and Username is a required feature whereas an Icon is optional.

Registration in Low-Fidelity Prototype Image:CS160_Group7_Problem1.jpg

Registration in Interactive Prototype

  • Main Menu

The Main Menu UI has changed almost at every development stage. Most of these changes consist of wording and naming alterations that give better indications of what each button encompasses. Between Low-Fidelity Prototype and Interactive, the "Drop Item" button became "Manage Items." This was due to the fact that dropping an item would require choosing an item from the inventory list, so "Manage Items" indicates that the list of items is presented and dropping item option is implemented as a menu option from the "Manage Items" activity. In the Pilot Study it got changed back to "Drop Item" because it is the only option available at the time. Between Pilot Study to the latest implementation, this became became "Look at Loot," which indicates that it presents a list of items but the inventory cannot be managed/manipulated. This is because we have taken out the deleting item option, so the naming changed with it. Between Interactive Prototype and Pilot Study, "Current Status" became "Rankings" because the central server was implemented at this time and rankings option became available.

Main Menu in Low-Fidelity Prototype

Main Menu in Interactive Prototype

Main Menu in Final Prototype

  • Dropping Item

The dropping item option also changed with most of the development stages. In the Low-Fidelity Prototype, we presented a UI that presents this option as a button from the Main Menu and lets the user search for a particular item via a text field. In the Interactive Prototype, it became a menu option from the items inventory. In the most recent implementation the dropping item option is completely taken out. This is because there is not much incentive for dropping items from the inventory unless the private scavenger option is available

Dropping Item in Low-Fidelity Prototype

Dropping Item in Interactive Prototype

  • Map View

The map view for finding items is a recent change reflected in the latest implementation. The old design indicates the nearest item within range and automatically gives the option for picking up an item. The new design presents all items within range and the option for picking up an item is only visible when one of these locations is clicked on. The Main Menu button is changed accordingly from "Find Closest Item" to "Start Scavenging." This is because we don't want the user to keep going back to the page in order to see if there are more items within range.

Map View in Pilot Study

Image:CS160_Group7_8.jpg Image:CS160_Group7_9.jpg Image:CS160_Group7_10.jpg Image:CS160_Group7_11.jpg

Map View in Final Prototype

Major Changes

  • Map View Changes

The map view changes are one of our latest changes but it is a major change. We revamped the entire design and chose a different way of presenting the items within range. The items are no longer small box icons since in one of our usability studies we got a complaint that the box obscured street names and was not easy to spot as a simple dot. The reason we did this was because we discovered the limitations of our previous design of presenting one item at a time. The new system eliminates repeated item requests for the same location, and also allows the user to be able to pick up all items within range without repeatedly going to the finding closest item option. We decided to invest a lot of time and effort into making this change because picking up items is one of the most important features in the scavenger hunt so making it as efficient and accessible as possible is key.

  • Naming Changes

There has been a lot of naming changes throughout the development stages. Most of the changes are for buttons in the Main Menu or the Settings Menu. These are small and detailed changes that we kept on tweaking just to make sure that the buttons are correct indications of the features they link to. There are other naming changes such as changing "avatar" to "icon," and this is again tweaking for the exact meaning of each word or for adding some flare or personality and fun to our application.

  • Dropping Item

One of our important latest changes is taking out the dropping item option. This option went through several changes throughout the stages but had issues in each design. The reason for completely removing this options is because in our Pilot Study, several participants expressed that they don't see the purpose of this feature since overflowing inventories is not a current issue and private scavengers feature is not implemented. For that reason, we decided there is no need for dropping items with our current system and it would be a cleaner design without it.

  • Central Processing Server

We implemented the central processing server before the Pilot Study to have a database for users and items. The purpose of the server is to collect data from all users and implement a ranking system to make the game more competitive and exciting. Another usage of the server is to keep the list of items so they are not hard-coded on each device. This way they are easy to track, manage, and remove if necessary. The server also provides the space for future development such as messaging or scavenger competitions.

Valuable Evaluation Techniques

  • Low-Fidelity Prototype

The Low-Fidelity Prototype was very useful in evaluating our initial big ideas. It was relatively cheap and provides amazing flexibility. Because of the Wizard of Oz technique for the interface, we're able to discover and remedy issues on the spot. The simplicity of the system kept the participants focused on the basic functionalities instead of distracted by colors, shapes, font, etc. It gave us a lot of useful information before we had to start implementing.

  • Pilot Study

The Pilot Study was extremely beneficial because it revealed small, intricate issues in our system. Because of the representative tasks, the users would express their opinions on issues concerning naming confusion, data-flow inefficiency, or the usefulness of certain features. At this time we had most of our features implemented with a few Wizard of Oz techniques, so the users are commenting on the actual implementation.

Final Interface


Welcome Screen

Functionality: The welcome screen (1) will let the user start the application or get more information about the game by selecting the About button. If you are a new user or have reseted the game, then you will be forwarded automatically to set up a new profile (4) or else will be forwarded to the main menu (3).

Interface Design: The application welcome screen (1) is a courtesy to let the user know that the application has been started and to make sure that this is what the user intended to do. Our logo is therefore very visible and easy to recognize. As you can see, we kept it simple by only providing two options, which are so common among almost all applications that they do not confuse a user. In addition, the descriptions are very short and self-explanatory. The About (2) feature is just a description of our game and doesn't provide any functionality, except to go back. The start button will begin the game.

(1) Welcome screen
(1) Welcome screen
(2) About our application
(2) About our application

Main Menu

Functionality: The main menu (3) provides several options to go to different activities grouped by functionality including the following: Start Scavenging (6), Look at Loot (12), Rankings (13), Settings (16), and Help (21).

Interface Design: The main menu (3) is, as the title says, the screen where most applications will return to. This is important so the user can easily return to a familiar point inside the application. In addition, we also implemented a breadcrumbs system to identify what depths level the user is currently in to improve navigability. In addition, the main menu (3) also displays the user's name and selected icon to identify the user and personalize the application. The order of the buttons is displayed by the estimated usage frequency whereas the most used buttons are located on top.

(3) Main Menu
(3) Main Menu

Setting up new Profile

Functionality: A new user is directly forwarded to this screen with clear instructions to enter his/her user name (4) and then select an icon (5).

Interface Design: Being able to get started is very critical and can decide whether a user just gives up or continues to explore the software. In our scenario, the user should be able to create a new profile easily by choosing their icon and name without having other options interfering with these two critical steps. Therefore, the user is forwarded from entering the user name directly to the next step of selecting an icon. Input for these features should be similar to common applications such as the address book to present the user with a similar interface. The user will select one of the several given icons by using the the navigation features from the phone to browse around. Any error messages when entering the user name such as a too long name or invalid characters are made clear and visible for the user to correct via pop up messages.

(4) Create Username
(4) Create Username
(5) Select Icon
(5) Select Icon

Start Scavenging


  • Display map (6): You can move in all 4 directions with the arrow keys and press the enter key to call for the action. There are either no items to be picked up (7) or there is an item (8).
  • No Item for pickup (7): When no item is in pick up range and you issued an action, then the game will return a detailed pop up message to let you know what happened. In this case, no item was close enough to pick up.
  • Item in Range (8): When an item is in pick up range and the user issues an action with the Enter button, then the application will return three options (9), namely to pick it up, examine it further, or just to ignore it.
  • Examine item (10): The user is presented with the two other options from the original three and with a detailed information of the item with the points correlated. If the user decides to pick it up or ignore it will then pop up a notification window (11) for the user to echo on their choice.
  • Scavenging also has the added function of fusing items to form a super item, once a collection of items are found. This is done automatically and the user is informed of the process.

Interface Design: When the user starts the scavenging hunt, he/she is presented with a map centered to the current location set to a certain zoom level with the following map overlays:

  • Person Overlay: This overlay shows the user's current location as a person icon to make sure that the user can identify himself with the virtual representation. Also, the user has a blue circle, which represents his pick up radius. We want the user to physically move to items , but also need to make sure that it is not too frustrating, when a user cannot get to a specific location within few meters. The user will always stay centered to make sure that he/she can see the surroundings. An example can be seen in picture (6).
  • Item Overlay: This overlay will display the item as a green dot and the pickup radius as a green circle as shown in picture (6). There is a perceived affordance with intersecting circles meaning that the the user is close enough to pick up the item. The item overlay just displays items that are inside the visible area of the screen.
  • Arrows Overlay: This overlay will display items that are outside of the visible area, yet within 4 times of the radius of the current zoom level. They are represented by a red dot on the transparent white border (8). We wanted to make sure that the user is given a clue of items nearby. This encourages the user to explore areas further away. The border is transparent white to make sure that the user is aware where to expect the red dots to show up. As the user moves away or closer to an item, it will change from being an Item Overlay to an Arrow Overlay.

The map browser has different options for the following scenarios:

  • No Item for pickup (7): If the user doesn't understand the concept of the intersecting circles in our game, it will display an understandable message to the user to get accustomed to our model. The message will pop up and disappear with few seconds delay for the user to be able to read the message.
  • Item in range (8) & Item option (9): Once the user moves in range of an item and presses the center button, it will return the item description as well as the option with clear function descriptions. The two most important buttons are to the left and right to make clear of their opposing functions. The middle "Examine" button is a intermediary between the two and therefore located in the middle.
  • Examine Item (10) & Pick up Item (11): When examining the item, it will display more information about the item such as the detailed description and points. You are then presented with the other two options as before. If you decide to pick it up or ignore it, we will pop up a quick confirmation window to echo your options for verification.

(6) Display map
(6) Display map
(7) No Item for pickup
(7) No Item for pickup

(8) Item in range
(8) Item in range
(9) Item options
(9) Item options

(10) Examine item
(10) Examine item
(11) Pick up item
(11) Pick up item

Look at Items

Functionality: The application will show the items in the simplest layout, namely a list to scroll up or down with the option to go-back by using the well-known system back button.

Interface Design: When the user wants to look at their items collected, they can easily select the option from the main menu and are presented with a list of their items. This is kept very simple with an image of their item as well as the title, points, and detailed description. The scrolling as well as the go-back options are standardized throughout our application and so common that they should not cause any difficulty.

(12) Look at items
(12) Look at items


Functionality: The main ranking page (13) shows a summary of your current status as well as options to learn more about the level descriptions (14), display the best players around the world (14), or go back to the main menu.

Interface Design: The ranking overview displays a quick summary of how many points you collected, how many more points you need to get to the next level, the description of your current level, as well as your current online ranking with players around the world.

  • The main ranking page (13) is kept simple and displays the most important information for a user. Besides having the top bread crumbs, we intentionally display the other options in the bottom to make sure that the user can take advantage of them without having to hit random buttons. We used a common WYSIWUG approach to avoid users to randomly pressing buttons hoping to open hidden menus.
  • The About Levels page (14) only gives the user the option to read the information and display the main menu option for fast navigation. We displayed the points to the left and tabbed the description to align and make it easily readable.
  • The Top Rankings (15) displays the top 5 players with their rank, points, and user name to give the user the option to learn how far they are from getting on the hall of fame.

(13) Ranking Overview
(13) Ranking Overview
(14) Level description
(14) Level description
(15) Top players
(15) Top players


Functionality: The main settings screen (16) gives the option to change the Game Sound, Item Alert, Icon, and to reset the game as well as the Main Menu button for consistency throughout our application.

  • Game Sounds (17): The user can change when the sound occurs and the volume as well as save the new settings.
  • Item Alert (18): The user can select what type of alerts he can receive and configure their intrusiveness.
  • Change Icon (19): The user can select a new item by using the arrow keys.
  • Reset Game (20): The user is presented with two options that are clearly stated with a warning.

Interface Design: The main settings page is similar in look and feel to other previous screens to enhance familiarity with the layout. We also laid these options out on the estimated usage frequency of them where the top option is the most commonly used one.

  • Game Sounds (17): This option enables the user to either turn the game sounds on or off and to set the volume according to their current environment. The pre-filled options limit the user to the legal actions. We also have a Save Settings button, so the user can be sure when settings are saved or when they have not been. The main menu button is listed for consistency as well as the progress bar.
  • Item Alert (18): The interface for configuration of alerts is very similar to the Game Sounds interface. Below an example of what an actual alert looks like is provided. In the real game, the toast will be replaced with a vibration and the non-intrusive notification will tell the user an item is nearby.
  • Change Icon (19): The user is displayed with the familiar icon selection screen that he/she has been exposed to at the beginning of this game. It is a simple layout and the user can either select a new one of just go back to return. We also display a notification when the settings has been changed to ensure that the user gets constant feedback.
  • Reset Game (20): When the users selects to reset the game, we will display an alert for the user to confirm his choice. We also detail out what the consequences are as to not surprise the user later on. We offer two options that are on opposite sides and clearly labeled Yes and No.

(16) Settings overview
(16) Settings overview
(17) Game Sound
(17) Game Sound
(18) Item Alert
(18) Item Alert
(19) ChangeIcon
(19) ChangeIcon
(20) Reset Game
(20) Reset Game


Functionality: The Help Main screen (21) will give buttons that link to their corresponding subsections, namely overview, settings, using maps, and viewing items. Each submenu will only display text and the possibility of using the system go-back button.

Interface Design: The main help screen will give the user few options to get help on. The layout is similar to the rest of the application to encourage familiarity with it. Also, the breadcrumbs at the top makes sure that the user always knows where they are in the application. All options are displayed to make it very clear for the user that there are no hidden topics. All sub menus (22) are just simple text based details on each topic and offer only the system go-back button for ease of use.

(21) Help Main Menu
(21) Help Main Menu
(22) Help Overview
(22) Help Overview

Implementation Details/Difficulties

  • General: One of the main issues developing our project was to find enough information on how to implement features and functions with the Android SDK. Even though sample projects were a great resource, documentations and examples were not always clear, too complex, or couldn't be found. We had problems importing libraries as android would just reject them and while some online help said that it was not supported, other threads were just open ended or said that it should work. We experienced the same confusion when trying to change specific system settings or running the application in the background and handling notifications. In addition, learning how Android works and how to get the application to show what we intended was a time consuming task of searching the web. The few methods (such as onFreeze, onResume, etc) were not easily understandable in the beginning and caused a lot of confusion when running tests.
  • Server: Our server stores all user and item information for our game. Parameters are being passed into the server via HTML GET methods, which then returns a string to be parsed by the Android application. The server processes most of the data in order to take the load off the cellphone CPU. We use Apache Tomcat Java Server Pages with a MySql backend which can easily handle a large amount of requests. The MySql server has two tables, one for user and one for the item. The user table holds the online id as a key , user name, score, and item list. The Item table holds information about its location, the details, and the details about merging items.
  • Item Fusion: In order to make it more fun, items can be part of a set to create a super item. If you find all items necessary, they will merge to create a super item with a much higher score. The user will be prompted to accept the fusion of items. The logic behind this idea and to make it scalable was a lot harder than initially anticipated because it changed the logic of our game. Therefore, several parts of the program that were affected had to be fine-tuned.
  • New Profile: Due to our server side implementation, the user creates a unique online id in addition to the user name and icon id when a new profile is made.
  • Map: The map overlay system was initially difficult to use because they support very little in the way of pre-made pop-up overlays on the map view. Because of the entire overlay system needed to be drawn using the basic shapes supported in Android. This task was no difficult, but tedious since it was required to constantly recompile for small changes in the UI to see if the changes reflect the desired output. Also testing this stage was a little difficult, since we were doing parallel development, so at times we were not sure if the overlays were broken on if the supporting functions to get the items were broken.

Unimplemented Features

We did not implement two features that we originally brainstormed, since we decided to go in a different direction than the original plan. The two features that were left out include dropping items and creating personalized scavenger hunts. We did not receive too much positive feedback from the users regarding the drop items feature since they were unwilling to lose their precious items. The unwillingness of people to drop their items made the idea of personalized scavenger hunts difficult since users would be very stingy with their items. Alternatively, instead of striving towards personalized hunts to keep the game interesting, we decided to make the game more interesting from the centralized server by implementing features such as clue chains to find items and items merging into a superior item once a set of items is gathered.

A smaller feature that we did not implement was making the "center page" of operations something other than the Main Menu. Although this was requested, we felt that the menu truly is the center of the game and that if users wanted to start at a different location, they could always just exit the game at a different screen and the well handled activity life cycles will allow them to resume at that screen. Also, one of our item alerts allows quickly jumping to the MapBrowser when an item is found, if that is what the user desires.

Wizard of Oz techniques

Due to the lack of physical hardware, a set of wizard of oz techniques were used. The first and rather trivial set is the use of toasts to indicate that the user's preferences are being applied to the item alerts. The actual implementation of sound was not completed since we were unable to create sound clips for the game due to time constraints. Furthermore, even if we had sound clips vibrations would have been impossible using the emulator.

The more serious use of wizard of oz was for the movement of the user. The final version of the game plans to use GPS to track the user's movement and update the map accordingly, but since this is not possible in the emulator, we implemented movement using the DPAD. Clearly this defeats the purpose of having to "explore" your region as suggested by the game's introduction, but we feel this way of testing the interface is more effective rather than having the user follow a set of piped GPS coordinates since that would essentially be watching a scavenger hunt movie rather than playing a game.


[add comment]
Personal tools