CSE333 16au -- Homework #6

Out: Monday February 27, 2017
Due: Friday March 10, 2017, 11:59 PM.
Teams: Two person teams are required.

In this final piece of the project we adapt the model component of HW5 so that it chooses the next move to be made. Your model contacts a server to obtain a game to be played. The server then periodically contacts your model component to ask for its next move, which must be supplied promptly. Because finding a good move in limited real time is a constraint, your search for moves should be multi-threaded.

  • The objective of the game is to bring "the state" of each board cell to zero in the fewest possible moves. (The state is the number of remaining firings of a square that will give the player a point. So, the goal is to achieve the maximum possible score in the few possible moves.)

  • You will be asked for moves no faster than once per second and no slower than once per minute.

  • If the server does not receive your move within about 1 second from the time the server sends the request for it, you will be disqualified.
The HW6 protocol is similar to the one used in HW5. The main changes are
  • Every message sent from the model to the server carries a teamname field. teamname must be a string. It's intended to be distinct from the teamnames of all other groups using the same server.

  • The move and update messages are no longer used.

  • The initial sequence is a model-server hello message and an helloack response. There is no third message.

  • After that, communication starts with the server. Most often, it sends a requestmove message. requestmove messages contain only an action field.

  • The client should respond promptly with a mymove message. At the highest level, a mymove looks like:
           { "action" : "mymove",
             "teamname" : "our team",
             "gameinstance" : { ...},
             "move" : {... },
             "movesevaluated" : 1234

    The move field looks like:

           "move": { "row" : 3, "column":5, "direction": 0 }
    (The directions are 0 though 3 for left, right, down, and up respectively.) The movesevaluated field is an integer indicating how many moves were examined in deciding on the move being provided.

  • The server sends a bye message when it terminates. The model should not send a bye.
There are two servers running on attu4, one at port 33306 and one at 33310. The former supplies the classic test6by6.json model, and the latter a newly created 10x10 model.

You can view a list of best scores on each game by each team (that has connected to the servers) at this page. (All your game results are recorded, but only the best result on each game for each team is shown.)

Q: How do I find a good move?
A: That's entirely up to you.

Q: What happens if I return a move that isn't legal?
A: You should expect to be disqualified.

Q: What happens if I don't respond quickly enough?
A: You should expect to be disqualified.

Q: If I'm disqualified, how can I know why?
A: In some instances the server will return an error message field in the bye message, so dump that message.

We provide a copy of the game server executable (built on attu): hw6-server.

  • You should submit your code and any other files required to build and run it. We're anticipating that you'll follow the directory structure of past distributions. If you do something else, you should make that clear in your pdf document.
  • Your code should build with the command make.
  • After building it, it must be possible to invoke your application with the command ./hw6-model hostname port
  • You should submit a pdf document. Put the names and login names of both members of your team at the top of the pdf document. In the body, tell us anything we might need to know to build and run your code.
  • Submit everything to the course dropbox.
  • We're expecting you to make extensive reuse of code from projects 2 through 5. If you don't, you should explain why not in your pdf file.