CAST — Same Play, Different Rules

Inspiration

Game mechanics are judged by feel, but iteration usually breaks that feedback loop.

A designer notices something wrong during a playtest, stops playing, changes the logic, rebuilds the prototype, and then tries to recreate the exact moment that exposed the problem. Even when the change is small, comparing the old and new mechanic is surprisingly hard because the original interaction is already gone.

CAST asks a different question:

What would the play I just made have felt like under a different rule?

What it does

CAST is a live playtest agent for game and interaction designers.

The workflow is simple:

1. Play the prototype normally.
2. Describe a mechanic change in natural language.
3. CAST uses a Strands Agent to turn that intent into an executable rule change.
4. The exact same recorded player input is replayed from the same initial state under:
   • the OLD mechanic
   • the NEW mechanic
5. The designer can immediately compare the results, try the candidate, keep it, revert it, or revise it again.

The key idea is not AI-generated game logic.

It is counterfactual playtesting:

Same play. Different rules.

In our demo, the player moves cargo toward a goal. The designer can ask for a rule such as:

“Only attach when I approach slowly.”

The Strands Agent generates a rule using distance and speed. CAST then replays the same recorded interaction under both versions.

A second request can modify the existing mechanic again, for example making a fast movement detach the cargo. This is handled as a real patch to the current mechanic rather than restarting from a prebuilt result.

How we built it

CAST is built around a constrained rule runtime rather than free-form code generation.

The Strands Agent receives the current scene, existing mechanics, recent modification context, and a set of reusable control primitives. It decides whether to add, replace, or modify a relationship and calls tools to produce an executable candidate.

The runtime supports signals such as position, movement direction, speed, and distance, together with composable conditions and stateful behaviors.

For the hero interaction, we implemented generic attach/detach behavior with persistent state:

• acquire an object when conditions become true
• preserve its relative offset while following
• detach it when another condition is triggered
• preserve its released position

CAST also records a real pointer playtest:

• initial world state
• ordered input frames
• relative timestamps
• relevant movement signals
• mechanic version

The replay engine restores the same initial state and feeds the same recorded input into both the old and candidate rulesets. This makes the comparison about the mechanic itself rather than differences between two attempts by the player.

The current prototype uses a simple PLAYER → CARGO → GOAL graybox scene so the mechanic remains visually obvious.

How Strands is used

Strands is the decision-making layer of CAST, not just a chat interface.

The Agent:

• reads the current scene and rules
• interprets the designer's requested change
• decides whether the mechanic requires a new rule or a patch
• composes reusable control primitives
• preserves unrelated behavior
• produces an executable candidate through tool calls
• supports follow-up revisions to an existing mechanic

The verified browser flow includes real Strands tool calls for mechanic creation and subsequent patch revision.

If the Agent cannot produce a valid candidate, CAST keeps the current mechanic instead of silently substituting a hard-coded result.

Challenges

The hardest part was realizing that generating a rule was not enough.

Our first version used camera-tracked physical props, but unstable visual tracking made the input itself dominate the experience. We de-emphasized that unstable camera path and made deterministic pointer play the primary competition path and focused on the more important interaction: comparing the same real play under different mechanics.

We also discovered that simple position assignment could not honestly represent mechanics such as grabbing and releasing cargo. Attach, follow, detach, and state persistence had to become real runtime behaviors.

Another challenge was deterministic comparison. OLD and NEW cannot be two hand-authored animations. Both versions must start from the same world snapshot and consume the same recorded player input.

What we learned

The most useful role for an agent here is not deciding which mechanic is “better.”

That judgment belongs to the designer.

The agent is valuable because it removes the repetitive work between having an idea and being able to evaluate it:

interpret the change → implement it → reconstruct the moment → run the comparison.

That keeps the human focused on the part that still requires human judgment: how the interaction feels.

What's next

CAST currently demonstrates the idea with a compact graybox interaction and a constrained mechanic runtime.

The next step would be connecting the same counterfactual playtesting loop to richer prototypes and existing game engines, while keeping the same principle:

the designer plays once, changes the rule, and immediately sees what that exact play would have become.

Builder Center Bonus Posts

• Building CAST — Counterfactual Playtesting with Strands Agents
• Designing a Safe Mechanic Patch Loop with Strands Agents
• Why CAST Replays the Same Play Under Different Rules

Built With

• fastapi
• javascript
• python
• strands