PATRICK ARMSTRONG Pervasive Gaming as a means of reminding the user of daily events.

Background The boom in smart phone and mobile devices see’s these items becoming ubiquitous. Design a pervasive mobile game that was:  Location dependant  Time dependant A game that uses the players location and time as a means of reminding the user of daily events

Original Timeline Full game finished in development by late August. Testing finished by now. Results being collated Testing about to begin. Results not ready. Reduced testing time frame. Actual Timeline

Issues Faced Structure of Android development platform  Activity and Context importance. Understanding the way Android uses Views and XML inflation to handle display properties No internet support for phones, drastically the planned map system. AR implemented as a hybrid camera view / custom view rather.

Revised Features Core design changed immediately to handle the way Android deals with classes. SAX Parser to read and write to XML files. Implementation of Parcelable Bundles to transfer data between Activity’s. No internet for Google maps.  Google maps is a superior design, but limited by devices. Map changes meant view was limited. AR overlay is a workaround, it uses a manipulation of views unattached to the camera in any real sense.

GameTab Functionality Handles the creation of the 3 tab activities though is in fact the real workhorse. Handles the creation of the XML data files and then re parses them to build the locations and resources array lists  Each is an array list of a Resource Object or Location Object Pushes the updated ArrayLists to other Activity’s. Runs the two fundamental timers  Timer One: Decrements resources from the resources list at given time frames  Time Two: Handles pushing the array lists at given intervals, this passes the bundles into the Application Context where it can be retrieved as parcelables by the other activities.

PetActivity Built out of XML and a custom View. Update bars handled by the XML view file. Animation handled by the custom view. In a revised build all the necessary graphics built into a single film strip.

ResourcesActivity No combined views, all handled by the XML view inflator. Like the gather activity implements its own inner class LocationListener. Basic graphics.

GatherActivity The most complex Activity. Two fundamental views  Map view  Standard default view.  Used because of lack of internet, any revision would implement Google map API.  Constantly checks the locations array for any locations that fall within the given bounds. If it finds them it marks the index of that value and allows the user to scan for resources. When the user presses the button, view changes.  Camera view  Implements the camera and AR overlay views.  Camera uses a surface view and call back to display the camera.  AR Overlay is a separate view, testing if the resource is within visible range and displaying when it is.

GatherActivity The most complex Activity. Two fundamental views  Map view  Standard default view.  Used because of lack of internet, any revision would implement Google map API.  Constantly checks the locations array for any locations that fall within the given bounds. If it finds them it marks the index of that value and allows the user to scan for resources. When the user presses the button, view changes.  Camera view  Implements the camera and AR overlay views.  Camera uses a surface view and call back to display the camera.  AR Overlay is a separate view, testing if the resource is within visible range and displaying when it is.

Helper Classes Compass  Basic Android SensorListener that takes an orientation on the X, Y and Z axis. Resource and Location parser  Handles parsing raw files on application creation. Logger  Custom logger to write to a text file so I can rebuild the activities the user used while testing. Resource Object  Basic resource object, made up of a name and its quantity Location Object  The location of not collected resources. Includes their long / lat, the time they were planted, if they are user stored and an angle value as a comparison for the AR overlay.

Current Timeline. Testing  Set to commence 27 th – 7 th  Simple 1 hour proof of concept / subjective interpretation.  Lack of time / resources for a full scale test situation. Expo  Determine EXPO placard layout.  Create wrapper to display program use. Finish Report 27 th Sept.– 7 th Oct Testing / Data Collation. Initial report draft October (first half) Finalise Expo content. Create mock up application to simulate experiment steps. Continued report draughts October (second half) Produce Expo placard Final report draughts SEPTEMBER OCTOBER NOVEMBER FinalDeadlineFinalDeadline

Questions?