FinalPrototype-Group:Treo

From Cs160-sp08

Jump to: navigation, search

Contents

Team Members

  • Reid Hironaga - coded new implementation
  • Siyu Song - developed new icons, organized writeup

Problem and Solution Overview

While mobile gaming is not a new concept, conventional games on mobile devices do little more than shrink existing games already available in other mediums such as PCs and consoles by fit them onto a smaller screen. This admittedly takes advantage of the portability of mobile device but the original games were not designed with mobile in mind. We propose that games for mobile devices should be designed with the device in mind, taking into account the affordances of the device and designing game mechanics and game play tools around those affordances. With this in mind, we focused on developing a game that promotes social interaction using the mobile device as a tool to provide players with information during game play. The purpose of this project is to invigorate the play of Cops and Robbers from a social experience into a more strategically rich game. By doing so we wish to allow our application to increase the usage of cell phones in a more diverse set of real-world interactions, not limited to traditional communication. In designing around the portability of mobile devices and providing quick peripheral information, this application is unique to mobile devices as it cannot be easily replicated on another medium such as the desktop.

Target User Group

Our target user group consists of people in their late teens and early 20’s who are familiar with Cops and Robbers and its regional variations. This is a game that is very popular among high school and college students in urban/suburban environments. The ideal users initially are people who have been playing this game and will be intrigued by the added dynamic of knowing where other players are during the course of play.

Tasks

Easy

Scanning for location of robbers as a cop: To do this; first, start the game as a cop. For the purposes of the prototype, the player as a cop will be able to scan for robbers immediately. To do this: press the menu button and select scan for robbers. This will bring the user back to the map screen that is shown during play.

Medium

Getting and using an item: In this prototype this is a medium task because it involves looking at information on the map screen and then a series of keystrokes; however in actual play this would be a hard task because it would involve physically moving to given coordinates while avoiding cop players and then the set of keystrokes to use items. For the purposes of this prototype, the user needs to start the game as a robber. Next, the user needs to locate where the items have spawned between the start and end locations, then use key presses to get the on screen map cursor (that indicates the player’s location) to where the item is on the screen. The user will then acquire the item, and press menu to bring up options to use the item. In this case it is the inverse of the cop’s ability scan for robbers. After this item is used, cop player location will be displayed on the screen.

Hard

Hosting a game: To host a game: users must enter a name at the start-up screen and then select “Host a Game”. This will take users to the Goal Selection screen where the user is to use the directional pad to set a goal location for the game. After this screen the user is taken to the Options Screen where the player will be able to set a time limit for the game as well as change the goal location.

Design Evolution

We focused on two major areas when designing the interface of our application. The first was the flow of the screens, this refers to sequence of screens the user sees from the time the player launches the application to the time game play is started. The second major area of consideration was in the map screens, both the one where the host sets the goal location and the one in which information is displayed during game play.

Screen Flow

Screen flow is what we refer to the transition of activities that the player needs to go through to get from the start screen to actual game play. We wanted to design the screens to be able to guide the players from all the necessary steps of hosting and joining a game and yet do so in as few screens as possible.

Flow of screens in the lo-fi prototype
Flow of screens in the lo-fi prototype

One of the biggest early changes to the flow of the screen was the elimination of a Name Entry screen. Originally in the low-fi prototype flow, the this screen came after the start screen (after the Game Setup screen if the player chose to host a game). The only interaction on this screen was for the player to enter a name, and seeing as how this input was required of both types of players, the name entry field was added to the start screen and this activity was removed. We did this because in the low-fidelity prototype we found that players had to stop and think and evaluate each screen. While each item on a screen needs to be looked at individually, each screen as a whole has the mental overhead of visually scanning the entire screen associated with it. After we saw this in the testing of our low-fi prototype we realized that our goal should be to minimize the number of screens as well as the number of inputs required by the user. In having the name entry field in the front page, we eliminate not only a screen, but the keystrokes associated with selection on the name entry screen as well as the complexity of two extra buttons that were on that screen, also the perceived complexity of having an extra screen where the user must input information.

Other changes we made to the screens between the lo-fi prototype and the interactive prototype involved repositioning the buttons as well renaming then to better direct the user to the necessary tasks. Some of these changes were made from comments we received from testing of the lo-fi prototype. In particular, the “SELECT START & STOP” button was confusing for users as it was not clear what start and stop referred to. In the interactive prototype this was changed to “Set Start/End Locations”.

Flow of the screens in the interactive prototype.
Flow of the screens in the interactive prototype.


Between the interactive prototype and the final implementation, there consideration was more how to make tasks efficient because the changes made to the button names and locations were enough to fix many of the issues users were having in regards to know knowing what to do at a screen. A major change we did make was that once a user selects “Host a Game”, the map screen to select a goal location would be displayed instead of the Options Screen. This was done because we noticed during testing of our interactive prototype but more commonly in the lo-fi prototype, users sometimes made the mistake of not selecting a goal location before selecting start game. This is an error for two reasons; with no goal location there is no game to play, and also our implementation would throw an error if there was no goal location to pass between activities. Displaying the set goal location immediately avoids both these issues by ensure that the host sets a goal location before progressing. This solution worked well because the task of setting a goal location was necessary task that the user needed to do and in having the user press a button before going to the goal set map screen, we provided the user with an opportunity to cause an error. In our final implementation the linearity of the screens ensure all necessary input is given before progressing from each screen.

Flow of the screens in the final prototype, notice that the reordering of screens removes backtracking when hosting.
Flow of the screens in the final prototype, notice that the reordering of screens removes backtracking when hosting.

Map Screen Overlays

We had two screens in which we used the map activity. These screens posed a separate challenge from the others in that the goal was to create overlays that clearly displayed the necessary information given the challenges.

Lo-fi Prototype In the lo-fi prototype there was little planning done in the way of how information would be displayed on the game play map screen and the map screen for selecting a goal state. We had the facilitator who was the computer hold a pencil and point to where the player was on the map for both screens, we found this was not enough information for the player. In addition to adding more information there was an options screen in the lo-fi prototype associated with the game play screen that the player had to go to in order to use items or scan for robber locations. For the same reason as in the screen flow section, these options screen were eliminated in the interactive prototype. Also in the lo-fi prototype the names of the start and stop location were displayed at the top, it quickly became evident to us that that information would not be available to us given just longitude and latitude, and we felt it was not necessary to require the user to enter the games. We felt having icons denote the start and end location was a more elegant solution.

The Map screen in the lo-fi prototype.
The Map screen in the lo-fi prototype.

Interactive Prototype The on screen display became a major part of our interactive prototype implementation. We first had color coded dots to represent the players on the screen. In the game play screen, red dots enclosed in a larger black circle were robbers and blue dots also enclosed in a circle were cops. Status updates like which team you were on and when you've picked up an item were displayed in a small text field across the top of the screen. On the goal selection screen, the menu would pop up right when the goal was selected and the user was prompted with "Done" or "Toggle Satellite View". The initial feedback we got from this early implementation was from the in class presentation, which was that the dots were not very clear about what were cops and what were robbers. Also the black circles were found to be ambiguous. We incorporated these comments in chanages mainly to the map overlays between our interactive prototype and pilot usability tests.

The Map screen to set a goal location in Interactive Prototype.
The Map screen to set a goal location in Interactive Prototype.
The game play screen of the interactive prototype.
The game play screen of the interactive prototype.


Pilot Usability Test Between the interactive prototype submission and the pilot usability test, a number of changes were made based on the comments we receieved as well as our own analysis. The changes made to the options map screen were largely in the menu portion. First, when players press the menu button there is now only the option to “Toggle Satellite View”. This was done so that players cannot select done without first setting a goal position. This tweak removes an error by ensuring that once players have left this screen, they will have set some location as a goal. The second major change to the Options Map Screen is that once players have set a screen, they are prompted with a floating dialog that allows them to “Confirm” their selection, or a “Change Location”. This is the same as an ok/cancel dialog box, but these names for the buttons are much less ambiguous. Also, separating these buttons from the Android menu button allows for further distinction from “Toggle Satellite View”, whereas one is for assisting in the setting of location, the floating menu is for options confirming the entry of a location. The largest area of improvements between the interactive prototype and the pilot usability study was in the game play screens. Graphical enhancements affected both Cops and Robbers game play screens. One enhancement that affected both Cops and Robbers was the inclusion of a color border around the map, blue for cop and red for robber. This was meant to use color to convey which team the player is on. The original idea for incorporating color was to tint the entire screen, however this was too distracting and it made the map more difficult to read. This color scheme was meant to make easier to distinguish the game play screens of Cops from Robbers. The other graphical enhancement was replacement of dots with graphical icons. These icons makes it much less ambiguous which items being displayed are cops and which are robbers. Also the icons are bolder and stand out more on the map interface. Icons are also now used for items and the goal position. Finally, the title bar was removed in favor of a pop up alert for when receiving an item. This was done to get rid of a strip that users would ignore since it would not change often during the course of play. A pop-up alert would grab the player’s attention more, and since it disappears after a short time, it does not hog screen space.

Setting goal location map from the Pilot Usability Test implementation. The pop up menu is now displayed as opposed to the built in menu.
Setting goal location map from the Pilot Usability Test implementation. The pop up menu is now displayed as opposed to the built in menu.
Robber game play screen from the Pilot Usability Test implementation.
Robber game play screen from the Pilot Usability Test implementation.


Final Implementation The feedback we recieved in the pilot usability was key in guiding us in which changes to make for the final application. One major comment we found was that the icons were difficult to tell from one another, even moreso than the dots. In the final application the icons have been redesigned to be bigger and bolder. In addition we have added a help display for new users which can be accessed through the menu. This on screen help is designed to help new users figure out controls and provide some details about expert features.

Analysis Methods

Both the lo-fi testing and the piloty usability testing were very helpful. Since we were designing the interface to be simple and inuitive for the user, getting feedback from users was key. The most important aspect of these tests for us was to ask the user to think aloud as they were performing tasks. While this slowed down the time it took to perform tasks, the information we recieved from users' thoughts were worth the trade off. Recording what the users said during the test and the thought process the users went through were key to many of the insights we used to make changes to our interface. For instance during the lo-fi testing one user looked at the Options Screen, described each button and went directly for the start game button without setting a goal location. This was an indication to us that we were not emphasizing the task of setting a goal location enough. In trying to build a system that is as simple as possible it was important for us to understand what users thought of each step of our interface. Knowing the users thoughts allowed us to identify where we matched the users interpretation with our intentions and where we did not match. For these reasons, user testing was the most useful evaluation feature to us, specifically recording the users' thoughts as they performed tasks.

Final Interface

I. Design and Functionality

Joining a game

The final start screen. Similar to the Interactive Prototype but there is a banner added to this screen.
The final start screen. Similar to the Interactive Prototype but there is a banner added to this screen.

Hosting a game

From the start screen, a user is able to select “Host a Game”. This allows the user to specify settings for a round of Cops and Robbers. By selecting to host a game, the user is taken to the map screen where the user is asked to enter a goal location. In this screen the user controls the position of the goal location by using the directional pad. The words “Select Goal Location at the top of this screen directs users to enter this setting, some expert hotkeys are also displayed directly to the right of the starting location. In this screen, the user has the option to toggle satellite view to assist the user in picking the desired location. This option is available as both a hotkey and by pressing the menu button. Holding down a button on the directional pad will allow the user to move the map cursor to a desired location. Pressing the select button internally sets the goal location to that point and an icon is drawn indicating where the goal location has been selected. The user is then prompted with a pop up display to either confirm this selection or change it. This pop-up was included to give some feedback to the user that the goal has been set before proceeding to the options screen. The game options screen gives hosts a chance to review settings before proceeding onto the game. The timer has a default and a goal location has already been set, this screen gives player a chance to change the time limit if they would like to as well as change the goal location. There is a title bar across the top to prompt the user to take some actions if it is not clear what needs to be done at this screen. Selecting ‘Start!’ from the options screen will take the user to the lobby, where he/she can switch teams before starting the game.


Setting goal location map the circle cursor was changed to an icon.
Setting goal location map the circle cursor was changed to an icon.
New prompt displayed after a goal has been selected.
New prompt displayed after a goal has been selected.

.

Cop game play

The lobby screen represents where the first screen converges, as players who select either join or host game both end up at this screen. On this screen players are able to switch teams from the default setting before gameplay starts. Selecting start game will initiate the start of play.

Coloring As a cop the first thing to notice is the border framing the map. Since this is a game about opposing teams, we wanted to use colors to emphasize that opposition. Playing as a cop, the player is represented by an icon of a cop on the screen that is for the most part composed of blue this coupled with the blue border makes robber icons which are red stand out more.

Initial game play screen for cop.
Initial game play screen for cop.

Controls In our implementation since actual hardware with GPS is not available, game play where cops run around and search for robbers is simulated by using the D-pad. One final feature that was implemented was the ability to toggle satellite view, this is analogous to the option in the set goal location screen and is accessed in the activity menu. The menu is also where players activate their abilities such as scanning for location of other players.

The options available to Cops in the game play menu.
The options available to Cops in the game play menu.

Scanning Cops have the ability to scan for robbers which can be accessed by pressing the menu button. Doing so will allow cops to check where other players are. Player locations are displayed on the map screen as icons.

The result of a scan by the Cop player.
The result of a scan by the Cop player.

Player icons In addition to being color coded blue for cops, red for robbers, the icons are also shaped to have a point on the bottom half which allows for more precision than if the icons were completely round. These icons have been designed to have colors and outlines to be bold and stand out on the default map screen as well as satellite view.

Help Display A help display has been added after requests from users during the Pilot Usability test. It is accessible from the menu and gives information about hotkeys designed for expert users to quickly zoom in and out and toggle satellite view.

The game play help screen.
The game play help screen.

Robber game play

Robber game play is initiated once again, from the lobby screen. Instead of Cop the player switches teams to the robbers.

Coloring/Icons/Controls The idea behind the colored border and the coloring of robber icons is the same as with Cops only this time the color of choice is red and not blue. Similarly, controls are implemented in the same fashion.

Items Items are unique to robbers. In order to access the item option in the menu, the player must first locate the item on the map and move to that location. When the user has reached the location of the item, there is an alert that the item has been picked up, and the player will be able to use the item from the menu. If the player attempts to use an item without having first picked one up, an error message will pop up notifying the player that an item needs to be gotten before it can be used. For the final prototype, we included additional item classes by building an item class framework from which different item implementations can be built upon in a uniform manner. Images, descriptions, and locations are easily handled in this framework. Using this framework, we have increased the potential on-screen items from one to any number of items of any range of descriptions, locations, and visibility.

Timer The on-screen timer was implemented to give the players an easily readable countdown to the end of the game. We kept it black on white shadow text to prevent it from distracting against other important screen elements. The Timer begins at the moment the player enters the game-screen and counts down until no time is left, at which point the game is over. Implementation of the timer involved a running thread that updates the MapView overlay at regular intervals about every quarter second.

Alert for picking up an item.
Alert for picking up an item.
Error for trying to use an item when you have none.
Error for trying to use an item when you have none.

.

II. Implementation

Interface Design & Iterations

The initial interface was designed using Droid Draw. We used this tool to quickly design mock ups for our lo-fi prototype. Those designs were the foundations of our interactive prototype. While the layouts generated using Droid Draw provided a good starting point, we made adjustments to the button sizes and contents as we received feedback from tests.

MapView

The major challenge and accomplishment we faced in the interactive prototype was the use of google maps. While the passing of information to map view and the map view controller were straightforward and relatively well documented, we had difficulties with adding controls to the map view. At first we set up the map activity using xml layouts as we did the other screens, however we quickly found that the only buttons that responded to entry in the way we wanted were the select button, the menu button, and the directional buttons. During the implementation of the map view we found that using setContentView() to set the view to the map view itself and overriding the key listener gave us access to all the keys, which was not the case for using key listener with xml layout. At first we attempted to design the interface around only those buttons and still be able to use xml but we felt strongly that this was too limiting and the controls we developed were too convoluted. We were also under the impression at this point that if we wanted icons they would have to be implemented as Drawable objects on top of the map view using xml. While we wanted to use xml layouts in case we wanted to add widgets in addition to the map, we felt the controls should come first. After deciding not to use xml, we found tutorials on how to use the map view overlay which provided much of the functionality we were looking for such as drawing simple shapes and adding icons.

Connectivity

Connectivity was the most difficult thing we struggled with. Since we do not have working hardware to test on we attempted to create a Wizard of Oz interface where one emulator will control multiple players while the testing application that would be used for testing by individuals would have the normal functionality of only controlling one player. We attempted many ways of trying to simulate this sort of connectivity and while we saw some results the Android SDK just did not have the features that we were needed to implement this effectively yet. The first thing we tried was to use a SQLite database and attempt to share information on the database between emulators but we quickly found that this was not possible for instances of the emulator to share information with each other in real time. Next we attempted to send information between the emulators through SMS messages but the emulator can only receive simulated hard coded messages at this point. The closest we got was with using Gtalk sessions and we were able to implement some connectivity, but this solution was not stable enough for our needs. We were able to use Gtalk sessions to send text information between two instances of the Android emulator but there are still some stability issues that we encountered and found on forums. Using Gtalk would cause a concurrency exception during the use of the application and interrupt the game. While this did not crash the application, the interruption we felt was not good for our implementation. While we were not able to fully implement networking, we feel that passing information as small text strings through either SMS or Gtalk session is an effective solution when it becomes implemented or is stable. Much of the framework necessary for this functionality is in our code now.

III. Wizard of Oz & Unimplemented Features

Simulated Walking

Due to the lack of actual hardware to test on, certain aspects of the game play had to be simulated. The most notable Wizard of Oz technique was the simulation of walking. Since we had no GPS devices to use to track the movement of players, the game play screen had an interface for simulated walking through use of the directional pad. This was done by incrementing and decrementing the longitude and latitude values of the center of the map view depending on which directional button was pressed.

Simulated Connectivity

Our interface design is centered around the goal of connecting players to each other through location data and competition for virtual items. However, due to the time constraints of the project deadlines, we were forced to try to implement connections with various unwieldy tools such as SMS messaging and iChatSessions. The end result of the SMS was finding incomplete documentation and a lack of sufficient example implementations, while iChatSessions seemed very hopeful, until repeated untraceable concurrency exceptions occurred. Unfortunately, we developed an entire framework for the sqlite database before realizing the local nature and the privacy restrictions of independent emulator instances. We also wished to use a mySQL database through an Apache server, but insufficient know-how led us to attempt use of the included packages within the Android SDK. Implementation of the connectivity is now simulated by a static list of players in the lobby as well as a single instance of an actual connection-based player. Due to the instability of the systems, however, the data is not processed correctly and often creates concurrent access exceptions, most notably upon receiving a piece of data through a messageListener stub. There are also hard-coded sample locations of players for both teams that appear in changing locations for each ping initiated by the user.



[add comment]
Personal tools