Mobile Application Programming: Android CS4530 Fall 2016 Project 4 - Networked Battleship Due: 11:59PM Monday, Nov 7th Abstract Extend your Model-View-Controller implementation of the game Battleship on Android to use an Internet-connected server, allowing two players to play against one another on separate Android devices. The application will host a list of games that are in progress or have finished, as well as a user interface to play a game. As before, the game itself involves two grids positioned over locations in the ocean. One grid belongs to the player while the other belongs to his enemy. Each grid contains 5 ships that can be positioned in a row or column of the grid and have lengths of 2, 3, 3, 4, and 5 units. Players take turns launching missiles into individual grid locations in their enemy s grid with the goal of sinking the opponent s ships. When a missile is launched, the player is told wether the missile hit or missed. Some variations of the game also say on a hit if the ship was sunk, meaning that all of the locations the ship occupies have been hit, but our variation will not give that distinction. While both grids will contain hits and misses, each player may only see ships that are in their own grid. The game is won when all locations that the enemy s ships cover have been hit. See http://en.wikipedia.org/wiki/battleship_(game)#description for more information. The game will be modified to be multiplayer over the network, and communicate with a server using a RESTful API. All game information and logic will be hosted on the server. Remove the screen asking the player to pass the device to their opponent. Instead, present UI showing the user who s turn it is, polling the server every 500ms to update that state. Do not allow the user to launch missiles when it is not their turn. Allow the user to return to the game list screen to start additional games while they wait. Components Networked Battleship has all the gameplay requirements of project 3 not replaced by features below. Data Model should be modified to communicate with a server at http://battleship.pixio.com API specification is below. Must be capable of handling JSON data. Ship placement and most game logic will now be handled by the server. Games will be saved on the server, made available in a lobby, which replaces the local game file used previously. Game and player IDs need to be saved, however, to access inprogress games. Lobby List View now contains all requested games found on the server with a specified status (WAITING, PLAYING, DONE), selectable using an appropriate control. The new game control should still be shown. Rows representing games should now show at least the game name and status. Include other statistics about games where available. Tapping the new game control adds a game to the server by creating a new game, first collecting the game and player name with appropriate UI. Then the game UI is presented to play the game. Selecting a game in WAITING mode joins the game, first collecting the player name with appropriate UI. Then the game UI is presented to play the game.
Selecting a game in the PLAYING or DONE modes shows a simple game summary, unless the game was started previously on the device (it will have saved the game & player ID). In that case, open the game UI and continue the game. Multi-Game Functionality - Allow the user to be in several active games at the same time. Be sure to poll the server every 500ms for each active game to determine who s turn it is. Display this in the game list screen as well as in-game. Game View should be the same as in project 3. If you built project 3 using MVC, very little should need to be changed in your game view. Extra Credit My Games 5% - Extra credit for adding a 4th lobby option for all games played on the device. The server does not offer this search, so you will have to piece it together using server information and game / player IDs saved from games as they are played. This allows the user to see all games in all statuses that they are involved in. Extra credit will also be given for substantially improved UIs. Handin You should hand in a zip file containing your project. To do this, zip the folder by right-clicking it and selecting Compress, then handing it in using web handin or the handin command line tool. Hand this zip into: handin cs4530 project4 your_zip_file.zip
Battleship Server API A very simple REST api for the CS4530 Android Battleship MVC assignment. All request and responses are in JSON and follow JSON guidelines. " " represent a dictionary of Key:Value pairs (can also be thought of as an object, where keys are class variables), and "[ ]" represent an array. RESTful API's use HTTP verbs to determine the type of operation to execute. The standard verbs and standard uses are as follows: GET - used to query for information from the server. Query parameters can be used to filter the requested data. POST - Asks the server to create a new resource. PUT - Requests for a change or update to a resource. DELETE - Remove a resouce. NOTE: Only POST and PUT verbs can have a request body. The board is a 10x10 grid with rows and columns ranging from [0-9]. Response will use standard HTTP status codes. 200 - Request handled successfully 4xx - User request was not handled because the user request is malformed, missing parameters, or attempting to access a resource that is not allowed. 5xx - Server error. Please tell me what you did to receive this error. In the case of a 4xx or 5xx error, check the message property in the top level of the JSON response. Game Lobby Get list of games Gets a list of games from the lobby. Query parameters may be used to filter the result set. For example, querying for completed or in progress games Request: GET /api/v2/lobby Valid Query Params:
status - an string enum. Represents the status of the game. Acts as a filter. results - an integer. The number of results per result set. offset - an interger. The offset position to begin the result set. Zero based. NOTE: If results is defined, so must offset and vice-versa. Defining one without the other will simply be ignored. [ ],... "id": GUID, "name": STRING "status" ENUM id - The GUID of the game. This id is globally unique and can be used to find/update/delete this particular game. name - The user readable name of this game. status ENUM: DONE, WAITING, PLAYING DONE: Game has finished. No more actions are allowed WAITING: Game needs a second player. Allowed to join PLAYING: Game is currently in progress. Cannot join. NOTE: Providing no query parameters will return all games in the database. This may overwhelm the memory of your device. USE WITH CAUTION. Get game detail Get details for the game with the provided id. Request: GET /api/v2/lobby/:id :id - The GUID of the game you are searching for.
"id": GUID, "name": STRING, "player1": STRING, "player2": STRING, "winner": STRING, "status": ENUM, "missileslaunched": INT id - The GUID of the game. This id is globally unique and can be used to find/update/delete this particular game. name - The user readable name of this game. player1 - The name of player 1. player2 - The name of player 2, if a second player has joined the game. winner - The name of the winning player. Otherwise, IN_PROGRESS. status ENUM: DONE, WAITING, PLAYING DONE: Game has finished. No more actions are allowed WAITING: Game needs a second player. Allowed to join PLAYING: Game is currently in progress. Cannot join. missleslaunched - An integer representing the number of turns currently taken in the game. Create a new Game Create a new game with the provided name. Game will be in a WAITING status until another player joins the game. Once a player joins, the status will change to PLAYING. The player who created the game will become player 1 and will be provided a GUID to identify the player. Request: POST /api/v2/lobby "gamename": STRING, "playername": STRING gamename - The user readable name for the game being created.
playername - The user readable name of player 1 (the creator). "playerid": GUID, "gameid": GUID IT. playerid - A GUID used to identify player1. Will be used in future requests to manipulate this game. SAVE gameid A GUID used to identify this game. Will be needed in future requests to manipulate this game. SAVE IT. Join the game with the given id Join the game with the provided id. Request: PUT /api/v2/lobby/:id :id - The GUID of the game you would like to query. "playername": STRING, "id": GUID playername - The user readable name of player2. id - The GUID of the game this player would like to join. "playerid": GUID IT. playerid - A GUID used to identify player2. Will be used in future requests to manipulate this game. SAVE
In Game Making a guess Make a guess to try and hit a ship. Request: POST /api/v2/games/:id :id - The GUID of the game you would like to query. "playerid": GUID, "xpos": INT, "ypos": INT id - The GUID of the game you would like to manupulate. playerid - The GUID of the player making the move. xpos - The x position of your guess. ypos - The y position of you guess. "hit": BOOLEAN "shipsunk": INT hit - True if this guess was a hit. False otherwise. shipsunk - Correspondes to the size of the ship sunk. 0 if no ship was sunk. Whose turn is it Use to poll the server and determine the players turn. Can be used when waiting for an opponent player to join the game, i.e. will return false for player 1 on a new game until an opponent player has joined. If the game is in progress, winner will be IN PROGRESS. If the game is over, winner will contain the name of the player who won the game.
Request: GET /api/v2/games/:id :id - The GUID of the game you would like to query. Valid Query Parameters playerid - The GUID of the player making the request. The player must belong to this game, otherwise the request will fail. "isyourturn": BOOLEAN, "winner" : STRING isyourturn - True if it is currently this players turn. False, otherwise. winner - The name of the player who won the game. Otherwise, IN_PROGRESS. Get Player Boards Will return the status of the player's entire board for the game with the given id. The board is represented as a list of cells. playerboard represents the players own board (ships and all), while the opponentboard shows the current players hits and misses against the opponent. Both playerboard and opponentboard are represented as an array of cells with a cell containing its own state as: x position, y position, and status. Request: GET /api/v2/games/:id/boards :id - The GUID of the game you would like to query. Valid Query Parameters playerid - The GUID of the player making the request. The player must belong to this game, otherwise the request will fail.
"playerboard": [ "xpos": INT, "ypos": INT, "status": ENUM,... ], "opponentboard": [ "xpos": INT, "ypos": INT, "status": ENUM,... ] xpos - The x position of this cell. ypos - The y position of this cell. status ENUM: HIT, MISS, NONE HIT: a player has hit this cell MISS: a player has missed this cell SHIP: this cell is part of a ship and has not been hit NONE: this cell has no activity Game AI The server also comes with its own battleship AI and functions as follows: The bot server polls every 30 seconds for games. If a game is named with the correct name, it will join automatically with the specified AI. Valid Game Names: RANDOMBOT - Completely random. SPIRALBOT - Begins at the center and spiral out. SMARTBOT - Attempts to intelligently destroy your ships.
If you create a game with the name RANDOMBOT, the bot server will create a bot with the random AI and play against you. The bot will continue to play against you until a winner has been declared. While the game is in progress, the bot will poll for your game with exponential backoff up to 1 minute. The bot will abandon games if there is no activity for 6 hours.