Problem 1: Monty Hall Server API (100 points)
The final two assignments for the semester have you implement a client-server AJAX based web application to play the Monty Hall game. If you're not familiar with this problem, or want a deeper dive into it, see the WikiPedia article for it: https://en.wikipedia.org/wiki/Monty_Hall_problem.
The basics of the game work like this:
- The Player is presented with 3 closed doors. There is a prize behind one of the doors.
- The Player first selects one door, but does not open it.
- The Host then opens one of the doors the Player did not choose. The Host will always open a door with no prize behind it.
- The Player is then given a final choice: stick with the original door the player selected, or switch their choice to the other door that the Host did not open.
- Finally the Host reveals the door containing the prize, and the Player either wins or looses.
For this assignment you will create the server back-end API for the game. The server is responsible for setting up new games, storing game state in a MySQL database, and communicating results to the client.
Minimum Requirements
You will have to implement the four API functions described in the API Documentation.
Database
You are provided with a SQL file in the files folder which contains the table definition to use for this assignment. You will need to create a new MySQL database, and import this table definition into your newly created database. All data for the game will be stored and retrieved from this single table.
JSON Output
All commands in the API return data not as HTML, but as JSON. You will need to use PHP's header functionality to set the mime type of the return data stream to JSON, in order for clients to properly interpret the data. The response data structure will be mostly the same for valid results, with a different structure for errors. All responses must have either a 'message' value or an 'error' value. Valid responses should also include a 'data' value with the data appropriate to that API command.
newGame Command
The newGame command is responsible for creating a new game entry in the database, and returning a game data structure to the client. The server picks a random door as the prize door, and stores this in the database in order to get a new Game ID. The server returns a data structure as demonstrated in the API Documentation.
There shouldn't be any potential error states to handle with newGame.
stats Command
The stats command is responsible for returning the number of current wins and losses broken down by if the player switched their door for the final choice, or stuck with their initial door. You will need to figure out how to query the database to find each of the four possible combinations:
- Player did not switch their choice between firstChoice and finalChoice, and the Player Won.
- Player did not switch their choice between firstChoice and finalChoice, and the Player Lost.
- Player DID switch their choice, and the Player Won.
- Player DID switch their choice, and the Player Lost.
The server returns a data structure as demonstrated in the API Documentation.
There shouldn't be any potential error states to handle with the stats command.
firstChoice Command
The firstChoice command takes two arguments from the user in addition to the command name. You need a Game ID and a Choice. The choice should be recorded in the database for the given Game ID. Once the player's choice has been recorded, the server must return a data response containing the incorrect door to open. The server must always return a door that does not hide the prize behind it. The server returns a data structure as demonstrated in the API Documentation.
There are several potential error cases the server needs to handle as demonstrated in the API Documentation. Your implementation must implement the error cases identified in the documentation. You are free to implement additional error handling if you see an opportunity.
finalChoice Command
The finalChoice command takes two arguments from the user in addition to the command name. You need a Game ID and a Choice. The player's final choice should be recorded in the database. The server should then determine if the player won or lost the game, and return an appropriate message. This is the only command where the prize_door is returned, showing the player where the prize was all the time. The data returned is the same if they win or loose, the only difference is the message string.
There are several potential error cases the server needs to handle as demonstrated in the API Documentation. Your implementation must implement the error cases identified in the documentation. You are free to implement additional error handling if you see an opportunity.