Addendum 3 — Exploration, Hidden Information and Knowledge State

This document extends the original Cooperative Strategy Game & Simulation Platform specification, Addendum 1 — Simulation, Experimentation and AI Playtesting Architecture, and Addendum 2 — Physical-First Game Model, Spatial Systems and Entity Design.

This addendum introduces a more explicit distinction between:

• what exists in the game world,
• what players currently know,
• what can be inferred from partial information,
• and what becomes known only through exploration.

The goal is to strengthen exploration and discovery without introducing a new resource economy or additional physical component types.

The central principle is:

The world may already contain information and Situations that players do not yet know about.

1. Core Design Change

Do not assume that all cards, Situations, Items, Assets or opportunities associated with a Location are automatically visible from the start of the game.

By default, players should often know:

where a Location is
what broad type of Location it is
how it connects to other Locations

without necessarily knowing:

what is currently there
what can be discovered there
whether an opportunity exists there
whether something dangerous is happening there
which Items or Assets may be present

This allows movement and exploration to generate information rather than functioning only as logistical costs.

2. World State vs Knowledge State

The authoritative engine state and player-visible state must be conceptually distinct.

The existing architecture from Addendum 1 already separates:

GameState

from:

Observation

This addendum makes that separation strategically important.

The authoritative GameState may know:

Situation X exists at Location C
Item Y exists at Location D
Location E contains hidden content

while the player's current Observation may only show:

Location C exists
Location D exists
Location E has not been explored

The engine must never rely on the UI to hide information.

Hidden information belongs in the domain model.

3. Knowledge Levels

Use a small and understandable knowledge model.

Recommended default states:

UNKNOWN
SIGNALED
REVEALED

These should describe knowledge of content, not necessarily the Location itself.

4. Unknown

UNKNOWN means:

The team does not know the specific content.

Example:

Forest
Content: unknown

The Location may still be visible and known.

Players simply do not know what they will find there.

5. Signaled

SIGNALED means:

The team knows that something relevant is present, but does not yet know its exact nature.

Examples:

smoke visible in the distance
distress transmission
movement detected
unknown ship
strange signal
storm front
possible survivor
unidentified structure

A signal may reveal selected information such as:

Location
general category
urgency
approximate risk
expiration

while hiding:

exact Situation
exact requirements
exact reward
exact consequences

6. Revealed

REVEALED means:

The relevant content is known to the team.

Its card and gameplay properties are now visible normally.

Once revealed, information should usually remain known for the rest of the scenario.

Do not automatically hide content again when Characters leave the Location.

7. Location Knowledge and Content Knowledge Are Separate

A Location may be completely known while its contents remain unknown.

Example:

Location:
Harbor

Known:
Harbor exists.
Harbor connects to Town and Island.

Unknown:
What is currently at the Harbor?

This distinction should be explicit.

Possible conceptual model:

interface LocationKnowledge {
  locationKnown: boolean;
  explored: boolean;
}

and separately:

interface ContentKnowledge {
  state: "unknown" | "signaled" | "revealed";
}

Do not necessarily implement these exact interfaces if the current architecture has a better representation.

Preserve the distinction.

8. Default Map Model

The recommended default for the base game is:

Known geography, unknown local content.

At scenario start:

• map topology is visible,
• Location cards are visible,
• Characters know where they may travel,
• some or most local content remains hidden.

This provides exploration without making navigation unnecessarily confusing.

9. First Visit

Recommended baseline rule:

When a Character enters an unexplored Location for the first time, that Location becomes explored and its local hidden content is revealed.

This should initially happen automatically.

Example:

A — B — C

A explored
B explored
C unexplored

Character moves:

B → C

Result:

C becomes explored
hidden Situation is revealed

This makes exploration a natural consequence of movement without adding another mandatory action.

10. Optional Explicit Explore Action

The engine may support a more detailed rule variant:

enter Location
↓
basic information becomes visible
↓
spend Effort to Explore
↓
full content is revealed

This can create interesting decisions such as:

"We reached the Location, but do we have time to investigate it?"

However, this is not recommended as the default until playtesting demonstrates that the additional action improves the game.

The simpler default should remain:

first visit = reveal

11. Hidden Content Should Exist Before Discovery

From the engine and simulation perspective, prefer:

scenario generation
↓
hidden world content assigned
↓
players begin
↓
exploration reveals existing content

rather than:

player enters Location
↓
engine invents random content

This distinction is important for:

• reproducibility,
• seeded simulation,
• counterfactual analysis,
• fair comparison between agents,
• coherent scenario construction.

The narrative interpretation should be:

The content was already there. The team simply did not know about it.

12. Physical Implementation Options

Several physical representations are acceptable.

The scenario may choose whichever works best.

Option A — Face-Down Local Card

Place hidden content face down at the Location.

Advantages:

• content physically exists from the start,
• discovery is tangible,
• deterministic scenario layout is easy,
• players can see that something unknown exists.

Disadvantage:

Players know that something is there.

Option B — Draw on Exploration

No card is placed initially.

When a Location is first explored:

draw its assigned / appropriate hidden card

Advantages:

• players may not even know whether anything is present,
• table remains cleaner.

The engine should still treat the content as preassigned where deterministic simulation requires it.

Option C — Hidden Scenario Packet / Assigned Content

Scenario setup defines hidden content without showing it to players.

Digital simulation stores this directly.

Physical scenarios may represent it through:

• numbered cards,
• shuffled scenario stacks,
• hidden setup instructions,
• envelopes or other optional mechanisms.

Do not require complex physical packaging for the base game.

13. Unknown Does Not Mean Empty

An unexplored Location should not communicate:

nothing is happening there.

It communicates:

the team does not currently know what is there.

This distinction should remain consistent in UI and terminology.

14. Observable World Situations

Not all content should require physical presence to become known.

Some Situations are naturally observable remotely.

Examples:

large storm
visible fire
blocked bridge already reported
incoming vessel
radio transmission
system alarm
known political event
meteorological warning
station-wide power failure

These may become visible immediately regardless of Character location.

15. Visibility Policy

Content should support a generic visibility policy.

Recommended conceptual values:

LOCAL
SIGNALED
OBSERVABLE

16. Local Visibility

LOCAL

The content becomes visible when appropriate exploration occurs.

Typical examples:

hidden cave
abandoned supplies
injured traveler
local merchant
unknown machinery
tracks
small discovery

17. Signaled Visibility

SIGNALED

Some information becomes globally visible, while details remain hidden.

Example:

Signal:
Distress call detected at Location D.

Known:
location
expires in 2 rounds

Unknown:
who is there
what they need
what reward/consequence exists

This should be a major source of strategic uncertainty.

18. Observable Visibility

OBSERVABLE

The content is immediately visible to the team.

Examples:

storm
public objective
global alarm
large fire
major infrastructure failure
known incoming ship

This preserves the feeling that the world acts independently of Character exploration.

19. Signals as Strategic Information

Signals should not exist only as flavor.

They may communicate useful partial state.

Possible signal properties:

Location
category
urgency
potential reward
potential danger
required capability hint

Do not reveal all information by default.

Example:

Unknown medical signal
Location: East Station
Urgency: high
Expires: next round

The team must decide whether enough is known to justify intervention.

20. Exploration Creates Decisions

Exploration should create strategic questions such as:

Do we continue toward the known Objective?

Do we investigate the unexplored Location?

Do we respond to the unknown signal?

Do we send the nearest Character?

Do we first gather information remotely?

Do we use fast transport for reconnaissance?

Do we ignore the opportunity?

The value of exploration should come primarily from information and optionality rather than random rewards.

21. Information Is a Resource Without Tokens

Knowledge becomes strategically valuable but does not require a new currency.

Players gain information by:

moving
exploring
scouting
using Skills
using Items
using Vehicles
resolving Situations

The state is represented through:

hidden card
revealed card
partial signal

No information points or knowledge tokens are required by default.

22. Scouting

Support mechanisms that reveal information without requiring a Character to physically enter the Location.

Possible sources:

Skill
Item
Vehicle
Team Asset
Location Asset
Situation outcome

Examples:

Binoculars:
Reveal local content in an adjacent Location.

Drone:
Reveal one unexplored Location within range 2.

Radio:
Reveal additional information about one Signaled Situation.

Scout:
The first remote inspection each round costs no Effort.

Satellite:
Reveal one distant signal at the start of each round.

These abilities create qualitatively new decisions instead of merely numeric bonuses.

23. Scouting Should Not Necessarily Equal Full Reveal

Support several inspection strengths.

Example:

detect
identify
fully reveal

A Drone may convert:

UNKNOWN → SIGNALED

while physical exploration converts:

SIGNALED → REVEALED

This enables different information-oriented capabilities.

Do not introduce more than a small number of knowledge levels.

24. Vehicles and Reconnaissance

Vehicles may have strategic information roles in addition to transport.

Example:

Helicopter
Direct movement to any Location
+
rapid reconnaissance

The team might use a Vehicle to:

• reveal a remote Location,
• inspect a signal,
• transport a specialist after reconnaissance,
• determine whether a long journey is worthwhile.

This strengthens the interaction between:

mobility
information
time

25. Exploration Skills and Roles

Some Character roles may specialize in information.

Examples:

Scout
Navigator
Observer
Sensor Specialist
Investigator
Tracker

Prefer capabilities such as:

reveal information
reduce exploration cost
inspect farther away
gain better signal detail

rather than generic:

+1 exploration

when possible.

26. Knowledge Persists

Default rule:

Once information is revealed to the team, it remains known.

Do not re-hide Situation cards merely because no Character remains there.

This reduces memory burden and avoids artificial fog-of-war.

Exceptions may exist if explicitly thematic:

moving enemy
changing weather
unknown mobile entity
temporary sensor contact

but these should be exceptional.

27. New Hidden Content May Appear in Explored Locations

An explored Location is not permanently exhausted.

Future game events may create new hidden or signaled content there.

Example:

Harbor explored in round 1.

Round 5:
Unknown ship arrives.

The Location remains known, but the new Situation may begin as:

SIGNALED

or:

UNKNOWN

depending on visibility rules.

28. Exploration and Situation Lifecycle Are Separate

Do not conflate:

Location unexplored

with:

Situation hidden

A Location may be explored while containing newly hidden content.

Likewise, a Situation may be observable in a Location nobody has visited.

The engine should represent these separately.

29. Exploratory Geography

The engine may optionally support a stronger exploration model where even the map topology is partly unknown.

Example:

A — B — ?

Exploring B may reveal:

A — B — C
        |
        D

This can support themes such as:

jungle expedition
cave exploration
unknown planet
dungeon
ocean exploration

However:

Unknown geography is optional and should not be the default base-game model.

It introduces significantly more uncertainty and physical setup complexity.

30. Known Geography Should Remain the Default

For most themes:

map known
content partly unknown

offers the best balance between:

• strategic planning,
• exploration,
• simplicity,
• physical readability.

Players can make route decisions while still discovering meaningful content.

31. Scenario Generator Changes

The Scenario Generator should distinguish:

world placement

from:

player knowledge

Example:

situations:
  - id: abandoned-camp
    location: forest-east
    visibility: local

  - id: distress-call
    location: harbor
    visibility: signaled

  - id: major-storm
    location: global
    visibility: observable

All three may exist at scenario start.

Players simply receive different observations.

32. Scenario Generation Must Avoid Knowledge Leaks

Do not expose hidden content through:

card identifier
card count
UI labels
unique backs
debug text
legal-action names
LLM prompts
analytics metadata

unless running in explicit designer/debug mode.

For example, do not generate a legal action:

Investigate injured scientist

when the player only knows:

Investigate unknown signal

Legal actions themselves form part of the Observation.

33. Agent Observation

AI agents must receive only information currently available to their role/team.

Example:

interface AgentContext {
  observation: Observation;
  legalActions: LegalAction[];
}

The Observation must respect:

UNKNOWN
SIGNALED
REVEALED

states.

Do not accidentally give LLM agents hidden authoritative state.

34. Omniscient Analysis Mode

For game-design analysis, the simulator may intentionally support:

omniscient observer

This may inspect:

• hidden Situation identity,
• true future content,
• assigned random outcomes.

This is for:

debugging
analytics
scenario inspection

not ordinary player or agent decision-making.

Make this distinction explicit.

35. Counterfactual Analysis and Hidden Information

When evaluating a historical player decision, distinguish between:

information the player actually had

and:

information the simulator knows retrospectively

The system should avoid evaluating decisions as if the player knew hidden outcomes.

For example:

Going west was reasonable given the signal.

must remain distinguishable from:

Going east would have produced the better hidden reward.

This is critical for fair strategy analysis.

36. Exploration Should Not Become Pure Gambling

Avoid:

spend several actions travelling
↓
reveal card
↓
nothing useful

as a frequent outcome.

Exploration should usually provide some form of value.

Possible value:

new Situation
Item
Skill opportunity
information
shortcut
map change
Location Asset
Objective
new route
future advantage
risk knowledge

Not all discoveries must be positive.

But discovery should usually change what players know or can meaningfully decide.

37. Negative Discovery Can Still Be Valuable

Example:

Players discover that the eastern route is blocked.

This is not a reward.

But it provides valuable strategic information before the team commits more resources.

Likewise:

dangerous creature discovered

may be negative, but learning its presence early can improve planning.

Design exploration around:

information value

not only:

loot value.

38. Empty Discoveries

Completely empty Locations may exist, but should be used sparingly.

If used, they should serve a design purpose such as:

creating uncertainty
establishing safe routes
providing spatial shortcuts
supporting thematic realism

Frequent empty exploration risks making movement feel wasted.

39. Hidden Outcome vs Hidden Situation

Keep these concepts separate.

Hidden Situation

Players do not yet know what they have encountered.

Example:

Unknown signal
↓
reveal
↓
Stranded scientist

Hidden Outcome

Players know what the Situation is, but not exactly how it will resolve.

Example:

Abandoned laboratory
known interaction:
Search it.

unknown outcome:
equipment / information / complication

Both systems may coexist.

40. Multiple Uncertainty Layers

Avoid stacking too many uncertainty layers simultaneously.

For example:

unknown Location
+
unknown Situation
+
unknown requirement
+
random success
+
unknown reward

would make decisions almost meaningless.

A useful design principle:

Players should usually know enough to make an informed gamble.

Uncertainty should create tension, not remove agency.

41. Information Gradient

Situations may progressively reveal information.

Example:

UNKNOWN
↓
signal detected

SIGNALED
"Someone needs help at Location E."
↓
scouted

SIGNALED+
"Medical assistance probably required."
↓
visited

REVEALED
"Injured traveler — Medical 2."

The exact implementation may still use only three formal states.

Additional details can be attached to the SIGNALED state.

42. Signals and Urgency

A Signaled Situation may have a deadline before full reveal.

Example:

Distress signal
Expires in 2 rounds.

Players must decide:

investigate
scout remotely
ignore

before knowing the exact reward or requirement.

This is a strong form of controlled uncertainty.

43. Physical Representation of Signals

Signals should remain physically simple.

Possible representations:

Generic face-down Situation card

The card's back communicates:

unknown Situation

possibly with a generic category icon.

Signal card

A generic card such as:

DISTRESS SIGNAL

is placed at the Location.

When investigated, replace or reveal it with the actual Situation.

Orientation / partial reveal

Where card production permits it, a visible section may communicate limited information.

For the initial physical prototype, prefer the simplest reliable method.

44. Do Not Require Unique Hidden Card Backs

As established in Addendum 2:

Hidden decks must use uniform backs.

Do not encode secret information through unique card backs unless the information is intentionally visible.

Generic signal cards or neutral hidden cards are preferred.

45. Exploration and Physical Component Budget

This addendum should not substantially increase component count.

It should primarily reuse:

Location cards
Situation cards
Character pawns
card orientation
card zones
existing decks

Potential additional component:

a very small number of generic "unknown / signal" markers or cards

This should remain optional.

If the same state can be represented through face-down cards, prefer that.

46. Exploration State on Locations

If the game needs to distinguish explored and unexplored Locations physically, prefer a simple method.

Possible options:

Location side

front = unexplored
back = explored

Only appropriate if flipping does not conflict with other Location states.

Orientation

sideways = unexplored
upright = explored

Only if orientation is not already used.

Hidden local content

No separate exploration marker is needed:

face-down content exists = unexplored
content revealed = explored

This is often preferable.

Do not add dedicated exploration tokens unless necessary.

47. Avoid Overloading One Physical Dimension

Do not use card orientation simultaneously for:

unexplored
urgent
damaged
used

on the same card type.

Each card category should have a clear physical grammar.

Example:

Character orientation → operational state

Situation orientation → urgency

Location side → major Location state

content face-up/down → knowledge

This keeps the tabletop readable.

48. Recommended Physical Grammar

A useful default mapping is:

This should be treated as a strong default.

49. Exploration as a Core Strategic Pillar

The updated game now has several interacting pillars:

TIME
SPACE
CAPABILITY
INVENTORY
STATUS
INFORMATION

Information should be treated as equally important as the others.

However, it should not require its own numeric resource.

50. Updated Strategic Relationship

The previous core relationship was:

Location determines access.

Character determines capability.

Cooperation connects the two.

Extend this to:

Knowledge determines which opportunities the team can plan around.

Therefore:

Exploration converts unknown world state into strategic options.

51. Information and Mobility Interaction

Fast mobility should naturally increase information-gathering power.

Example:

Scout on foot
→ cheap local exploration

Helicopter
→ expensive but global reconnaissance

Drone
→ remote reveal without transporting a Character

Radio
→ better information about signals

This helps differentiate mobility assets without simply increasing movement distance.

52. Information and Specialization Interaction

Different Characters may contribute differently to discovery.

Examples:

Scout:
reveals Locations efficiently

Scientist:
reveals more detail about anomalies

Navigator:
predicts routes / geography

Medic:
recognizes medical signals

Mechanic:
identifies technical Situations before arrival

This creates specialization while preserving team-level information sharing.

53. Knowledge Is Normally Shared

Default cooperative rule:

Once one Character discovers information, the whole team may use it.

Avoid physically tracking separate knowledge for each player unless a specific theme requires it.

This keeps the game cooperative and manageable for children.

The architecture may technically support actor-specific knowledge, but team-shared knowledge should be the default.

54. Optional Character-Specific Knowledge

The engine may support Character-specific observations for advanced themes.

Examples:

radio communication unavailable
Characters separated
secret information
deduction scenario

This is explicitly optional.

Do not introduce it into the base game unless playtesting demonstrates a strong benefit.

55. Scenario Pacing Through Discovery

The Scenario Generator may use hidden content to control pacing.

Example:

Opening

Players see:

main Objective
known map
one visible Situation
several unexplored Locations

Development

Exploration reveals:

opportunities
secondary Objectives
Assets
new complications

Finale

Previously discovered elements may:

transform
escalate
become relevant to final Objective

This creates narrative development without scripted paragraphs.

56. Discovery Should Create Story Continuity

Where possible, later events should reference earlier discoveries.

Example:

Players discover abandoned radio tower.
↓
Repair it.
↓
Later it reveals a distant distress signal.

or:

Players rescue navigator.
↓
Navigator becomes Team Asset / Skill source.
↓
Later enables shortcut.

This strengthens emergent narrative.

57. Hidden Content and Content Packs

Content expansions can add replayability through:

new hidden Situations
new signals
new discovery outcomes
new Location contents
new scouting Assets

without introducing new rules.

This fits the existing content-first expansion philosophy.

58. Scenario Seeding

Hidden world setup must be reproducible.

A scenario seed should deterministically define:

hidden content assignment
signal placement
Location content
hidden outcomes where applicable

This allows two agents to face the same hidden world.

They should only differ in:

decisions
information acquired
timing

unless the experiment intentionally varies randomness.

59. Paired Exploration Experiments

The simulator should support experiments such as:

same hidden world
same Character setup
same scenario

Agent A:
explores aggressively

Agent B:
focuses known Objectives

Agent C:
uses scouting first

Compare:

success
Effort spent
information acquired
optional opportunities found
travel distance
risk exposure

This can reveal whether exploration is actually strategically meaningful.

60. Exploration Metrics

Add analytics such as:

Locations explored
round of first exploration
hidden Situations revealed
signals investigated
signals ignored
remote scouting uses
Effort spent on exploration
travel spent on exploration

61. Information Value Metrics

Where practical, estimate:

information gained
subsequent strategy change
opportunities enabled
risks avoided
travel avoided

Do not attempt a perfect mathematical definition initially.

Start with observable proxies.

62. Exploration Efficiency

Possible metric:

useful discoveries
/
exploration investment

But do not automatically optimize for maximum efficiency.

A less efficient path may generate better narrative diversity.

Expose the data rather than making design decisions automatically.

63. Signal Conversion Metrics

For Signaled content track:

signals created
signals investigated
signals remotely identified
signals fully revealed
signals expired
signals ignored

Also record how often signals cause:

route change
Vehicle use
team split
Character reassignment

These are strong indicators of strategic relevance.

64. Hidden Content Quality

For hidden Situation cards track:

reveal frequency
engagement frequency
ignore-after-reveal frequency
average exploration cost
average reward
average strategic impact

Watch for cards that produce:

high travel cost
low strategic value

too consistently.

65. Surprise Without Unfairness

One design objective should be:

Players may be surprised by what they discover, but should rarely feel that the game punished them arbitrarily for information they could not possibly have obtained.

The design should distinguish:

interesting uncertainty

from:

unavoidable hidden punishment

This is particularly important for a family-oriented game.

66. Avoid Mandatory Blind Guessing

Do not routinely present:

three completely indistinguishable hidden Locations
one contains major reward
one contains catastrophic punishment

with no meaningful information.

Prefer giving players:

• signals,
• geography,
• thematic clues,
• scouting tools,
• risk categories.

The decision should contain some reasoning.

67. Hidden Information and Randomness

Remember the original rule:

Randomness should create the puzzle, not decide whether the chosen action succeeds.

Hidden content follows the same principle.

Good:

You do not know exactly what is at the Location.
You decide whether exploration is worth the cost.
Once there, your chosen interaction behaves predictably.

Less desirable:

You spend several actions reaching the Location.
Roll a die.
On 1–3 nothing happens.

68. Default Exploration Model

Use the following as the initial default implementation:

Map:
known

Location identities:
known

Local content:
mostly hidden

First visit:
automatically reveals local content

Knowledge:
shared by team

Revealed information:
persistent

Remote scouting:
supported through capabilities

Global/observable Situations:
visible immediately

Signals:
partial information before full reveal

This should be treated as the baseline to test.

69. Optional Exploration Variants

The engine should remain capable of supporting:

explicit Explore action

partly unknown map

Character-specific knowledge

multiple levels of scouting

moving hidden entities

re-concealed information

but these should not complicate the default implementation.

70. Required Engine Review

Review the current implementation for assumptions such as:

all Situations are globally visible

all Location contents are visible

legal actions may reveal hidden identities

bots receive authoritative state

scenario generation creates content only when visited

Refactor where necessary.

71. Required Data Model Additions

Introduce or refine concepts equivalent to:

visibility policy

knowledge state

exploration state

signal information

reveal conditions

Exact naming should fit the existing architecture.

Avoid unnecessary parallel models if equivalent abstractions already exist.

72. Suggested Visibility Model

A possible conceptual schema:

type VisibilityPolicy =
  | "local"
  | "signaled"
  | "observable";

type KnowledgeState =
  | "unknown"
  | "signaled"
  | "revealed";

Example content:

id: stranded-scientist

location: research-module

visibility:
  policy: signaled

signal:
  label: distress-signal
  reveal:
    - location
    - urgency

fullReveal:
  trigger: character-enters-location

This is illustrative rather than mandatory syntax.

73. Reveal Conditions

Content may specify reveal conditions such as:

Character enters Location
Character performs Explore
remote Scout effect
specific Skill used
specific Item used
round reached
other Situation resolved
scenario event occurs

Keep the initial set small.

Avoid arbitrary scripting for ordinary cards.

74. Information Revealed by Signals

A signal should explicitly control which fields are visible.

Possible fields:

category
urgency
Location
rough difficulty
required capability hint
potential reward type

This prevents accidental all-or-nothing information design.

75. Physical Compileability

All knowledge states must remain physically representable.

Examples:

Do not require a digital fog-of-war system for normal play.

76. Physical Simplicity Check

Before adding an information mechanic, ask:

Can players represent this by revealing, replacing, moving or turning a card?

Will they remember what is known?

Can the information state be reconstructed after the table is disturbed?

Does it require separate notes?

Does it require remembering something that is no longer visible?

Prefer visible physical state.

77. UI Changes

The web simulator should visually distinguish:

unknown content
signaled content
revealed content

without exposing hidden debug information.

Designer/debug mode may optionally show the true content.

Player mode must not.

78. Scenario Inspector

Extend the existing Scenario Inspector to show:

true hidden content
visibility policy
current knowledge state
reveal conditions
signal payload

This should help designers understand:

what exists,

versus:

what the team currently knows.

79. Replay UI

When replaying a game, support at least two perspectives:

Player View

Shows only information available at that historical moment.

Designer View

Shows authoritative hidden state.

This is useful for evaluating whether a decision was reasonable given available knowledge.

80. LLM Playtesting

LLM agents should be specifically evaluated for how they handle uncertainty.

Possible review questions:

Did the agent overvalue unknown opportunities?

Did it ignore useful signals?

Did it behave as if it knew hidden information?

Did scouting meaningfully change its decisions?

Was the signal information sufficient for a reasoned choice?

81. Human Playtesting

Add exploration-specific questions:

Did players understand what was known and unknown?

Was a face-down card interpreted correctly?

Did players find exploration exciting or frustrating?

Did they feel punished by hidden information?

Did signals provide enough information?

Did players use scouting abilities?

Did exploration change route planning?

Did children understand the difference between:
"nothing is there"
and
"we do not know what is there"?

This distinction is especially important.

82. Main Risk — Too Much Uncertainty

The game already contains:

limited Effort
map topology
Character specialization
inventory
Vehicle logistics
operational state
Situation timing

Exploration should add richness without obscuring everything.

A useful target is:

Players should usually have a mix of known priorities and uncertain opportunities.

Do not make the whole board unknown.

83. Main Risk — Information Becomes Mandatory Chore

Scouting should not become:

always scout every Location before moving.

If that is universally optimal, the system creates repetitive overhead.

Balance scouting through:

Effort cost
limited range
once-per-round capability
opportunity cost
partial information

Sometimes scouting should be useful.

Sometimes moving directly should be better.

84. Main Risk — Exploration Is Always Optimal

Similarly, optional unknown Locations should not always contain enough value that players must explore all of them.

The intended decision is:

sometimes explore
sometimes ignore
sometimes scout first
sometimes return later

The simulator should explicitly test this.

85. Main Risk — Exploration Is Never Worth It

The opposite failure mode is equally problematic.

If the main Objective always dominates optional exploration, hidden content becomes decorative.

Track:

exploration rate
opportunity engagement
success correlation
strategy diversity

and adjust content incentives accordingly.

86. Updated Physical Gameplay Model

With this addendum, a typical board may look conceptually like:

[LOCATION A]      [LOCATION B]      [LOCATION C]
 revealed          revealed          unexplored

 [Situation]        [Signal ?]

    ● A                ● B


[LOCATION D]      [LOCATION E]      [LOCATION F]
 unexplored         revealed          unexplored

                    [Vehicle]
                       ● C

Only the visible state is physically represented.

The hidden authoritative world exists in:

scenario setup
deck order
face-down cards

87. Updated Strategic Pillars

The game now combines:

SPACE
Where can we go?

TIME
What can we accomplish before things change?

CAPABILITY
Who can do what?

INVENTORY
Who carries what?

MOBILITY
How can Characters and Items move?

STATUS
Who or what is currently operational?

INFORMATION
What do we actually know?

The strategic depth should emerge from interactions between these pillars rather than additional rule layers.

88. Updated Core Principle

The previous principle:

Location determines access. Character determines capability. Cooperation connects the two.

should now become:

Location determines access.

Knowledge determines what the team can plan around.

Character determines capability.

Mobility determines how capabilities can be repositioned.

Cooperation reconnects knowledge, location and capability.

89. Updated Narrative Principle

A Situation does not need to appear because the team entered the Location.

Narratively:

The Situation may already have existed. Exploration merely makes it part of the team's known world.

This should remain the conceptual distinction even when the physical implementation draws the card only upon arrival.

90. Implementation Priorities

Apply this addendum incrementally.

Priority 1 — Observation audit

Verify that hidden information is genuinely excluded from player/agent observations.

Priority 2 — Visibility model

Introduce:

LOCAL
SIGNALED
OBSERVABLE

or equivalent.

Priority 3 — Knowledge state

Support:

UNKNOWN
SIGNALED
REVEALED

for relevant world content.

Priority 4 — First-visit discovery

Implement the baseline:

first Character visit
→ reveal local hidden content

Priority 5 — Persistent shared knowledge

Revealed information remains visible to the team.

Priority 6 — Signals

Allow partial information without full Situation reveal.

Priority 7 — Scouting capability

Allow Skills/Items/Assets to reveal information remotely.

Priority 8 — Scenario generation

Preassign hidden content independently of exploration.

Priority 9 — Analytics

Add exploration and information metrics.

Priority 10 — Optional advanced geography discovery

Only after the baseline model works, experiment with hidden map topology.

91. Non-Goals

Do not currently introduce:

complex fog-of-war
memory-based hidden information
large decks of clue tokens
per-player note taking
mandatory secret objectives
constant re-hiding of content
random success checks for exploration
procedurally generated content that cannot be reproduced

92. Final Design Constraint

The exploration system should satisfy all of the following:

The world can exist independently of player presence.

Players do not automatically know everything in the world.

Discovery has strategic value.

Information is physically visible once acquired.

Exploration does not require another currency.

Hidden information does not dominate player agency.

The same system works in physical and digital play.

AI agents operate only on information they are legitimately allowed to know.

93. Target Experience

The game should naturally produce conversations such as:

"We know something is happening on the western island, but we do not know what."

"Do we send someone there, or use the drone first?"

"The main objective is east, but this signal expires next round."

"We discovered a shortcut here last game; this time the Location contained something completely different."

"Now that we know what is there, we should send the Character with the right Skill."

This adds exploration and curiosity without requiring another major rules subsystem.

The intended result is:

A world that feels larger than the visible cards because some of its state exists beyond the team's current knowledge, while every important discovery still becomes a simple, tangible change on the physical table.