►Software Development
▼—The Project
•4 — The Rules
7.8.0.1
    ← prev  up  next → 

4 — The Rules

Due Thursday, 10 October 2019, midnight

Delivery Place the product of this week’s project steps into your repo as follows:

Design Task Our plan calls for the implementation of an automated player and a referee component, which supervises a game of a three to five automated players.

Describe interfaces for a Tsuro referee and an automated Tsuro player.

Keep in mind that such planning documents describe what the desired methods/functions should compute without pre-determining how they should compute it.—Separately describe the internal organization of the referee and player.

The memo must not exceed two pages. Less is more.

Programming Task Design the implementation of the rule enforcing component. It relies on the design of an action component, which is a data representation of the actions a player may request.

In addition to the basic constraints of Tsuro, for now, the following rules govern our Tsuro games.

When a player requests the initial placement of an avatar on a specific port p and tile at a certain spot (x,y) on the board, the requested action is legal if the squares horizontally and vertically neighboring (x,y) are unoccupied and the p faces an unoccupied square.

When a player requests the placement of a tile during its turn, the requested placement must not conflict with the given information and the tile placement may not cause

  • the player’s suicide (as in exiting the board), unless this is the only possible option (due to the supplied tiles); or

  • send any avatar into an infinite loop, unless this is the only possible option (due to the supplied tiles).

Everything else is legal.

Testing Task Develop a test harness for the game board.

The words ``place'' are short for ``placement''. The words ``initial'' and ``intermediate'' are possibly misleading; they anticipate how these specs will be used for the distributed version.

An input is a JSON array of state-pats followed by a sequence of action-pats:

     A state-pat is one of:

      -- initial-place

      -- intermediate-place

    

    An initial-place is [tile-pat, color, port, index, index]

    An initial place represents where an avatar for some player is currently placed:

    the position of the tile; the tile itself and how its rotated;

    plus the port where the colored avatar is placed.

    

    An intermediate-place is [tile-pat, index, index]

    An intermediate place represents where a particular tile is placed and how it is rotated.

    

    An action-pat is [color, tile-pat]

The sequence array of state-pats describes the current state of the board. The action-pat specifies which player places which tile; the harness applies the first to the given board, the next action to the result, and so on.

The output is one of the following:

  • an initial-place of the shape [tile-pat, "red", port, index, index], that is, the place of the red avatar on the state resulting from the execution of the action sequence;

  • "red never played" if the red avatar isn’t a part of the initial state to start with;

  • "red died" if any of the actions sends off the red avatar;

  • "infinite" if any of the actions sends an avatar into an infinite loop; the harness does not apply any more actions when this happens in the middle of the sequence.

  • "collision" if two avatars (or more) avatars end up on the same spot.

Validity The input must specify a valid state of the board in terms of tile and avatar placement. Thus the sequence array may contain at most one state-pat that describes the location of a colored avatar, and the tiles must be coherent.

Create five tests and place them in board-tests.

    ← prev  up  next →