← HraDokumentace a ke stažení

Addendum — Simulation, Experimentation and AI Playtesting Architecture

This document extends the original Cooperative Strategy Game & Simulation Platform specification.

It does not replace the original design brief. Its purpose is to strengthen the simulation architecture so the current implementation can become a serious game-design laboratory rather than only a digital implementation of the board game.

The implementation should incorporate these concepts incrementally and pragmatically. Existing working code should be preserved where possible.

1. Main Architectural Principle

Treat the game simulator as two separate products:

  1. Headless game and simulation engine
  2. Interactive web-based design laboratory

The game logic must not depend on:

The same core engine should be usable for:

human browser play
automated bot play
LLM playtesting
Monte Carlo simulation
parameter search
CI regression testing
replaying historical games
counterfactual analysis

The web application is a client of the engine, not the engine itself.

2. Recommended Architecture

Target conceptual architecture:

                         PLAYERS / AGENTS

               Human
               Random bot
               Heuristic bots
               Search agents
               RL agents (optional later)
               LLM agents
                   │
                   ▼

┌─────────────────────────────────────────────────────┐
│                     GAME CORE                       │
│                                                     │
│  GameState                                          │
│  Observation                                        │
│  Actions                                            │
│  Chance Model                                       │
│  State Transitions                                  │
│  Rules                                              │
│  Content                                            │
│  Scenario Generator                                 │
│  Game Parameters                                    │
│                                                     │
└─────────────────────────────────────────────────────┘

                  │                     │
                  ▼                     ▼

          Interactive Play        Headless Runner
                                        │
                                        ▼

                      ┌──────────────────────────┐
                      │    Experiment System     │
                      │                          │
                      │ simulations              │
                      │ agent tournaments        │
                      │ parameter sweeps         │
                      │ A/B comparisons          │
                      │ counterfactual tests     │
                      └──────────────────────────┘
                                        │
                                        ▼

                      ┌──────────────────────────┐
                      │      Trajectory Store    │
                      │                          │
                      │ states                   │
                      │ observations             │
                      │ actions                  │
                      │ chance events            │
                      │ metrics                  │
                      │ decisions                │
                      └──────────────────────────┘
                                        │
                                        ▼

                      ┌──────────────────────────┐
                      │      Analytics Lab       │
                      │                          │
                      │ balance                  │
                      │ skill depth              │
                      │ randomness               │
                      │ strategy diversity       │
                      │ content quality          │
                      │ replayability            │
                      └──────────────────────────┘

3. Explicitly Separate State, Observation, Action and Chance

The original implementation may currently expose the complete game state directly to players or bots.

Refactor this conceptually into four independent parts.

3.1 GameState

Represents the authoritative complete state of the game.

It may contain information hidden from individual players or agents.

Example:

interface GameState {
  gameId: string;
  round: number;
  phase: GamePhase;

  characters: CharacterState[];
  locations: LocationState[];
  situations: SituationState[];
  objectives: ObjectiveState[];

  resources: ResourceState;
  hiddenContent: HiddenContentState;

  rng: RandomState;
  history: HistoryEntry[];

  result?: GameResult;
}

Only the engine may modify authoritative state.

3.2 Observation

Represents what a specific actor is allowed to know.

Conceptually:

getObservation(
  state: GameState,
  actor: ActorId
): Observation

This distinction should exist even if the first game version uses almost entirely open information.

It enables future support for:

A bot or LLM should receive an Observation, not unrestricted access to GameState, unless explicitly running in omniscient analysis mode.

4. Legal Actions

Keep all game participants constrained by engine-generated legal actions.

Conceptual API:

getLegalActions(
  state: GameState,
  actor?: ActorId
): LegalAction[]

A participant selects one of these actions.

Then:

applyAction(
  state: GameState,
  action: LegalAction
): GameState

Players, bots and LLMs must never directly mutate game state.

This is essential for:

5. Make Randomness Explicit

Do not hide randomness inside arbitrary calls to:

Math.random()

or equivalent functions.

Every random event should belong to a named random source.

Possible examples:

scenario generation
situation selection
location generation
hidden outcome selection
content modifier selection
event sequencing

Represent randomness explicitly.

Example:

interface RandomStreams {
  scenario: RandomSource;
  situations: RandomSource;
  outcomes: RandomSource;
  modifiers: RandomSource;
}

Each random source should be seedable.

6. Multiple Independent Seeds

Prefer multiple named seeds over one opaque global seed.

Example experiment configuration:

{
  "scenarioSeed": 817263,
  "situationSeed": 193827,
  "outcomeSeed": 882731,
  "agentSeed": 389123
}

This allows experiments such as:

Keep the scenario identical while changing only uncertain outcomes.

or:

Give two strategies exactly the same future random events.

This is important because one of the central game-design goals is:

player decisions should matter substantially more than luck.

The simulator should eventually allow this to be measured instead of merely assumed.

7. Chance as a First-Class Event

Where practical, model random events as explicit transitions.

Conceptually:

interface ChanceEvent {
  source: ChanceSource;
  possibleOutcomes: ChanceOutcome[];
}

This does not mean the game must expose probability trees to players.

It means the simulation architecture should understand:

player decision
vs.
random event

as different causes of state changes.

This distinction becomes important for later analysis.

8. Complete Game Trajectories

Every simulated or human-played game should be recordable as a trajectory.

Suggested conceptual record:

interface TrajectoryStep {
  step: number;

  stateBefore: SerializedGameState;

  actor?: ActorId;

  observation?: SerializedObservation;

  legalActions?: SerializedAction[];

  selectedAction?: SerializedAction;

  chanceEvents?: SerializedChanceEvent[];

  stateAfter: SerializedGameState;

  metrics?: StepMetrics;
}

A full game becomes:

interface GameTrajectory {
  metadata: GameRunMetadata;
  steps: TrajectoryStep[];
  result: GameResult;
}

Prefer a serialization format that can also be efficiently streamed or processed, such as JSONL.

9. Replayability

Every recorded trajectory should support deterministic replay.

Required behavior:

Load trajectory
→ restore initial state
→ replay actions and chance events
→ reproduce final state

If replay produces a different state, this should be treated as an engine correctness problem.

This makes historical simulations useful for:

10. Forking Historical Games

Add the concept of creating a new simulation branch from an arbitrary historical decision.

Example:

Game trajectory

step 1
step 2
step 3
step 4 ← fork here
       ├─ original action
       ├─ alternative A
       ├─ alternative B
       └─ alternative C

This enables counterfactual analysis.

It should eventually be possible to select any meaningful decision in the UI and ask:

What would probably have happened if another action had been selected?

11. Counterfactual Simulation

Counterfactual analysis is one of the most valuable additions to the original specification.

For a selected state:

  1. Enumerate candidate actions.
  2. Apply each candidate action.
  3. Run many continuations from each resulting state.
  4. Use identical or paired future random seeds where appropriate.
  5. Compare distributions of outcomes.

Example:

Decision at round 4:

A — Investigate ruins
Win rate: 62%
Average objective progress: 8.1

B — Continue toward destination
Win rate: 59%
Average objective progress: 8.8

C — Resolve storm damage
Win rate: 38%
Average objective progress: 6.4

Do not treat estimated win rate as the only value function.

Compare multiple metrics.

12. Effective Choices vs Legal Choices

The number of legal actions alone is not a useful measure of strategic depth.

Example:

15 legal actions

may actually mean:

1 sensible action
14 obviously inferior actions

The simulator should eventually estimate effective choices.

One possible approach:

  1. Evaluate candidate actions using rollouts or a search agent.
  2. Estimate their expected value.
  3. Count how many remain within a configurable range of the best candidate.

Example:

best expected score: 0.72

actions within 5%:
3

actions within 10%:
5

This is much more useful than raw branching factor.

13. Decision Quality Metrics

Introduce metrics such as:

legal action count
effective action count
best-vs-second-best difference
action-value entropy
decision sensitivity
decision reversibility

Interpretation:

Very low effective choice count

Potentially:

Extremely high effective choice count

Potentially:

A preliminary design target may be roughly:

2–5 meaningful choices

for typical important decisions.

This is a hypothesis, not a hard rule.

14. Skill Ladder

Create multiple agent strengths.

Do not compare only:

random bot vs LLM

Use a progression.

Recommended initial ladder:

Random
↓
Simple heuristic
↓
Greedy heuristic
↓
One-step lookahead
↓
Small search
↓
larger search
↓
strong planner

For example:

Random
Greedy
OSLA
MCTS-100
MCTS-1,000
MCTS-10,000

Exact algorithms may change.

The important concept is increasing decision quality.

15. Skill Depth Metric

Compare performance across the skill ladder.

A strategically meaningful game should generally produce:

stronger decision-making
→ measurably better outcomes

If:

Random agent ≈ strong planner

then outcomes may depend too strongly on luck.

If:

simple greedy ≈ strongest planner

the strategy may be too shallow or dominated by a trivial heuristic.

Track:

agent strength
vs.
success rate
vs.
objective score
vs.
resource efficiency

16. Search Agents Before Heavy LLM Usage

LLMs are valuable, but should not be the main quantitative balancing engine.

Implement search-based or algorithmic agents where useful.

Potential approaches:

one-step lookahead
beam search
Monte Carlo rollouts
MCTS

Advantages:

Use LLMs mainly where language understanding and qualitative assessment add value.

17. Recommended Agent Responsibilities

Algorithmic agents

Best suited for:

balance
strategy testing
parameter optimization
dominant strategy detection
skill depth analysis
counterfactual simulation

LLM agents

Best suited for:

human-like strategic interpretation
rule comprehension testing
narrative evaluation
situation interpretation
qualitative playtest feedback
content review

Human playtests

Best suited for:

fun
clarity
social interaction
emotional engagement
table presence
cognitive load
actual age suitability

These are complementary, not interchangeable.

18. Experiment as a First-Class Entity

Do not implement batch simulation only as:

Run 1,000 games

Create a formal Experiment model.

Example:

interface ExperimentConfig {
  id: string;

  gameVersion: string;

  contentVersion: string;

  parameters: GameParameters;

  agents: AgentConfiguration[];

  scenarios: ScenarioConfiguration[];

  seeds: SeedConfiguration;

  repetitions: number;

  metrics: MetricId[];
}

Results should be reproducible from the stored experiment configuration.

19. Game Versioning

Every simulation result must record which game version produced it.

At minimum track:

rules version
content version
parameter version
agent version

Example:

{
  "rulesVersion": "0.4.2",
  "contentVersion": "base-0.3",
  "parameterSet": "standard-v7",
  "agentVersion": "mcts-0.2"
}

Never mix analytics from incompatible versions without explicit normalization or labeling.

20. A/B Game Variant Comparison

Support formal comparison between game variants.

Example:

Variant A
shared action pool = 10

Variant B
shared action pool = 8

Variant C
hybrid personal/shared actions

Run all variants using matched scenarios and seeds where appropriate.

Compare:

win rate
decision diversity
effective choices
game length
character utilization
situation engagement
strategy distribution

The web UI should eventually offer direct:

A vs B

comparison.

21. Parameter Search Space

Move game-balance parameters out of hardcoded logic.

Example:

interface GameParameters {
  rounds: number;

  actionsPerRound: number;

  initialSituationCount: number;

  situationFrequency: number;

  objectiveDifficultyMultiplier: number;

  situationExpirationMultiplier: number;

  rewardMultiplier: number;

  uncertaintyRate: number;
}

Not every parameter needs to exist immediately.

The important requirement is that balance-relevant numbers should be configurable.

22. Parameter Sweep

Support experiments such as:

rounds:
6, 7, 8, 9

actionsPerRound:
8, 9, 10, 11

situationFrequency:
0.8, 1.0, 1.2

The simulator can then execute all combinations.

Results should identify regions where desired properties emerge.

23. Multi-Objective Optimization

Do not optimize exclusively for:

50% win rate

A game with a perfect win rate distribution may still be boring.

Possible target metrics:

Standard win rate:
55–70%

Median game duration:
15–25 minutes

Effective choices:
2–5 for important decisions

Unused actions:
low

Character contribution:
balanced

Randomness contribution:
limited

Situation engagement:
diverse

Strategy concentration:
low

Treat balance as a multi-objective problem.

24. Randomness Contribution Analysis

One central requirement of the game is low dependence on luck.

The simulator should therefore explicitly estimate:

How much of the outcome variation comes from randomness versus player decisions?

A practical approach can use paired simulations.

For example:

Same agent
Same decisions where possible
Different random seeds

versus:

Different agents
Same random seeds

Compare outcome variance.

Eventually generate metrics such as:

seed sensitivity
agent sensitivity
scenario sensitivity
outcome randomness sensitivity

The exact statistical method can evolve later.

The architecture must make this analysis possible.

25. Strategy Classification

Store enough trajectory information to identify recurring strategies.

Examples:

main-objective rush
opportunity-heavy
risk avoidance
full situation resolution
exploration-heavy
resource conservation
single-character concentration
balanced character usage

Some strategies may be manually defined initially.

Later they may be inferred using clustering.

26. Dominant Strategy Detection

A strategy may be problematic if it:

Flag patterns such as:

always ignore optional situations
always resolve every negative situation
always use the same character first
always concentrate actions on one character
always pursue objectives before exploration

Do not automatically treat dominance as a bug.

Surface it to the designer for review.

27. Trajectory Similarity

Content variety should not be measured only by:

different cards appeared

Two games may use different cards but produce functionally identical play.

Store complete trajectories and derive normalized features such as:

objective progress over time
action types over time
character usage
location movement
situation lifecycle
resource trajectory
risk exposure
opportunity engagement

Use these to estimate similarity between games.

28. Replayability Metrics

Introduce metrics such as:

trajectory diversity
strategy diversity
content diversity
decision diversity
ending diversity

A useful future concept:

Replayability Distance

where highly similar playthroughs have low distance and substantially different strategic trajectories have high distance.

Exact algorithm can be deferred.

Store sufficient data now so the metric can be implemented later.

29. Scenario Quality Analysis

Because this game relies heavily on varied situations and emergent stories, introduce analytics specifically for scenarios.

For each scenario or scenario family track:

success rate
game duration
objective completion order
situation engagement
ignored opportunities
strategy distribution
decision difficulty
randomness sensitivity
trajectory diversity

Identify scenarios that are:

too easy
too hard
too deterministic
too random
too repetitive
too similar to another scenario

30. Situation Quality Analytics

Each Situation should accumulate analytics.

Example:

interface SituationAnalytics {
  appearanceCount: number;

  engagementRate: number;
  ignoreRate: number;

  resolutionRate: number;
  expirationRate: number;

  averageActionCost: number;

  averageLifetimeRounds: number;

  successCorrelation: number;

  objectiveProgressCorrelation: number;

  effectiveChoiceImpact: number;

  trajectoryImpact: number;
}

This is important because a situation can be mechanically balanced while still being strategically irrelevant.

31. Detect Functional Duplicate Content

Two cards may have different:

name
story
theme
art

while producing almost the same player decision every time.

The simulator should eventually detect potential functional duplicates.

Example:

Card A:
engaged 68%
cost 2 actions
usually chosen in round 3–4

Card B:
engaged 70%
cost 2 actions
usually chosen in round 3–4

trajectory effect almost identical

Flag such pairs for human review.

This is especially important if LLM-generated candidate content becomes large.

32. Opportunity Analysis

Because the game intentionally includes positive, negative and ambiguous situations, track opportunity behavior separately.

Metrics may include:

opportunity engagement rate
expected reward
actual reward
action investment
opportunity abandonment
opportunity regret
objective trade-off

Important question:

Are optional opportunities genuinely tempting without becoming mandatory?

Ideally the answer should vary by context.

33. Ambiguous Situation Analysis

For hidden or partially known outcomes, track:

engagement before reveal
outcome distribution
player expectation
actual result
future behavioral impact

A hidden outcome should not behave like arbitrary punishment.

The system should help identify situations where:

risk is too high
reward is too low
players always engage
players never engage
outcome variance dominates strategy

34. Human Playtest Telemetry

Human games played in the web simulator should produce the same trajectory format as bot simulations.

Additionally record non-game telemetry where useful:

decision time
undo usage
rules help usage
hover/detail inspection
pass/no-op usage

Do not interpret these automatically as definitive UX problems.

They are signals.

Example:

decision repeatedly takes 45 seconds

may indicate:

Human review remains necessary.

35. Compare Human and AI Play

Once enough human games exist, compare:

human strategy distribution
vs.
bot strategy distribution

Useful metrics:

action frequency
situation engagement
character usage
decision branching
objective order
game duration
success rate

The goal is not to make AI perfectly imitate humans.

The goal is to identify when automated testing explores a very different part of the strategy space than real players.

36. LLM Playtest Reports

After selected games, LLM agents may produce structured evaluations.

Recommended output schema:

{
  "mostInterestingDecision": "...",
  "mostObviousDecision": "...",
  "leastUsefulMechanic": "...",
  "dominantStrategyObserved": "...",
  "unclearRule": "...",
  "narrativeConsistency": "...",
  "randomnessAssessment": "...",
  "replayabilityAssessment": "..."
}

These reports are qualitative evidence only.

Do not mix them directly with quantitative metrics.

37. Aggregate LLM Feedback

Do not rely on a single LLM playtest report.

Instead:

run multiple games
↓
collect structured reports
↓
aggregate recurring observations
↓
surface clusters

Example:

17 / 25 agents:
"Optional exploration rarely felt worthwhile."

14 / 25:
"Character C had little reason to act."

3 / 25:
"Outcome randomness felt frustrating."

Recurring feedback is more useful than isolated commentary.

38. Experiment Dashboard

The web application should eventually provide an analytics-oriented experiment screen.

Useful views:

Experiment summary

games simulated
agent composition
game version
parameter set
seed configuration

Outcome distribution

win / loss
objective score
rounds played

Decision quality

branching factor
effective choices
decision entropy

Agent comparison

Random
Greedy
Planner
MCTS
LLM

Content analytics

situations
characters
objectives
scenarios

Strategy analytics

strategy frequency
dominant patterns
trajectory clusters

39. Distribution Over Average

Where possible, show distributions rather than only averages.

Prefer:

median
quartiles
percentiles
histogram/distribution

over only:

average = 7.3

For example:

game duration:
median 8 rounds

P10: 6
P90: 10

This makes outliers and unstable balance visible.

40. Confidence and Sample Size

The simulator should not imply statistical certainty from tiny samples.

Example:

Win rate: 62%
n = 18

should be visually distinguishable from:

Win rate: 62%
n = 25,000

Track sample size everywhere.

Confidence intervals may be added where useful.

41. CI Regression Testing

Create deterministic simulation-based regression tests.

Examples:

game always terminates
no illegal state transitions
no negative resources
all generated scenarios are solvable structurally
all legal actions are executable
serialized replay reproduces the same state

Later add statistical regression guards.

Example:

Standard mode win rate with baseline agent:
expected 45–70%

Do not make narrow statistical thresholds flaky.

Use generous ranges.

42. Content Validation Through Simulation

Candidate content should pass automated tests before inclusion.

Pipeline:

schema validation
↓
static rule validation
↓
scenario generation validation
↓
simulation
↓
metric comparison
↓
qualitative review
↓
human approval

Automatically flag content that produces extreme results.

Example:

new card increases success rate by 18 percentage points

or:

new situation is ignored in 96% of appearances

43. Performance Requirements

Keep simulation independent of rendering.

Target execution path:

createGame()
getLegalActions()
selectAction()
applyAction()
...

without:

DOM
React
animations
network
browser layout

Simulation should be suitable for:

Node.js
workers
parallel execution
CI

Do not prematurely optimize everything.

However, avoid architectural choices that make large-scale simulation impossible.

44. Parallel Simulation

Batch simulation should eventually support parallel workers.

Conceptually:

Experiment
   │
   ├─ worker 1 → games 1–2500
   ├─ worker 2 → games 2501–5000
   ├─ worker 3 → games 5001–7500
   └─ worker 4 → games 7501–10000

Each simulation must remain independently reproducible from its seeds.

45. Avoid Storing Excessive State by Default

Complete trajectories are useful but can become large.

Support recording levels.

Example:

NONE
SUMMARY
ACTIONS
KEY_STATES
FULL

Batch balancing runs may use:

SUMMARY

while debugging or selected LLM games may use:

FULL

This allows large-scale simulation without unnecessary storage.

46. Separate Simulation Metrics from Game Rules

Instrumentation must not alter gameplay.

Avoid code such as:

if (analyticsEnabled) {
  // different game behavior
}

Instead:

engine emits domain events
↓
analytics observers consume events

Example events:

ActionSelected
SituationRevealed
SituationEngaged
SituationResolved
SituationExpired
ObjectiveAdvanced
ResourceChanged
RoundEnded
GameEnded

This creates a cleaner analytics layer.

47. Event-Based Instrumentation

Recommended conceptual event:

interface GameEvent {
  type: string;
  step: number;
  round: number;
  actor?: ActorId;
  entityIds?: string[];
  payload?: unknown;
}

Metrics should preferably be calculated from events and trajectories rather than hardcoded throughout gameplay logic.

48. Designer-Friendly Debugging

The simulator UI should provide:

current state
current observation
legal actions
selected action
chance events
game events
parameter values
seed values

A designer should be able to answer:

Why did this happen?

without reading source code.

49. Decision Inspector

Add a future UI concept called something like:

Decision Inspector

For a selected decision show:

available actions
estimated action values
effective alternatives
future rollouts
relevant rules
contributing state variables

This can become one of the most useful tools in the application.

50. Scenario Inspector

Likewise, support inspecting generated scenarios.

Show:

scenario template
selected content
tags
compatibility decisions
random seeds
difficulty estimate
generated objectives
generated situations

The designer should be able to explain why a scenario was generated.

51. Content Provenance

For every piece of content track its source.

Possible sources:

human
LLM candidate
LLM revised
generated
expansion pack

Example:

interface ContentMetadata {
  source: "human" | "llm" | "generated";
  version: string;
  authoringBatch?: string;
}

Useful later for evaluating whether automatically generated content behaves differently from hand-designed content.

52. Strong Separation Between Content and Mechanics

Continue the original principle:

complexity should live in combinations, not rules.

The simulator should reinforce this separation.

Game mechanics should not require code modifications for every new Situation.

Prefer:

content schema
+
effects
+
tags
+
conditions

over:

if (cardId === "special_card_37") {
  // custom rules
}

Custom mechanics should be exceptional.

53. Recommended Immediate Refactoring Priorities

Do not attempt to implement the entire analytics system at once.

For the current implementation, prioritize in this order.

Priority 1 — Core correctness

Ensure:

headless engine
serializable GameState
legal action generation
pure/controlled transitions
seeded randomness

Priority 2 — State / Observation separation

Introduce:

GameState
Observation
Action
Chance

even if Observation initially mirrors most of GameState.

Priority 3 — Game trajectory

Record:

initial state
actions
chance events
final state

Support deterministic replay.

Priority 4 — Experiment runner

Create:

ExperimentConfig
SimulationRunner
ExperimentResult

Support many headless games.

Priority 5 — Baseline agents

Implement:

Random
Greedy
Objective-focused
Risk-focused

Keep the agent interface generic.

Priority 6 — Metrics

Initially calculate:

win rate
game duration
action frequencies
character usage
situation engagement
objective progress
unused actions
legal branching factor

Priority 7 — Variant comparison

Support:

parameter set A
vs.
parameter set B

using matched seeds.

Priority 8 — Search agent

Add at least one simple planning agent.

For example:

one-step lookahead

and later:

Monte Carlo search / MCTS

Priority 9 — Counterfactual analysis

Fork states and compare alternative actions.

Priority 10 — Advanced analytics

Only then add:

effective choices
skill-depth measurement
randomness attribution
trajectory similarity
strategy clustering
content functional-duplicate detection

54. Non-Goals for the Current Refactoring

Do not block current development waiting for:

reinforcement learning
complex neural agents
distributed cloud infrastructure
perfect statistical models
automatic game design
automatic publication of content

The architecture should allow these later.

They are not required now.

55. Important Implementation Principle

Avoid coupling future capability to a specific AI provider.

The agent interface should be provider-neutral.

Conceptually:

interface Agent {
  selectAction(
    context: AgentContext
  ): Promise<ActionSelection>;
}

Possible implementations:

RandomAgent
GreedyAgent
SearchAgent
LlmAgent
HumanAgent

An LLM should be just another agent implementation.

56. LLM Agent Input

Do not send arbitrary internal state dumps to the model by default.

Build a normalized context.

Example:

interface AgentContext {
  observation: Observation;

  legalActions: LegalAction[];

  objectives: ObjectiveSummary[];

  recentHistory: HistorySummary[];

  metadata: {
    round: number;
    roundsRemaining: number;
  };
}

This improves:

57. LLM Structured Output

LLM agents should choose actions through structured output.

Example:

{
  "actionId": "character-2:investigate:situation-8",
  "comment": "The opportunity may unlock the objective route."
}

The engine must validate actionId.

Invalid responses should never mutate state.

58. Designer-Defined Evaluation Functions

Do not hardcode only a binary win/loss score.

Allow evaluation functions such as:

objective progress
remaining resources
team condition
unresolved situations
round efficiency
exploration achieved
optional discoveries

Search agents may use weighted combinations.

This is also useful for incomplete simulations.

59. Beware of Optimizing Away Fun

The simulator is a design aid.

It must not silently turn the design goal into:

maximize win probability.

For example, an optional mysterious situation may intentionally be slightly suboptimal in pure efficiency terms but highly valuable for:

story
curiosity
variation
tension

Therefore:

mechanical optimality
≠
game quality

The analytics system should expose trade-offs, not automatically decide them.

60. Overall Target

The improved system should allow the designer to ask questions such as:

Does skill matter more than luck?

Are there several viable strategies?

Does one character dominate?

Are optional opportunities actually attractive?

Which situations are almost always ignored?

Do different content packs produce genuinely different games?

Are two cards narratively different but mechanically identical?

Is Standard difficulty actually harder because of decisions,
or just because bad random outcomes become more punishing?

Does reducing the action pool improve tension
or merely make the game frustrating?

Does this rule change improve the game across scenarios
or only solve one specific case?

Do humans play similarly to our automated agents?

At which turns are decisions most interesting?

Which decisions are almost automatic?

These questions are more important than raw win rate.

61. Final Design Principle

The simulation platform should optimize for understanding the game, not merely running it quickly.

Its purpose is to reveal:

why games are won
why games are lost
where meaningful decisions happen
where decisions are fake
where randomness matters
which strategies emerge
which content matters
which content is redundant
how different playthroughs really are

The simulator should therefore evolve from:

a digital implementation capable of automated play

into:

a reproducible experimental environment for designing, testing and understanding the strategic and narrative behavior of the game.