►Software Development
▼Projects, Specifics
•7 — Implementing the Player Interface and the Rule Checker
7.1.0.8
    ← prev  up  next → 

7 — Implementing the Player Interface and the Rule Checker

Due Monday, October 08, midnight

Delivery For this assignment, you will still place the design documents into the Design/ folder and Santorini-specific code into Common. The xrules goes into a 7/ directory, while the test go into 7/rules-tests.

Design Task The player itself is just a mechanism that hooks into the game framework and enables some other "actor" to engage. This actor could be a person, a remote component (as one pair already showed during a design review), and a strategy. For next week, design an interface between the player and a strategy object.

Ask yourself what a strategy object needs to know in order to plan the next action for a player.

You may also wish to contemplate what kind of strategies a player should pursue. This course is not about AI strategies, which is a subject that requires its own separate course(s). You may look into αβ minimax and other such idea on wikipedia. We will probably run a tournament for AI players after the grades have been settled (though we may off extra points).

Implementation Task Implement the data representation of the player interface:

  • your player will need a representation of where workers have been placed so far and a representation for how the player picks the location for the next worker.

  • when it is a player's turn, the referee must inform the player of the current state of the game; in turn, the player must inform the referee of the action to be taken.

This task may mean nothing else but a rigorous data definition in some languages and a full-fledged interface or class layout in others.

Implement a rule checker that decides whether a player’s requested action conforms to the Santorini rules with respect to the current state of the game.

Knowledge A rule checker knows whose turn it is, the state of the game, and what is about to happen.

Services A rule checker must understand the current board and two kinds of requests: to move a worker from one square to a neighboring one and to build (up) a building on a square neighboring to a worker that just moved. By implication (context), it knows that the worker is owned by the player whose turn it is.

Mock-up Context To test such a small system of a number of components, it is common to implement a mock-up environment.

Create a system-level test harness called xrules that can read and interpret sequences of well-formed JSON values (from STDIN and to STDOUT, respectively). Every sequence must begin with a board specification followed by a Move request and optionally followed by a MoveBuild request:

["+build", Direction]

The response to the entire sequence is always "yes" or "no", depending on whether the requested turn action is legal.

Testing Task Develop at least five system-level tests to be used with your test harness. A test consists of a pair of files: n-in.json and n-out.json where n is in 1, 2, 3, 4 or 5.

    ← prev  up  next →