Cooperative Strategy Game & Simulation Platform

1. Objective

Design and prototype a cooperative strategic board/card game for approximately 1–5 players, supported by a web-based simulation environment that allows:

• human playtesting,
• solo play,
• automated simulation,
• rule validation,
• statistical balance testing,
• AI/LLM-controlled players,
• AI-assisted content generation and review.

The project should initially focus on the game system and decision quality, not on final artwork, physical production, or a specific theme.

The intended result is a game that is:

• easy to learn,
• strategically meaningful,
• highly interactive,
• enjoyable from the first turn,
• minimally dependent on luck,
• highly replayable,
• playable in approximately 15–30 minutes,
• suitable roughly from age 10,
• viable both as a solo game and a cooperative multiplayer game,
• expandable primarily through additional content rather than additional rules.

The final physical game must remain fully playable without software or AI.

2. Core Design Principles

2.1 Meaningful decisions over complexity

Strategic depth should come primarily from difficult choices rather than complicated rules.

A good turn should usually offer several plausible choices, while making it impossible to accomplish everything.

Ideal decision pattern:

Several things are worth doing, but available time/actions/resources allow only some of them.

Avoid situations where:

• one action is obviously optimal,
• players merely execute a predetermined sequence,
• success depends primarily on drawing the right card,
• players spend several early turns building an economy before interesting decisions begin.

2.2 Interesting from the first turn

The game should begin with meaningful circumstances already present.

Avoid:

Start with an empty board → collect resources → slowly build capabilities → eventually encounter meaningful decisions.

Prefer:

Start with objectives, opportunities, uncertainty, competing priorities, and limited capacity immediately.

The first turn should already contain a genuine decision.

2.3 Random input, strategic output

Randomness is allowed and desirable when it creates variety.

It should primarily determine:

• what appears,
• where something happens,
• which combination of circumstances exists,
• which opportunities become available,
• how a scenario develops.

Randomness should generally not determine whether an already chosen action succeeds.

Prefer:

A location requires three units of effort. Players decide whether to invest them.

Over:

Attempt the action and roll a die to see whether it succeeds.

Randomness should create the puzzle, not solve it.

3. Neutral Concept: "Situations" Rather Than "Problems"

The system must not assume that cards represent threats or problems.

The central content unit should instead be called a Situation, Opportunity, Encounter, or similarly neutral term.

A situation may be:

• beneficial,
• harmful,
• mixed,
• optional,
• uncertain,
• risky,
• time-sensitive,
• potentially beneficial but costly,
• initially ambiguous,
• something players may deliberately ignore.

Examples depending on theme:

Exploration

• an unexplored cave,
• unusual weather,
• a stranded traveler,
• a shortcut,
• an abandoned camp,
• signs of wildlife,
• a valuable discovery.

Space

• unexplored signal,
• malfunction,
• trade vessel,
• asteroid field,
• scientific anomaly,
• abandoned station,
• distress call.

Fantasy

• traveling merchant,
• wounded creature,
• suspicious ruins,
• approaching storm,
• local dispute,
• magical artifact,
• hidden passage.

Players should frequently ask:

Is this worth pursuing?

rather than only:

How do we fix this?

4. Outcome Uncertainty

Situations may have different levels of information.

The game should support at least three categories.

4.1 Known outcome

Players know the requirements and consequences.

Example:

Repairing the bridge costs 3 effort and opens a shorter route.

Useful for strategic planning.

4.2 Partially known outcome

Players know some consequences but not all.

Example:

Investigating the signal requires 2 exploration. It may reveal a useful location or trigger another event.

Players choose whether the potential benefit justifies the uncertainty.

4.3 Unknown outcome

The result becomes known only after the players commit.

Example:

Search the abandoned shelter.

Possible outcome may be determined by:

• drawing a linked card,
• revealing a card section,
• looking up a scenario result,
• drawing from a small thematic outcome deck.

Unknown outcomes should still be bounded and understandable, not arbitrary punishment.

The player should generally understand:

• approximate risk,
• potential reward,
• opportunity cost.

5. Core Game Structure

The initial prototype should use a short fixed structure.

Target:

• approximately 6–10 rounds,
• approximately 15–30 minutes total,
• approximately 2–3 minutes per round.

Possible round sequence:

1. Reveal / evolve the situation.
2. Players perform actions.
3. Resolve consequences and deadlines.
4. Advance scenario state.

The system should support experimentation with alternative structures, but this should be the initial baseline.

6. Characters and Players

Separate characters from human players.

The game may contain, for example:

• 3 characters,
• 4 characters,
• 5 characters,

regardless of the number of humans.

Examples:

Solo

One human controls 3–4 characters.

Two players

Each controls two characters.

Three players

Each controls one character, possibly with a shared fourth character.

Four or five players

Typically one character per player.

The rules engine should therefore operate on:

characters

rather than:

players

This simplifies:

• solo mode,
• balance testing,
• AI simulation,
• scaling.

7. Character Design

Characters should have very small rule footprints.

Preferred:

One primary ability per character.

Possibly later:

One ability + one passive trait.

Avoid:

• character-specific subsystems,
• individual resource economies,
• large player boards,
• many unique exceptions.

Example abilities:

• first movement each round is free,
• interacting with discoveries costs one less effort,
• may transfer an item over distance,
• can assist another character more efficiently,
• can inspect uncertain outcomes before committing,
• may perform one reaction during another character's action.

Abilities should create different tactical roles without creating separate games for each character.

8. Shared vs Individual Action Economy

This is an important design degree of freedom.

Several models should be supported experimentally.

Model A — Fixed actions per character

Example:

Each character gets 3 actions per round.

Advantages:

• simple,
• familiar,
• easy to balance.

Disadvantage:

• can feel like several individual turns rather than true cooperation.

Model B — Shared action pool

Example:

The team gets 10 actions per round and decides how to distribute them.

One character may consume:

• 1 action this round,
• 5 actions next round.

Advantages:

• highly cooperative,
• flexible,
• strategically interesting.

Risks:

• stronger quarterbacking,
• less individual player ownership.

This is currently a strong candidate for the core system.

Model C — Hybrid

Example:

Each character receives:

• 1 guaranteed personal action,

plus the team receives:

• 5 shared actions.

This may provide both:

• player agency,
• cooperative resource allocation.

The simulator should allow all three variants to be tested.

9. Turn Order

Another degree of freedom.

Possible models:

Sequential character turns

Character A completes its actions, then B, then C.

Simple but potentially less interactive.

Alternating single actions

Characters act one action at a time:

A → B → C → A → B → ...

Potential advantages:

• more interaction,
• more tactical combinations,
• less downtime,
• easier reaction to changing circumstances.

This is a strong candidate.

Free cooperative sequencing

Players choose which character acts next.

Example:

Character A moves → C activates something → A acts again → B assists.

Highly flexible, but potentially increases quarterbacking.

All models should be testable.

10. Interaction Between Characters

The game should contain direct cooperative mechanisms.

Examples:

• assistance,
• combined effort,
• transferring items/resources,
• movement support,
• reactions,
• chain actions,
• abilities that modify another character's action,
• positioning requirements,
• joint interaction with a situation.

The game should not become:

Several players independently optimizing their own character.

Players should frequently benefit from coordinating action sequences.

11. Avoiding Quarterbacking

A cooperative game risks one experienced player solving the entire game.

The design should test mechanisms that reduce this without creating unnecessary complexity.

Possible approaches:

Partial private information

Players may know some cards/resources that others do not.

Prefer soft secrecy:

"I have something useful for exploration."

rather than strict communication restrictions.

Character-specific decisions

Some decisions can only be made by the controlling player.

Reactions

Players can influence another player's turn through their own reactions.

Simultaneous commitment

Players choose one element before revealing choices.

Distributed information

Different players see different parts of a situation.

Avoid excessive communication restrictions unless testing demonstrates they are necessary.

12. Objectives

Winning should generally require active accomplishments.

Avoid a design based only on:

Survive until round 8.

Prefer:

Accomplish several objectives before the scenario ends.

Possible objective types:

• reach places,
• discover information,
• collect something,
• rescue or escort something,
• establish connections,
• complete projects,
• investigate,
• deliver,
• activate,
• negotiate,
• explore.

Different themes can reinterpret the same underlying mechanics.

13. Optional Opportunities

Not everything on the board should require resolution.

Situations should include genuinely optional opportunities.

Examples:

Investigate ruins for possible equipment.

Help a traveler and potentially gain information.

Take a dangerous shortcut.

Spend time studying an anomaly.

This creates important opportunity-cost decisions.

A useful recurring question should be:

Do we spend time on this, or continue toward the main objective?

14. Situation Lifecycle

A Situation should support a generic lifecycle.

Possible state:

hidden
↓
revealed
↓
available
↓
engaged
↓
resolved

Alternative transitions may include:

ignored
expired
escalated
transformed

The system should avoid assuming that expiration is always negative.

Example:

A traveling merchant leaves after two rounds.

Nothing disastrous happens; the opportunity simply disappears.

Another:

A storm grows stronger if ignored.

Another:

An unknown signal changes location.

Thus deadlines can create urgency without always being "threat meters."

15. Situation Schema

Content should be data-driven.

Example conceptual schema:

id: abandoned_station
type: situation

tags:
  - exploration
  - technology
  - uncertain

availability:
  duration: 2

interaction:
  cost:
    exploration: 2

outcome:
  type: hidden
  pool: abandoned_station_outcomes

priority:
  optional: true

A more deterministic situation:

id: damaged_bridge

tags:
  - infrastructure
  - movement

interaction:
  cost:
    repair: 3

success:
  unlock_route: true

expiration:
  block_route: true

The schema should remain generic enough to support very different themes.

16. Content Composition

Replayability should not rely only on having hundreds of independent cards.

Content should support compositional generation.

A scenario may combine:

situation
+
location
+
condition
+
modifier
+
possible outcome

Example:

Lost travelers
+
forest
+
during a storm
+
limited visibility

Another:

Unknown transmission
+
abandoned station
+
unstable power
+
possible survivor

This allows a relatively small card set to generate many combinations.

17. Compatibility Through Tags

Not every combination should be valid.

Use semantic tags.

Example:

environment
social
technical
exploration
transport
trade
rescue
mystery
danger
resource
discovery

A card may define:

requires_tags:
  - exploration

forbids_tags:
  - urban

The scenario generator uses these constraints to create coherent combinations.

18. Scenario Generator

Pure random card drawing should not determine the entire scenario.

Instead use a structured scenario generator.

Possible structure:

Opening

• primary objective,
• 1–2 active situations,
• one visible opportunity.

Development

• new opportunities,
• complications,
• discoveries,
• changing conditions.

Finale

• major choice,
• final objective,
• increased pressure,
• consequences of earlier decisions.

Example abstract structure:

phase_1:
  rounds: 1-2
  content:
    - situation
    - opportunity

phase_2:
  rounds: 3-5
  content:
    - escalation
    - discovery
    - dilemma

phase_3:
  rounds: 6-8
  content:
    - major_event
    - finale

The purpose is not to force a story but to maintain pacing.

19. Story Emergence

Narrative should ideally emerge from game state rather than long scripted text.

Prefer:

We ignored the damaged route, so later we could not reach a newly discovered opportunity in time.

over:

Read paragraph 37 describing what happened.

Cards may contain short narrative text, but gameplay should produce most of the story.

This also makes procedural combinations more natural.

20. Expansion Philosophy

A key design principle:

Expansions add content more often than rules.

A base game may contain:

• situations,
• objectives,
• characters,
• locations,
• modifiers,
• outcomes.

An expansion should ideally add:

• new cards,
• new scenarios,
• new characters,
• new thematic combinations,

without teaching another subsystem.

Examples:

Base Game
+ Storm Pack
+ Lost Expedition Pack
+ Night Pack
+ Wildlife Pack

Each expansion should use the same underlying grammar.

New mechanics should be exceptional rather than expected.

21. Difficulty

Difficulty should not primarily be controlled through luck.

Possible deterministic difficulty parameters:

• number of rounds,
• total available actions,
• starting conditions,
• number of simultaneous situations,
• objective requirements,
• expiration speed,
• resource scarcity.

Example:

Family
10 rounds
higher action budget

Standard
9 rounds
normal action budget

Hard
8 rounds
normal budget

Expert
8 rounds
lower budget + more demanding setup

The exact model should be discovered through simulation.

22. Difficulty vs Content Variability

Keep these separate.

Difficulty variability

Changes how hard the scenario is.

Content variability

Changes what happens and what story emerges.

A player should therefore be able to choose:

Difficulty: Standard

Content:
Base
+ Exploration Pack
+ Weather Pack

These should be orthogonal systems.

23. Web-Based Simulator

Build a browser-based simulator before investing heavily in physical production.

The simulator should initially be a game design laboratory, not a polished digital game.

Recommended architecture:

Game Engine
     ↓
Content Library
     ↓
Scenario Generator
     ↓
Player / Bot Interface
     ↓
Web UI
     ↓
Simulation & Analytics

24. Deterministic Game Engine

Game state must be completely serializable.

Example:

{
  "round": 3,
  "characters": [],
  "locations": [],
  "situations": [],
  "objectives": [],
  "resources": {},
  "history": [],
  "seed": 12345
}

Core engine API:

createGame(config): GameState

getLegalActions(state): Action[]

applyAction(
  state,
  action
): GameState

endRound(state): GameState

getGameResult(
  state
): "playing" | "win" | "loss"

Prefer pure or near-pure functions where practical.

25. Reproducibility

Every game should optionally use a deterministic random seed.

Example:

Seed: 184729

This allows developers to reproduce:

• unusual losses,
• broken combinations,
• difficult scenarios,
• AI mistakes,
• balancing anomalies.

A failed automated game should be replayable exactly.

26. Human Simulator UI

Initial UI should show:

Main board

• characters,
• locations,
• situations,
• objectives,
• available actions,
• round state.

Development/debug panel

• current seed,
• game state,
• legal actions,
• action history,
• active content packs,
• difficulty parameters.

Useful controls:

New Game
Undo
Redo
Restart Seed
End Round
Step Bot
Play Round
Auto Play

27. Simulation Mode

Support batch execution.

Examples:

Run 100 games
Run 1,000 games
Run 10,000 games

Simulation should ideally run independently of rendering.

This allows much faster automated testing.

28. Bot Interface

All players—human, deterministic bot, or LLM—should interact through the same conceptual interface.

Input:

{
  "state": {},
  "legalActions": []
}

Output:

{
  "actionId": "move_character_2_location_5"
}

The engine validates the action.

Bots must never modify state directly.

29. Baseline Bots

Implement simple baseline bots before LLM integration.

At minimum:

Random bot

Chooses a random legal action.

Useful as a lower baseline.

Greedy bot

Chooses actions with immediate measurable benefit.

Objective bot

Prioritizes progress toward primary objectives.

Risk-averse bot

Prioritizes preventing irreversible negative states.

Opportunity bot

Prioritizes optional rewards and discoveries.

These bots help identify whether game balance depends too heavily on one obvious strategy.

30. LLM Player

Add an optional LLM-controlled player.

Provide:

• summarized game state,
• legal actions,
• objective information,
• relevant history.

The model should choose among legal actions rather than invent arbitrary actions.

Possible response:

{
  "actionId": "assist_character_3",
  "reason": "This enables the team to complete the objective this round."
}

Reasoning should be stored for analysis but should not affect game rules.

31. Multi-Agent Testing

The system should support experiments such as:

One LLM controls the entire team

Useful for strategic evaluation.

One LLM per character

Useful for testing distributed coordination.

Mixed teams

Example:

LLM
+
Greedy bot
+
Human

Potentially useful for detecting whether cooperation mechanics remain understandable across different play styles.

32. Automated Design Metrics

Do not optimize only for win rate.

Track at least:

Win rate

By:

• difficulty,
• character combination,
• content packs,
• scenario type.

Game duration

In:

• rounds,
• actions.

Action distribution

Example:

move        21%
interact    31%
assist       7%
explore     18%
transfer     3%
other       20%

Rarely used actions may indicate weak mechanics.

Character contribution

Estimate how often each character:

• acts,
• uses abilities,
• advances objectives,
• changes game outcomes.

Situation interaction rate

Track:

• resolved,
• ignored,
• expired,
• failed,
• voluntarily abandoned.

If certain content is consistently ignored, its incentives may be weak.

Optional opportunity uptake

Important specifically for this game.

Measure:

How often do players choose optional opportunities when they could instead pursue the main objective?

Ideally this should vary depending on context.

Decision branching factor

Estimate how many viable actions exist at typical decisions.

Possible interpretation:

1 meaningful choice
→ probably too deterministic

2–5 meaningful choices
→ promising

15 meaningful choices
→ potentially overwhelming

Exact values should be validated empirically.

Resource/action efficiency

Measure wasted or unused capacity.

Failure cause

Classify losses where possible:

• insufficient objective progress,
• resource exhaustion,
• deadline failure,
• cascading situations,
• poor strategic allocation.

33. Detecting Dominant Strategies

Simulation should search for patterns such as:

• always prioritizing the main objective,
• always resolving every negative situation,
• always ignoring optional content,
• always using one character first,
• concentrating all shared actions on one character,
• exploiting a particular ability combination.

A robust game should generally reward adaptation rather than one universal strategy.

34. LLM Playtest Review

After each LLM-controlled game, optionally request structured feedback.

Questions may include:

• Which decision was most difficult?
• Which decision was obvious?
• Was any action rarely useful?
• Was any character disproportionately valuable?
• Did any situation feel irrelevant?
• Was the loss/win caused by strategy or randomness?
• Were there moments where multiple choices seemed genuinely viable?
• Was there any dominant strategy?

Aggregate feedback over many simulations rather than trusting individual reports.

35. Content Generation with LLMs

LLMs may also generate candidate content.

The model should generate structured objects matching a strict schema.

Example:

type: situation
theme: exploration

tags:
  - discovery
  - uncertain

interaction:
  exploration: 2

availability:
  rounds: 2

outcome_pool:
  - useful_discovery
  - neutral_information
  - complication

Generated content should never be accepted directly into production.

36. Content Validation Pipeline

Candidate content should pass several layers.

Schema validation

Check:

• valid fields,
• numeric ranges,
• allowed tags.

Mechanical validation

Check:

• achievable costs,
• compatible effects,
• no impossible references.

Similarity detection

Detect near-duplicate cards.

Automated simulation

Check effects on:

• win rate,
• action economy,
• strategic diversity.

LLM review

Check:

• narrative consistency,
• thematic appropriateness,
• obvious exploits.

Human review

Required before final inclusion.

37. Separation of Mechanics and Theme

The first implementation should intentionally use abstract terminology.

Example:

Character
Location
Situation
Objective
Resource
Effort
Opportunity
Condition

Avoid committing early to:

firefighter
wizard
spaceship
zombie

Once the mechanical system works, several themes can be prototyped against the same rules.

This should also reveal whether the rules are truly reusable.

38. Possible Theme Directions

Themes should support:

• movement or spatial relationships,
• discoveries,
• optional opportunities,
• uncertainty,
• cooperation,
• evolving situations.

Promising categories include:

Exploration

Expedition into unknown territory.

Space exploration

Crew exploring a region, station, or planet.

Adventure

Travel through a dynamic world.

Rescue expedition

More danger-oriented, but not necessarily purely negative.

Mystery expedition

Players discover clues and opportunities.

Ecological / scientific expedition

Observe, explore, respond, and collect knowledge.

Fantasy journey

Highly flexible narrative possibilities.

Theme selection should happen after the core prototype demonstrates good decisions.

39. Physical Components

The design should initially aim for low component complexity.

Potential base set:

• cards,
• character tokens,
• small number of generic tokens,
• modular location cards or small board,
• round marker.

Avoid requiring:

• dozens of resource types,
• large individual player boards,
• miniatures,
• complex bookkeeping.

The game should remain practical to prototype using paper cards and generic tokens.

40. Information Density

Target age is approximately 10+.

Cards should preferably contain:

• title,
• very short narrative,
• clear requirement,
• clear result or uncertainty indicator.

Avoid long paragraphs of rules.

Use iconography only once the concepts have stabilized.

41. Initial Prototype Scope

Do not create a full game immediately.

First playable prototype:

4 characters

6–8 locations

12–20 situations

3–5 objectives

approximately 10 modifiers/outcomes

one scenario generator

one difficulty setting

The purpose is to validate the core decision loop.

42. Prototype Success Criteria

Before expanding content, answer:

Decision quality

Are there usually multiple plausible actions?

Pressure

Can players do everything?

If yes, the game probably lacks tension.

Interaction

Do character combinations matter?

Opportunity cost

Are optional situations genuinely tempting?

Replayability

Do different setups lead to different decisions?

First-turn engagement

Is the first turn already interesting?

Duration

Can a complete game reliably finish in approximately 15–30 minutes?

Teachability

Can the core rules be explained in roughly 5 minutes?

43. Development Phases

Phase 1 — Formal model

Implement:

• GameState,
• actions,
• legal-action generation,
• round progression,
• situation lifecycle,
• objectives.

No final theme.

Phase 2 — Minimal web simulator

Allow one human to control all characters.

Include debug information.

Phase 3 — Automated simulation

Add:

• seeded randomness,
• random bot,
• heuristic bots,
• batch simulation,
• metrics.

Phase 4 — Tune the action system

Experiment with:

• individual action pools,
• shared action pool,
• hybrid system,
• turn order variants.

Choose the system producing the best combination of:

• strategic diversity,
• cooperation,
• simplicity.

Phase 5 — Situation and scenario systems

Introduce:

• optional opportunities,
• positive/mixed/negative situations,
• uncertainty,
• expiration,
• transformations,
• scenario pacing.

Phase 6 — LLM testing

Add:

• LLM player interface,
• playtest reports,
• batch AI testing.

Phase 7 — Theme experiments

Create several small content packs using identical rules.

Example:

Expedition
Space
Fantasy Journey

Compare which theme makes the mechanics feel most natural.

Phase 8 — Physical prototype

Convert stable digital content into printable cards.

Perform real family/group testing.

Phase 9 — Content expansion

Only after the core system works:

• expand card library,
• introduce modular content packs,
• improve scenario generation,
• generate more narrative diversity.

44. Important Degrees of Freedom

The implementation should deliberately keep the following configurable during experimentation:

These should primarily be configuration rather than hardcoded assumptions where practical.

45. Strong Initial Hypotheses

Some choices are worth using as the first implementation baseline.

Recommended initial defaults

Characters:
4

Rounds:
8

Action economy:
shared pool

Turn sequence:
one action at a time, flexible character order

Information:
mostly open

Situation outcomes:
mix of known, partially known, and hidden

Situations:
positive + negative + mixed + uncertain

Objectives:
active objectives rather than survival

Scenario:
structured phases

Randomness:
content selection rather than action success

Difficulty:
deterministic parameter changes

Expansions:
content-first, no new rules

Solo:
one player controls all characters

These are hypotheses, not fixed requirements.

Simulation and human testing should decide whether they remain.

46. Design Constraint

A useful guiding constraint for the entire project:

Complexity should live in combinations, not in rules.

Ideally the player learns a small number of mechanisms once.

Replayability then emerges from:

• different characters,
• different situations,
• different combinations,
• different objectives,
• timing,
• spatial state,
• uncertain opportunities,
• player decisions.

47. Desired Player Experience

A successful game should regularly create conversations such as:

"We could go there now, but then we will not finish the objective."

"If you help me first, I can reach the other location this round."

"That opportunity looks useful, but we do not know whether it is worth two actions."

"We can ignore this for now, but it may become important later."

"Last game this area was almost irrelevant; this time everything seems to depend on it."

Players should feel that the story emerged from their decisions rather than being imposed by a script.

48. Ultimate Design Goal

The finished system should achieve:

Low rules complexity + high combinatorial variety + meaningful cooperation + controlled uncertainty.

A player should be able to understand the game quickly, while still discovering new strategic situations after many plays.

The simulator should make it possible to test this systematically rather than relying only on intuition.

Most importantly, the design should not reduce the world to a sequence of crises that must be solved.

The core unit is an interesting situation:

something has appeared in the world, and the players must decide what—if anything—they want to do about it.

Sometimes it is a threat.

Sometimes it is an opportunity.

Sometimes it is both.

And sometimes the players will only discover which one it was after they chose to engage with it.