Droid Hunt

Current Iteration Plan:

We implemented hunt saving (to SD cards), and also editing capabilities for hunts,steps, and clues. The server was also refactored, and a GUI added to facilitate server operations. Aserver request log has also been created. Revision control (in order to maintain updated hunts in theevent they are currently in use) has also been hammered out, along with even more error handling. The GUI was also refined to incorporate a variety of dynamically created content.

Future Iteration 6 Plan:

Given another iteration, we would implement additional types of clues, such as video or audio. Multiplayer would also be another option, as well as further anti-hacking measures. In addition, the GPS positioning system might need to be revamped to provide more accurate fixes even through changes in access points.

Current Codebase:

Download Link

Current JavaDoc:

Javadocs

Current Iteration Plan:

Users are able to fully create and send a hunt to the server. They are also able to download a list of hunts from the server and join one to play. They will then be able to play through the hunt. Currently most of the backend and GUI has been hooked up together. We have the individual components for the Camera/ImageClues and GPSSteps but we still need to incorporate them with our GUI. As such, right now, hunts are just TextClues and TextSteps. We also did JUNIT tests for our base classes. The server was redesigned in order to follow the proposed guidelines. Server can now log incoming requests from the client and saves it in a text document in the droidhuntserver folder.

Future Iteration 6 Plan:

We will incorporate the multimedia clues/steps into our hunts. We will store a local copy of hunts on the phone’s SD card when they want to create a hunt to allow them to edit their hunts. We will store a local copy of the downloaded hunts so that the user can continue to play a hunt in between sessions. We will refine error messages for the GUI as to improve user experience.

Current Codebase:

Download Link

Current JavaDoc:

Javadocs

Current Iteration Plan:

We were able to continue to create additional GUI screens. We also refined existing ones and made sure that the android keyboard only appeared when the user wanted to enter text. We also hooked up a host of popup dialog events to trigger when the user did something incorrectly when logging in. With that said, the login/create user flow now incorporates error handling. We continued to create game objects and now have working renditions of Text and GPS steps. We also have working Text and Picture clues. The backend is able to create/send and store hunts on the server, and we are also able to query the server for a list of hunts that we can potentially download. We also had to figure out exactly how the android activities worked and now have a working Game class that takes care of all the logic that the phone may need. This makes it so the GUI doesn’t have to directly communicate with the phonecommunicator or the hunt creator.

Future Iteration 5 Plan:

We will hammer out support for all the other multimedia clues and steps. And finish refining various aspects of our rough GUI screens. User should be able to begin playing in a hunt and successfully complete one. We will also need to mesh together elements of the GUI and the backend so that they can successfully communicate between one another.

Future Iteration 6 Plan:

Continue refining our GUI and make sure that the server can handle our workload. Insure that all aspects of our GPS locations are working. Finish up anything else we still need to polish.

Current Codebase:

Download Link

Current JavaDoc:

Javadocs

Iteration 3

Group 4′s OOSE Project: Droid Hunt.

The team consists of: Kirk Sabnani, Serena Jeblee, Siren Wei, Sam Hu, Tony Zhang

Scavenger Hunt Rules:

• Hunts are made up of a series of steps. Each step has an answer associated with it. The user must complete a step in order to gain access to the next step of the hunt. In order to finish a step, a series of clues are associated with each step to aid the user to the answer.
• When user downloads and joins a hunt, they receive the first step.
• User must use the given hints to reach the GPS location for each step.
• When user reaches this destination, they check their location to see if the destination has been reached.
• If it is, the user receives another clue to continue their hunt.
• When user reaches destination of the last clue, they are considered to have won the hunt.
• Users are not to share clues or hack hunts; this is cheating.

Features:

• The game GUI and logic will allow users to create, edit, download, join, register, and quit hunts through various screens.
• Users will have the ability to create and edit their own scavenger hunts complete with lists of clues.
• Users will be able to share their scavenger hunt game with other droid users via an online repository (the repository will also store data pertinent to the progress of each hunt such as clues and objective details).
• Users will be able to download hunts from the repository using the droid’s connectivity.
• Users will be able to conduct hunts via a concurrent single player system (multiple users participating in instances of the same hunt).
• The app will update users with new clues, etc. in real-time as they progress to new objectives in the hunt.
• There will be leaderboards for the top users in order to provide incentive to use the app.
• Users will need to set up a game account with a username and password in the app in order to perform the aforementioned operations.  This will allow for user accountability, increased security and create a user infrastructure for data transfer.
• Users will be able to search for clues and hunts to facilitate ease of use.
• The abilities of the droids to use different sensors to detect clues will be included as a gameplay mechanic.
• The clues will vary widely in order to maximize use of the multiple sensor abilities on the droids.  Examples of clues include text, GPS coordinates, pictures/video, and audio.
• All Droid Hunt data on droids is to be stored on SD cards in order to maintain data liquidity (for convenience of interchangeability).

Future Features (Post Iteration 6):

• Droid Hunt has a high potential for multiplayer; in the future, real-time multiplayer would be a big step forward in terms of user connectivity and competitive play.
• There would be separate game “modes” with different rules that would increase the amount of gameplay and thus interest for players.
• Players could have achievements or accomplishment lists that would further increase interest in continuing to play the game.  Players will also value their accounts more if those accounts have unlockable features, etc.
• The database would have increased security in order to prevent hackers from injecting malicious code or stealing information.
• More complex and creative clues would be instituted into hunts to challenge users.

Deployment Diagram:

Architecture:

The project will consist of two applications. One will be the Droid Hunt application that is run on the Android Phone. The second application will be running on a remote machine ( one of our laptops ) and will provide a server for the Android application to connect to. The two will be linked together through TCP sockets, and the server will also provide data storage for the Android application. The Android application will only store information on the current clue on its local SD card. The rest of the data will be given to it from the server once the user has completed their current step. This insures that the user only has a limited amount of hunt data on their phone and will limit the opportunities for cheating to occur. The data that will be sent through our sockets will be serialized versions of Hunts/Steps/Clues. This will allow us to reconstruct the original object after receiving it at the other end of the connection. All of the data accessing will be handled through the server application. When a person has completed a given step in the hunt, it will send what the user deems to be the answer to the server and if this answer is correct, then the server will navigate through its folder hierarchy until it finds the next step in the hunt and sends it back to the user. The data package will contain the current user’s ID, hunt ID, step ID, and answer. As a result, the amount of data that the phone will have access to will be limited to the exactly what it needs for the current step. This way, the phone application does not have direct access to the hunt data files and must use the server as an intermediary. As a result, the server will also end up doing most of the logical game-state checks for the hunt. Thus, in model view controller schema, the model would be the server application and our Android application would be the view that the user sees. The file database itself will simply be  a series of files that are storing the serialized version of the hunt/step/clue objects. They will be organized in a folder hierarchy that will allow the server to easily access the required elements.

Use Cases:

Actors: Master, Player

Master use-cases:

Master creates new scavenger hunt:

1. User presses “Create New Hunt” button from the main screen.
2. User is sent to the Create New Hunt screen.
3. User specifies the name and type (e.g. public, invite-only) of hunt in provided fields.

3.1.      User presses the “Back” button.

3.1.1.   User is sent back to the main screen.

1. User is sent to the add new clue screen to add clues to the new hunt.

4.1.      Name or type of hunt is invalid, which leads to an error message and a prompt to re-enter hunt data.

5.   The first clue is added with a confirmation message.*

6.   User is asked if they would like to enter more clues for their hunt.

6.1.      If they do, user is sent to the edit hunt screen for that hunt to add more clues.

6.2.      If not, user is sent back to main screen.

7.   Hunt is added to database when user returns to main screen.

*Steps 5-7 imply that every hunt must have at least one clue in order to be created.

Master adds clue to a hunt:

1. User presses “Add New Clue” button (from either the create hunt screen or the edit hunt screen).
2. User is sent to the Create Clue screen.
3. User specifies the destination, sequence order, type (e.g. text, audio, video), etc. of the new clue and enters type-sensitive data relevant to the clue into (e.g. clue text, file location of video/audio file) into provided fields.

3.1.        User presses the “Cancel” button.

3.1.1.    User is sent back to their last screen (either the main screen or edit hunt screen).

1. User presses “Upload Clue” to add the clue.
2. Upload data is valid and clue is added to the hunt’s clue list along with a confirmation message.

5.1.        Clue data is invalid (e.g. file location does not exist), leading to an error message and a prompt to reenter clue data.

1. User is asked if they would like to enter more clues for their hunt.

6.1.      If they do, user is sent to another add new clue screen.

6.2.      If not, user is sent back to their last screen (either the main screen or edit hunt screen).

Master edits a hunt:

1. User presses “Edit Hunt” button from main screen.
2. User is sent to the ‘select hunt to edit’ screen.
3. On the ‘select hunt to edit’ screen, the user clicks on a hunt from a list of hunts to edit it (a security question/password may be requested).

3.1.        User presses the “Cancel” button.

3.2.        User is sent back to the main screen.

1. User is sent to an edit hunt screen where they can change the name/type of the hunt in the provided fields.

4.1.      User clicks on a clue from the clue list.

4.1.1.   User is sent to the edit clue screen for that clue.

4.2.      User presses “Add new Clue”.

4.2.1.   User is sent to the add new clue screen.

1. User presses the “Done” button to save the hunt and its changes if any.
2. User is sent to the ‘select hunt to edit’ screen.

6.1.        New Hunt data is somehow invalid, leading to an error message and a prompt to reenter hunt data.

Master edits a clue:

1. User clicks on a clue from the clue list of a hunt in the edit hunt screen.
2. User is sent to the edit clue screen for that clue.
3. On the edit clue screen, the user can alter clue data in the provided fields.
4. User presses “Change Clue” to save any changes.

4.2.        User presses the “Cancel” button.

4.2.1.    User returns to the edit hunt screen and any changes made are undone.

1. User is sent back to the edit hunt screen.

5.1.      Clue data is invalid (e.g. file location does not exist), leading to an error message and a prompt to reenter clue data.

Master deletes a clue:

1. User clicks on a clue from the clue list of a hunt in the edit hunt screen.
2. User is sent to the edit clue screen.
3. On the edit clue screen, the user presses the “Delete” button.
4. A confirmation dialog asks the user to confirm the deletion.

4.1. If user confirms, the clue will be deleted from that hunt.

4.1.1.   The user is sent back to the edit hunt screen.

4.2. If user aborts, the user is sent back to the edit clue screen.

*******Master searches for hunt to edit:

1. On the ‘select hunt to edit’ screen, the user presses the “Search for a Hunt” button.
2. User is sent to the search hunts screen.
3. On the search hunts screen, the user enters search terms (e.g. names, clues, etc.) into the provided fields.
4. User presses “Search” to initiate the search.

4.1.        The user presses the “Cancel” button.

4.1.1.    User is sent back to the ‘select hunt to edit’ screen.

1. User is sent to the search results screen.
2. On the search results screen, a list of hunts that match the search terms will appear for the user to select.
3. The user selects a hunt by clicking on it.

7.1.        The user presses the “Back” button.

7.1.1.    User is sent back to the ‘select hunt to edit’ screen.

1. The user is sent to the edit hunt screen for that hunt.

*******Master searches for a clue:

1. On the edit hunt screen, the user presses the “Search for a Clue” button.
2. User is sent to the search clues screen.
3. On the search clues screen, the user enters search terms (e.g. names, order number, etc.) into the provided fields.
4. User presses “Search” to initiate the search.

4.1.        The user presses the “Cancel” button.

4.1.1.    User is sent back to the edit hunt screen.

1. User is sent to the search results screen.
2. On the search results screen, a list of clues that match the search terms will appear for the user to select.
3. The user selects a clue by clicking it.

7.1.        The user presses the “Back” button.

7.1.1.   User is sent back to the edit hunt screen.

1. The user is sent to the edit clue screen for that clue.

Player use-cases:

Player logs in:

1. User opens the Droid Hunt app on their Droid.
2. User is sent to the login screen.
3. User is sent to the main screen.

1. User logs in by entering his/her username and password in the provided fields.
2. User presses “Login”.

5.1.      User enters incorrect credentials, leading to an error message and a prompt to re-enter credentials.

5.2.      User does not have a username/password, so they must register on the server.

Player registers on the server:

1. User presses Create New User button on the login screen.
2. User is sent to the create new user screen.
3. User enters a desired username, password, and password confirmation in the provided fields.
4. User presses the “Submit” button.

4.1.        User presses the “Cancel” button.

4.1.1.    User is sent to the login screen.

1. User enters valid credentials, and a new account is made with those credentials, with a confirmation message shown.

5.1.        User’s desired credentials are invalid or are taken by other accounts.

5.1.1.    User is sent back to the create new user screen with an error message and a prompt to re-enter different credentials.

1. User is sent back to login screen.

Player downloads hunt:

1. User presses “Download Hunt” button on the main screen.
2. User is sent to the download hunt screen.
3. User chooses a hunt to download by clicking on it from a list of hunts on the server.

3.1.        User presses the “Cancel” button.

3.1.1.    User is sent back to the main screen.

1. The user is asked to confirm if they wish to download that hunt.

4.1.        If so, the hunt is sent to the user’s Droid.

4.1.1.    Hunt is successfully sent and added to the user’s list of hunts.

4.1.1.1.        User is sent back to the download hunt screen along with a confirmation message.

4.1.2.    User cannot download hunt due to connection or privacy issues.

4.1.2.1.        User is sent back to the download hunt screen along with a detailed error message.

4.2.        If not, the user is sent back to the download hunt screen.

Player joins a hunt:

1. User presses the “Join Hunt” button from the main screen.
2. User is sent to the join hunt screen.
3. User selects a hunt by clicking on it from the list of hunts that the player has downloaded.

3.1.        User presses the “Cancel” button.

3.1.1.    User is sent back to the main screen.

1. User presses “Join Hunt”.
2. User is added to that hunt’s list of participants and sent to a hunt progress screen where they can play the hunt.

5.1.        User cannot join hunt due to connection or privacy issues.

5.1.1.    User is sent back to the join hunt screen along with a detailed error message.

*******Player searches for a hunt:

1. On the download hunt screen, the user presses the “Search for a Hunt” button.
2. User is sent to the search hunts screen.
3. On the search hunts screen, the user enters search terms (e.g. names, clues, etc.) into the provided fields.
4. User presses “Search” to initiate the search.

4.1.        The user presses the “Cancel” button.

4.1.1.    User is sent back to the download hunt screen.

1. User is sent to the search results screen.
2. On the search results screen, a list of hunts that match the search terms will appear for the user to select.
3. The user selects a hunt by clicking on it.

7.1.        The user presses the “Back” button.

7.1.1.    User is sent back to the download hunt screen.

1. The user is asked to confirm if they wish to download that hunt.

8.1.        If so, the hunt is sent to the user’s Droid.

8.1.1.    Hunt is successfully sent and added to the user’s list of hunts.

8.1.1.1.        User is sent back to the search results screen along with a confirmation message.

8.1.2.    User cannot download hunt due to connection or privacy issues.

8.1.2.1.        User is sent back to the search results screen along with a detailed error message.

8.2.        If not, the user is sent back to the search results screen.

*******Player searches for a clue:

1. On the hunt progress screen, the user presses the “Search for a Clue” button.
2. User is sent to the search clues screen.
3. On the search clues screen, the user enters search terms (e.g. names, order number, etc.) into the provided fields.
4. User presses “Search” to initiate the search.

4.1.        The user presses the “Cancel” button.

4.1.1.    User is sent back to the edit hunt screen.

1. User is sent to the search results screen.
2. On the search results screen, a list of clues that match the search terms will appear for the user to select.
3. The user selects a clue by clicking it.

7.1.        The user presses the “Back” button.

7.1.1.   User is sent back to the hunt progress screen.

1. The user is sent to the clue details screen for that clue.
2. The user presses the “Back” button on the clue details screen.

10.  The user is sent back to the hunt progress screen.

Player deletes a hunt:

1. User presses “Join Hunt” button on the main screen.
2. User is sent to the join hunt screen.
3. User selects a hunt to delete by clicking on it from the list of hunts that the player has downloaded.
4. User presses the “Delete Hunt” button.
5. A confirmation dialog asks the user to confirm the deletion.

5.1. If they confirm, the hunt will be deleted from the list.

5.1.1. The user is sent back to the join hunt screen.

5.2. If they abort, the user is sent back to the join hunt screen.

Player progresses to next step in hunt:

1. User reaches destination point specified by a clue in hunt.
2. User checks their location correctness by pressing the “Check Location” button on the hunt progress screen.
3. The app compares the players current location with the location specified in the clue.

3.1.        The GPS locations match.

3.1.1.    The hunt progress screen displays a new clue for the player, along with a progress notification.

3.2.        The GPS locations do not match.

3.2.1.    The player is sent a message stating they are not at the correct location.

1. GUI reverts back to progress screen.

Player finishes hunt:

1. User reaches and confirms destination point specified by last clue in hunt.
2. User receives a congratulation message on the hunt progress screen.
3. User’s completion time is sent to the server for score storage.
4. User is asked if they wish to participate in another hunt.

4.1.        If they would, the user is sent to the join hunt screen.

4.2.        If they don’t, the user is sent to the main screen.

Player leaves hunt:

1. User presses the “Leave Hunt” button on the hunt progress screen.
2. User is asked to confirm.

2.1.        If they do, the user is sent to the main screen.

2.2.        If they don’t, the GUI reverts to the hunt progress screen.

Player exits app:

1. User presses the “Exit Droid Hunt” button on the main screen.
2. User is asked to confirm.
   1. If they do, the app closes.
   2. If they don’t, the GUI reverts to the main screen.

Use cases with ******* are based on features that will be implemented only if time permits.

Domain Model:

Hunt:

The hunt is created by the user and stored online by the server. A hunt is made up of multiple steps.

Step:

Each step consists of a series of clues and an answer. The clues help the player to finally arrive at the given answer. Answers will initially be GPS locations and they will be compared to the GPS location that was specified as the answer when the given step was created. When a user tries to check their step answer, they will end up sending their information on their current hunt/step along with their answer to the server. The server will then validate whether or not the information is correct. If it is, then the server will end up sending the next step to the user. This way the phone will only have to store information on the current step.

Clue:

Clues are hints that navigate and aid the user in finding the right answer for a given step. Clues can come in a variety of ways such as text, picture, sound, ect.

Storage:

The various hunts, steps, and clues will be stored in files both on the server-side and on the phone. The phone will only have access to the current step that it is on’s file, while the server will have a copy of the entire hunt/step/clue. The objects will be stored inside the files as serialized versions of the objects, so they can be reconstructed at a later time.

UML Sequence Diagram:

UML Class Diagram:

Current Iteration Plan:

We were able to create a host of GUI screens. We also implemented a host of basic game objects, such as hunt, step-interface, and various clues that still need to be hooked up to the game logic. The server and phone have the ability to create new users as well as login existing users. The server is able to store the players as serialized objects in files, and is able to reconstruct the playerlist when the server is booted up. We have also hooked up the create player flow with the GUI panels, so when the user creates or logs in as a player on the Android device, they are able to connect with the application server.

Future Iteration 4 Plan:

Implement Creating hunts/steps/clues and adding them to the server. We will also be creating more GUI screens as well that will encompass all the other pages in our GUI designs. This will also allow us to serialize the hunt/clue/step objects into files on the server. We will also be able to edit existing hunts/steps/clues.

Future Iteration 5 Plan:

We will hammer out support for all the other multimedia clues and steps. And finish refining various aspects of our rough GUI screens. User should be able to begin playing in a hunt and successfully complete one.

Future Iteration 6 Plan:

Continue refining our GUI and make sure that the server can handle our workload. Insure that all aspects of our GPS locations are working. Finish up anything else we still need to polish.

Current Codebase:

Download Link

Current JavaDoc:

Javadocs

Iteration 2

Group 4′s OOSE Project: Droid Hunt.

The team consists of: Kirk Sabnani, Serena Jeblee, Siren Wei, Sam Hu, Tony Zhang

Vision Statement:
Our app allows a person to create a virtual scavenger hunt and then share that hunt with other droid users in order to create a multiplayer game where players share clues in order to lead other players to real-world locations. We will make use of the droid’s various sensors and features for this game, including the GPS, compass, light sensor, picture/video sharing, and audio recorder.

Features:

• The game GUI and logic will allow users to create, edit, download, join, register, and quit hunts through various screens.
• Users will have the ability to create and edit their own scavenger hunts complete with lists of clues.
• Users will be able to share their scavenger hunt game with other droid users via an online repository (the repository will also store data pertinent to the progress of each hunt such as clues and objective details).
• Users will be able to download hunts from the repository using the droid’s connectivity.
• Users will be able to conduct hunts with other users in competitive multiplayer.
• The app will update users with new clues, etc. in real-time as they progress to new objectives in the hunt.
• Multiplayer will have clear-set progress and winner notifications and possibly specific rules/game modes for each hunt (if time permits).
• Users will need to set up a game account with a username and password in the app in order to perform the aforementioned operations.  This will allow for user accountability, increased security and create a user infrastructure for multiplayer.
• Users will be able to search for clues and hunts to facilitate ease of use.
• The abilities of the droids to use different sensors to detect clues will be included as a gameplay mechanic.
• The clues will vary widely in order to maximize use of the multiple sensor abilities on the droids.  Examples of clues include text, GPS coordinates, pictures/video, and audio.
• All Droid Hunt data on droids is to be stored on SD cards in order to maintain data liquidity (for convenience of interchangeability).

Iteration To-Do List

We will be trying to get as much as we can in the next iteration, but a rough ordering of what we will be tackling can be seen below:

• Hunts and the ability to create/edit new/existing hunts
• Ability to create clues
• Ability to store clues.
• Server Class to allow FTP
• Player Class
• Syncing the Player Login Credentials with the FTP Server
• Allow users to register
• GUI to support the features above and allow testing
• Server Hierarchy for storing hunts and clues

GUI Sketches:

Architecture:

Phone

• The GUI:

The GUI component will deal with all of the visual aspects and application screens that the user will see. These will include the login screen, the main screen, screens that allow the user to join a scavenger hunt, search for clues, etc. The rules for the GUI will be stored locally on their Android Devices when the application is installed.

• The Game Logic:

This component will implement the game logic including scavenger hunts, clues, etc. Each scavenger hunt will have clues, the users that are participating in it and the user who created it. It will include the functionality of adding new scavenger hunts and clues and solving clues. The hunts and clues will be initially stored on the website, but when users try to join and complete a given hunt, the hunt will be downloaded onto their phones and stored locally.

Server/Database

• Hunts/Clues:

The clues and scavenger hunt data will be stored online. When a user creates a scavenger hunt or a clue, it will be uploaded to the website. Users can then choose to download hunts from the server onto their phones when they opt to do one. The website will include a folder hierarchy to store the user data, scavenger hunt data, what users are participating, the clue data, and possibly which clues have been found by which users.

Use Cases

Actors: Master, Player

Master use-cases:

Master creates new scavenger hunt:

1. User presses “Create New Hunt” button from the main screen.

2. User is sent to the Create New Hunt screen.

3. User specifies the name and type (e.g. public, invite-only) of hunt in provided fields.

3.1. User presses the “Back” button.

3.1.1. User is sent back to the main screen.

4. User is sent to the add new clue screen to add clues to the new hunt.

4.1. Name or type of hunt is invalid, which leads to an error message and a prompt to re-enter hunt data.

5. The first clue is added with a confirmation message.*

6. User is asked if they would like to enter more clues for their hunt.

6.1. If they do, user is sent to the edit hunt screen for that hunt to add more clues.

6.2. If not, user is sent back to main screen.

7. Hunt is added to database when user returns to main screen.

*Steps 5-7 imply that every hunt must have at least one clue in order to be created.

Master adds clue to a hunt:

1. User presses “Add New Clue” button (from either the create hunt screen or the edit hunt screen).

2. User is sent to the Create Clue screen.

3. User specifies the destination, sequence order, type (e.g. text, audio, video), etc. of the new clue and enters type-sensitive data relevant to the clue into (e.g. clue text, file location of video/audio file) into provided fields.

3.1. User presses the “Cancel” button.

3.1.1. User is sent back to their last screen (either the main screen or edit hunt screen).

4. User presses “Upload Clue” to add the clue.

5. Upload data is valid and clue is added to the hunt’s clue list along with a confirmation message.

5.1. Clue data is invalid (e.g. file location does not exist), leading to an error message and a prompt to reenter clue data.

6. User is asked if they would like to enter more clues for their hunt.

6.1. If they do, user is sent to another add new clue screen.

6.2. If not, user is sent back to their last screen (either the main screen or edit hunt screen).

Master edits a hunt:

1. User presses “Edit Hunt” button from main screen.

2. User is sent to the ‘select hunt to edit’ screen.

3. On the ‘select hunt to edit’ screen, the user clicks on a hunt from a list of hunts to edit it (a security question/password may be requested).

3.1. User presses the “Cancel” button.

3.2. User is sent back to the main screen.

4. User is sent to an edit hunt screen where they can change the name/type of the hunt in the provided fields.

4.1. User clicks on a clue from the clue list.

4.1.1. User is sent to the edit clue screen for that clue.

4.2. User presses “Add new Clue”.

4.2.1. User is sent to the add new clue screen.

5. User presses the “Done” button to save the hunt and its changes if any.

6. User is sent to the ‘select hunt to edit’ screen.

6.1. New Hunt data is somehow invalid, leading to an error message and a prompt to reenter hunt data.

Master edits a clue:

1. User clicks on a clue from the clue list of a hunt in the edit hunt screen.

2. User is sent to the edit clue screen for that clue.

3. On the edit clue screen, the user can alter clue data in the provided fields.

4. User presses “Change Clue” to save any changes.

4.2. User presses the “Cancel” button.

4.2.1. User returns to the edit hunt screen and any changes made are undone.

5. User is sent back to the edit hunt screen.

5.1. Clue data is invalid (e.g. file location does not exist), leading to an error message and a prompt to reenter clue data.

Master deletes a clue:

1. User clicks on a clue from the clue list of a hunt in the edit hunt screen.

2. User is sent to the edit clue screen.

3. On the edit clue screen, the user presses the “Delete” button.

4. A confirmation dialog asks the user to confirm the deletion.

4.1. If user confirms, the clue will be deleted from that hunt.

4.1.1. The user is sent back to the edit hunt screen.

4.2. If user aborts, the user is sent back to the edit clue screen.

Master searches for hunt to edit:

1. On the ‘select hunt to edit’ screen, the user presses the “Search for a Hunt” button.

2. User is sent to the search hunts screen.

3. On the search hunts screen, the user enters search terms (e.g. names, clues, etc.) into the provided fields.

4. User presses “Search” to initiate the search.

4.1. The user presses the “Cancel” button.

4.1.1. User is sent back to the ‘select hunt to edit’ screen.

5. User is sent to the search results screen.

6. On the search results screen, a list of hunts that match the search terms will appear for the user to select.

7. The user selects a hunt by clicking on it.

7.1. The user presses the “Back” button.

7.1.1. User is sent back to the ‘select hunt to edit’ screen.

8. The user is sent to the edit hunt screen for that hunt.

Master searches for a clue:

1. On the edit hunt screen, the user presses the “Search for a Clue” button.

2. User is sent to the search clues screen.

3. On the search clues screen, the user enters search terms (e.g. names, order number, etc.) into the provided fields.

4. User presses “Search” to initiate the search.

4.1. The user presses the “Cancel” button.

4.1.1. User is sent back to the edit hunt screen.

5. User is sent to the search results screen.

6. On the search results screen, a list of clues that match the search terms will appear for the user to select.

7. The user selects a clue by clicking it.

7.1. The user presses the “Back” button.

7.1.1. User is sent back to the edit hunt screen.

8. The user is sent to the edit clue screen for that clue.

Player use-cases:

Player logs in:

1. User opens the Droid Hunt app on their Droid.

2. User is sent to the login screen.

3. User logs in by entering his/her username and password in the provided fields.

4. User presses “Login”.

5. User is sent to the main screen.

5.1. User enters incorrect credentials, leading to an error message and a prompt to re-enter credentials.

5.2. User does not have a username/password, so they must register on the server.

Player registers on the server:

1. User presses Create New User button on the login screen.

2. User is sent to the create new user screen.

3. User enters a desired username, password, and password confirmation in the provided fields.

4. User presses the “Submit” button.

4.1. User presses the “Cancel” button.

4.1.1. User is sent to the login screen.

5. User enters valid credentials, and a new account is made with those credentials, with a confirmation message shown.

5.1. User’s desired credentials are invalid or are taken by other accounts.

5.1.1. User is sent back to the create new user screen with an error message and a prompt to re-enter different credentials.

6. User is sent back to login screen.

Player downloads hunt:

1. User presses “Download Hunt” button on the main screen.

2. User is sent to the download hunt screen.

3. User chooses a hunt to download by clicking on it from the online list of hunts.

3.1. User presses the “Cancel” button.

3.1.1. User is sent back to the main screen.

4. The user is asked to confirm if they wish to download that hunt.

4.1. If so, the hunt is sent to the user’s Droid.

4.1.1. Hunt is successfully sent and added to the user’s list of hunts.

4.1.1.1. User is sent back to the download hunt screen along with a confirmation message.

4.1.2. User cannot download hunt due to connection or privacy issues.

4.1.2.1. User is sent back to the download hunt screen along with a detailed error message.

4.2. If not, the user is sent back to the download hunt screen.

Player joins a hunt:

1. User presses the “Join Hunt” button from the main screen.

2. User is sent to the join hunt screen.

3. User selects a hunt by clicking on it from the list of hunts that the player has downloaded.

3.1. User presses the “Cancel” button.

3.1.1. User is sent back to the main screen.

4. User presses “Join Hunt”.

5. User is added to that hunt’s list of participants and sent to a hunt progress screen where they can play the hunt.

5.1. User cannot join hunt due to connection or privacy issues.

5.1.1. User is sent back to the join hunt screen along with a detailed error message.

Player searches for a hunt:

1. On the download hunt screen, the user presses the “Search for a Hunt” button.

2. User is sent to the search hunts screen.

3. On the search hunts screen, the user enters search terms (e.g. names, clues, etc.) into the provided fields.

4. User presses “Search” to initiate the search.

4.1. The user presses the “Cancel” button.

4.1.1. User is sent back to the download hunt screen.

5. User is sent to the search results screen.

6. On the search results screen, a list of hunts that match the search terms will appear for the user to select.

7. The user selects a hunt by clicking on it.

7.1. The user presses the “Back” button.

7.1.1. User is sent back to the download hunt screen.

8. The user is asked to confirm if they wish to download that hunt.

8.1. If so, the hunt is sent to the user’s Droid.

8.1.1. Hunt is successfully sent and added to the user’s list of hunts.

8.1.1.1. User is sent back to the search results screen along with a confirmation message.

8.1.2. User cannot download hunt due to connection or privacy issues.

8.1.2.1. User is sent back to the search results screen along with a detailed error message.

8.2. If not, the user is sent back to the search results screen.

Player searches for a clue:

1. On the hunt progress screen, the user presses the “Search for a Clue” button.

2. User is sent to the search clues screen.

3. On the search clues screen, the user enters search terms (e.g. names, order number, etc.) into the provided fields.

4. User presses “Search” to initiate the search.

4.1. The user presses the “Cancel” button.

4.1.1. User is sent back to the edit hunt screen.

5. User is sent to the search results screen.

6. On the search results screen, a list of clues that match the search terms will appear for the user to select.

7. The user selects a clue by clicking it.

7.1. The user presses the “Back” button.

7.1.1. User is sent back to the hunt progress screen.

8. The user is sent to the clue details screen for that clue.

9. The user presses the “Back” button on the clue details screen.

10. The user is sent back to the hunt progress screen.

Player deletes a hunt:

1. User presses “Join Hunt” button on the main screen.

2. User is sent to the join hunt screen.

3. User selects a hunt to delete by clicking on it from the list of hunts that the player has downloaded.

4. User presses the “Delete Hunt” button.

5. A confirmation dialog asks the user to confirm the deletion.

5.1. If they confirm, the hunt will be deleted from the list.

5.1.1. The user is sent back to the join hunt screen.

5.2. If they abort, the user is sent back to the join hunt screen.

Player progresses to next step in hunt:

1. User reaches destination point specified by a clue in hunt.

2. User receives a notification message on the hunt progress screen.

3. The hunt progress screen displays a new clue.

4. Other participants may be notified (depending on settings) of the player’s progression.

Player finishes hunt:

1. User reaches destination point specified by last clue in hunt.

2. User receives a congratulation message on the hunt progress screen.

3. Other participants in the hunt are notified of the user’s completion.

4. User is asked if they wish to participate in another hunt.

4.1. If they would, the user is sent to the join hunt screen.

4.2. If they don’t, the user is sent to the main screen.

Player leaves hunt:

1. User presses the “Leave Hunt” button on the hunt progress screen.

2. User is asked to confirm.

2.1. If they do, the user is sent to the main screen.

2.2. If they don’t, the GUI reverts to the hunt progress screen.

Player exits app:

1. User presses the “Exit Droid Hunt” button on the main screen.

2. User is asked to confirm.

a. If they do, the app closes.

b. If they don’t, the GUI reverts to the main screen.

Domain Model

Droid Hunt allows for players to participate in user created scavenger hunts on his/her Android phone. These hunts are files that are stored on a server. A user downloads entire hunts from the server, allowing the phone to implement the game. Each hunt consists of one or more clues. Each clue in the hunt leads the player the next clue. The solution to each clue can be either a location (to be checked by GPS) or some specific text answer that the clue will ask for. Once a clue is solved, the next clue will become available until all the clues have been solved. At that point, the hunt ends and the time taken to complete the hunt is calculated.

Each player also has the ability to create hunts. This is done by creating a set of clues of various types. A clue can be an image, video, audio recording, or text that describes the solution of the clue. Each clue has a solution that can be either a GPS coordinate for the user to check or a text answer to some question in the clue. When hunt creation is completed, the creator can then upload hunt files to the server for storage and distribution.

Each user is required to create an account and login to upload and download hunts. Each user is allocated a directory on the server to store all of that user’s created hunts. When downloading, users are presented a list of hunts from the server to choose from.

UML Sequence Diagram:

Activity Model:

Proposed Classes:

Player JavaDoc

Server JavaDoc

Clue JavaDoc

ContinueHuntGUI JavaDoc

CreateClueGUI JavaDoc

CreateHuntGUI JavaDoc

CreateNewUserGUI JavaDoc

CreateNewUserLogic JavaDoc

EditHuntGUI JavaDoc

FirstScreenGUI JavaDoc

FirstScreenLogic JavaDoc

MainScreen JavaDoc

HuntLogic JavaDoc

HuntGUI JavaDoc

UML Class Diagram:

Resources:

• Eclipse IDE
• Android SDK
• SVN Plugin

• import java.io.BufferedOutputStream;
• import java.io.BufferedReader;
• import java.io.File;
• import java.io.FileInputStream;
• import java.io.FileNotFoundException;
• import java.io.FileOutputStream;
• import java.io.FileReader;
• import java.io.IOException;
• import java.io.InputStreamReader;
• import java.io.PrintWriter;
• import java.net.ServerSocket;
• import java.net.Socket;
• import java.util.Arrays;
• import java.util.Scanner;
• import org.apache.commons.*;//for ftp functionality
• import android.app.Activity;
• import android.app.AlertDialog;
• import android.content.DialogInterface;
• import android.content.Intent;
• import android.net.Uri;
• import android.os.Bundle;
• import android.os.Environment;
• import android.os.StatFs;
• import android.util.Log;
• import android.view.ContextMenu;
• import android.view.Menu;
• import android.view.MenuItem;
• import android.view.View;
• import android.view.ContextMenu.ContextMenuInfo;
• import android.widget.AdapterView;
• import android.widget.ArrayAdapter;
• import android.widget.ListView;
• import android.widget.TextView;
• import android.widget.Toast;
• import android.hardware.*;
• import android.location.*;
• import android.media.*;
• import android.net.*;
• import android.net.http.*;
• import android.net.wifi.*;

Iteration 1

Group 4′s OOSE Project: Droid Hunt.

The team consists of: Kirk Sabnani, Serena Jeblee, Siren Wei, Sam Hu, Tony Zhang

Vision Statement:
Our app allows a person to create a virtual scavenger hunt and then share that hunt with other droid users in order to create a multiplayer game where players share clues in order to lead other players to real-world locations. We will make use of the droid’s various sensors and features for this game, including the GPS, compass, light sensor, picture/video sharing, and audio recorder.

Features/requirements:

• Players should have the ability to create their own scavenger hunts complete with lists of hints and clues.
• Players should be able to share their scavenger hunt game with other droid users via an online repository, along with data pertinent to the progress of the game such as clues and objective completion.
• The game GUI should allow players to create, edit, join/download, continue/open, and quit hunts.
• Players will need to set up a game account complete with username and password in the app to play. This will allow for player accountability and create a user infrastructure.
• The ability of a phone to use different sensors to detect a clue should be included as a gameplay mechanic.
• The clues should vary widely in order to maximize use of the multiple sensor abilities on the droids. Examples of clues include text, GPS coordinates, pictures/video, and audio.
• All data should be stored on SD cards in order to maintain data liquidity.

Use Cases:

Actors: Master, Player

Master use-case:

Login screen:

1. User logs in using his/her username and password.
2. User does not have a username/password, so they must press the “create new user” button to proceed to the Create new user screen and register new credentials.
3. User presses “cancel” and is returned to the login screen.
4. User enters username, password, and password confirmation and presses “submit”.
5. User is returned to Login screen and logs in as a registered user, going to the main screen.

Main screen:

1. User presses “create new hunt”.
2. User clicks “edit hunt” and then selects the name of the scavenger hunt from a list.
3. User adds clues to their hunt by clicking “add clue”.
4. User chooses the type of clue and creates or uploads the clue data.
5. User clicks “submit”.

Player use-case:

Login Screen:

1. User logs in using his/her username and password.
2. User does not have a username/password, so they must press the “create new user” button to proceed to the Create new user screen and register new credentials.
3. User presses “cancel” and is returned to the login screen.
4. User enters username, password, and password confirmation and presses “submit”.
5. User is returned to Login screen and logs in as a registered user, going to the main screen.

Main Screen:

1. User clicks “continue hunt” and then selects the name from a list,
2. User clicks join hunt and selects the name from a list.
3. User is added to that hunt and can view the first clue.
4. User can view current clues. User then clicks search for clues.
5. User clicks on a clue and then clicks pass clue.
6. User chooses another user to pass the clue to.
7. User chooses the type of clue to search for (i.e. gps, text).

Proposed Packages:

Gui

- This package would contain all of the GUI components such as screens, menus, buttons, etc. The buttons and menus would call methods from the Game Logic.

Game Logic

- This package would implement all of the logic for the scavenger hunt. It would include the main functionality that would the players to create and edit scavenger, as well as the clue structure. It will allow for different types of clues and different actions depending on the type of clue.

Classes:

• ScavengerHunt
• Clue
• GpsClue, TextClue, etc.

Player

- This package would contain all of the player logic, their login info, their current scavenger hunts, their status in the game, etc.

Classes:

• Player
• Supporting classes

Gui Sketches:

Activity Model:

Resources:

• import java.io.BufferedOutputStream;
• import java.io.BufferedReader;
• import java.io.File;
• import java.io.FileInputStream;
• import java.io.FileNotFoundException;
• import java.io.FileOutputStream;
• import java.io.FileReader;
• import java.io.IOException;
• import java.io.InputStreamReader;
• import java.io.PrintWriter;
• import java.net.ServerSocket;
• import java.net.Socket;
• import java.util.Arrays;
• import java.util.Scanner;
• import org.apache.commons.*;//for ftp functionality
• import android.app.Activity;
• import android.app.AlertDialog;
• import android.content.DialogInterface;
• import android.content.Intent;
• import android.net.Uri;
• import android.os.Bundle;
• import android.os.Environment;
• import android.os.StatFs;
• import android.util.Log;
• import android.view.ContextMenu;
• import android.view.Menu;
• import android.view.MenuItem;
• import android.view.View;
• import android.view.ContextMenu.ContextMenuInfo;
• import android.widget.AdapterView;
• import android.widget.ArrayAdapter;
• import android.widget.ListView;
• import android.widget.TextView;
• import android.widget.Toast;
• import android.hardware.*;
• import android.location.*;
• import android.media.*;
• import android.net.*;
• import android.net.http.*;
• import android.net.wifi.*;