A request for another level leaves an important production question open: are we changing the starting situation, or changing what the player can do?

Those changes can be separated in a small example. We built an owned teaching puzzle with a five column, three row board. It is not a client game or a proposed replacement for one. Its job is to make the boundary visible.

A new situation under the same rule

Version A defines a starting position, a goal and two obstacles. A directional command moves the piece one cell, provided that cell can be occupied.

Version B changes the starting position, goal and obstacles. It uses the same movement rule and implementation. The situation is different; the meaning of the command is unchanged.

That is a configuration change in this model. It still creates a new layout to check. Calling it configuration does not remove the need to check the result.

The same situation under a new rule

Version C keeps A’s layout but changes movement from a one cell step to a slide. A directional command continues until the next obstacle or board edge stops it.

The starting position is identical in A and C. A Right command moves A one cell. In C, it carries the piece across that open row to the edge. The same input and the same starting picture produce different movement because the rule changed.

This is why a still image is not enough to describe the scope boundary. Identical art can conceal changed behavior; visibly different layouts can share one rule.

Turn the distinction into a brief

A useful request identifies the starting state, the input and the expected result. If only the start, goal or obstacle positions change, say so. If the input should behave differently, describe that change separately. If both change, keep both in the request.

For a production partner, this gives a concrete behavior to inspect instead of an ambiguous instruction to make another version. It is a starting point for scoping, not a pricing formula.

Our example was built to separate these variables. An existing playable may have a different architecture, dependencies or hard coded behavior. Whether a requested variant is configurable, needs code changes or requires a broader rebuild can only be established from that build.

In your next variant brief, name what changes: the starting layout, the action rule, or both.