Assignment 7 – Advanced Variant

Due Wednesday 5/11 5:00pm for the testing deliverables and Friday 5/13 11:59pm for the code deliverables

For this assignment you will generalize the code you have written earlier in the quarter to handle the advanced rules rules, at the end of the complete rulebook – note that this is not the same document as in assignment 3; this one has a few more pages than that one. Also you are not required to support the expert rules, just the advanced variant.

One subtle point that isn’t especially clear in the rulebook: playing a roundabout comes with two estate fences for free—you don’t need to use the surveyor effect. See also some end game clarifications of how roundabouts work.

The first step is to think carefully about your player and game state data structures and how they should change. Once you have a game plan for that, continue with the rest of the assignment.

1 Generalizing Player State JSON

The JSON spec for the player state changes only by the addition of "roundabout" in the house nonterminal. Here’s the complete, new grammar:

Note that if a roundabout appears, the corresponding fences must also appear explicitly in the JSON in order for the JSON to be well formed.

Testing Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.1/” and put at least ten input files that each have a single player state JSON object. The JSON object should either be a well-formed JSON object according to the new rules or not. If the file contains a correct input, the corresponding output file should be the same JSON object. If the file contains an incorrect input, the output file should contain only false.

You will receive up to ten points for your tests, two points for each valid pair of input and output files that do not duplicate existing tests.

Code Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.1/” and deposit there a Makefile for your test driver. It should accept a JSON value on stdin and it should convert it into your new internal representation for the player state. If this is possible, it should convert the internal representation back into JSON and print it out. If the JSON does not correspond to a valid game state, it should instead print false.

You will receive up to 50 points for your code.

2 Generalizing Game State JSON

The JSON spec for the game state changes by adding new criteria to the city plan cards. Here’s the revised grammar:

The new city plan criteria are allowed only on certain cards. While the list of numbers may appear on a card in any position, the criteria appearing in the criteria-card-1 non-terminal can appear only on a card with position 1 and the criteria appearing in the criteria-card-2 non-terminal can appear only on a card with position 2.

The numbers that identify rows start from 0, so either the first or third row must be completed filled in criteria 1 and either the second or third row must have all pools and all parks in criteria 2.

Although there are specific scores associated with each card (and thus each criteria) in the official game, we allow any (natural number) scores on city plan cards, not just those that are in the official game.

Testing Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.2/” and put at least ten input files that each have a single game state JSON object. The JSON object should either be a well-formed JSON object according to the new rules or not. If the file contains a correct input, the corresponding output file should be the same JSON object. If the file contains an incorrect input, the output file should contain only false.

You will receive up to ten points for your tests, two points for each valid pair of input and output files that do not duplicate existing tests.

Code Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.2/” and deposit there a Makefile for your test driver. It should accept a JSON value on stdin and it should convert it into your internal representation for the game state. If this is possible, it should convert the internal representation back into JSON and print it out. If the JSON does not correspond to a valid game state, it should instead print false.

You will receive up to 50 points for your code.

3 Generalizing Move Validity

Determining if a move is valid now needs to take into account roundabouts and the new criteria for city plan completion. Adjust your implementation.

Testing Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.3/” and put at least ten input files that each have a single JSON list containing three JSON objects: the game state, followed by the initial player state, and then the final player state. Create ten output files that each have either true or false, depending if the move represented by the corresponding input file contains a valid move or not, according to the advanced rules.

You will receive up to twenty points for your tests, two points for each valid pair of input and output files that do not duplicate existing tests.

Code Deliverables: In your team’s GitHub repository, create a directory “Deliverables/7/7.3/” and deposit there a Makefile for your test driver. It should accept a single JSON object on stdin that is a list containing the game state, followed by the initial player state, and then the final player state. It should print either true or false to indicate if the move was legal or not.

You will receive up to 50 points for your code.