3 — The State🔗

Due Tuesday, 01 October 2024, 11:59:59pm

Purpose This milestone has multiple learning goals:

• T to deal with the data-representation aspect of state machines;

• T to script an integration test environment (which eventually also supports the communication among components); and

• S to reflect on a partnership (self, partner) in an honest manner.

State machines are ubiquitous in software systems. A state-machine component is in some state and, triggered by certain stimuli, transitions from state to state. Many board games are essentially state machines: the game is in a certain state and, when a player is granted a turn, the state changes. Software designers have developed an approach to state machines that helps with testing by cleanly separating concerns: (1) the data representation of states from (2) the transition machinery. This milestone focuses on (1).

Partnership Evals For this milestone, we request an evaluation of your partnership.

Delivery Place the product of this week’s milestone into your git repo as follows:

Programming Task Design & implement a data representation for the information about the game’s state that the referee must keep to decide whether a player’s requests are legal according to the rules of the game.

This game state comprises the following pieces of varying information: the bank; the cards; all players’ wallets, scores, and reachability; The referee cannot know the entire state of a player. For example, a referee should not know which strategy a player uses to make decisions. and the order in which the players take turns. Consider the chosen set of equations a global constant, because it is chosen once and for the entire duration of the game during the setup phase.

The player whose turn it is next is called the active player.

Assuming that players know nothing about the state of the game—other than the equations chosen at the beginning of the game—the referee must provide sufficient information to the active player so that it can make decisions. Design & implement a data representation for this information. We refer to this data representation as the turn state. This data representation includes the bank’s pebbles, the active player’s state, and the current score of the remaining players.

Design Task In contrast to human players, AI players are not in charge; the referee of the game framework is and it plays the role of arbiter, which is often left to the collective of all players (or a subset of knowledgeable ones).

Here the referee engages the players, informing them of the game’s progress as needed, and managing turns. When granted a turn, a player responds with a description of the desired action, but it is the referee that executes them on behalf of the player on the ground-truth state of affairs—if the request is legal.

Design a player interface in the form of a method/function wish list. For each piece of functionality, describe what knowledge it must be able to retrieve from context (if any). Choose the wish list format that you got to know in Fundamentals I and Fundamentals II, depending on which of the languages used in these courses matches your chosen language most closely.

Note, each player component consists of two pieces: the mechanics for executing game actions and a strategy (or several strategies) for pursuing a goal. This task is concerned with mechanics only.

The memo should not exceed a page.

Keep in mind our Bazaar.Com, a Plan while you work on a design task.

Testing Task Create a test harness named xeq. The harness consumes its JSON inputs from STDIN and sends its results to STDOUT. Create three tests and place them in the specified [0-2]-{in,out}.json folder.

A test case always consists of given inputs and expected outputs. For this course, a test consists of a pair of files: n-in.json, the input file, and n-out.json, the expected output file, where n is an integer between 0 and the requested number of tests (exclusive).—Constraint No test file may exceed the size limit of 40Kb.

Here are the relevant JSON specifications:

Equation is an array of the shape [*Pebbles, *Pebbles]. INTERPRETATION The two arrays of Pebbles represent the two sides of an equation. The order in these arrays does not matter. CONSTRAINT the two *Pebbles in an Equation contain between 1 and 4 items CONSTRAINT the two *Pebbles in an Equation are disjoint

Wallet is a *Pebbles. INTERPRETATION It represents the Pebbles that the player owns.

Bank is a *Pebbles. INTERPRETATION It represents the Pebbles that the bank owns.

*Pebbles is an array of the shape [Pebble, ..., Pebble]. INTERPRETATION Any two *Pebbles are considered equal if they contain the same Pebbles, that is, it represents a set.

Pebble is one of: "red", "white", "blue", "green", "yellow"

} Hint This JSON data exchange representation is not intended to be identical to your data representation (and it is certainly not the one used for the oracle implementation).

Well-formed and Valid You may assume that all inputs to your test harnesses from STDIN are well-formed and valid. A well-formed piece of JSON satisfies the grammar; such a piece is valid if it also satisfies all the side constraints of a schema specification.

Beyond integeration testing, we should eventually move to stress testing. The course will touch on this idea in November or December.

Pedagogy Besides unit tests, multi-component projects also need integration tests. Such tests compose several components and run tests on the composite that exercise functions across the components. This task is a lightweight illustration of this idea.

When a milestone assignment requests an integration test harnesses, you should not have to modify the core functionality from the previous milestone—other than the addition of code for (de)serialization between your chosen data representation and JSON; see Bazaar.Com, a Plan.

That is, building harnesses for integration tests doesn’t slow you down—it actually accelerates your progress because the goals are always compatible with the current task and lay its foundation. Work thru the integration testing task before tackling the programming task.

Partner Evaluation

Only the head TA and, if necessary, the instructors will read your responses; nobody else will. At their digression, the instructors may interview partners.

The partnership evaluation is worth 20 points.