Addendum 2 — Physical-First Game Model, Spatial Systems and Entity Design

This document extends the original Cooperative Strategy Game & Simulation Platform specification and Addendum 1 — Simulation, Experimentation and AI Playtesting Architecture.

Addendum 1 is assumed to be already implemented or incorporated into the current architecture.

This document focuses primarily on a new requirement:

The game engine must remain directly transferable to a simple physical tabletop implementation.

The digital simulator may contain sophisticated analytics, AI agents, experiment infrastructure and derived calculations, but the actual playable game state should remain representable using a deliberately small set of physical primitives.

The goal is not to simulate reality precisely.

The goal is:

simple physical rules + strong spatial interaction + emergent strategic complexity.

1. Physical-First Design Principle

The game must not evolve into a digital design that later requires:

many counters,
numerical bookkeeping,
player dashboards,
large resource economies,
hidden digital state,
multiple status tracks,
paper-and-pencil recording,
a companion application.

The physical game must remain fully playable without software.

Every persistent gameplay state should therefore answer:

How would a player see this state on the table?

If there is no simple physical representation, this should be treated as a warning that the mechanic may be too complicated.

2. Physical State Primitives

The engine should deliberately prefer a small vocabulary of physical state representations.

Recommended primitive set:

type PhysicalPrimitive =
  | "card-zone"
  | "card-orientation"
  | "card-side"
  | "pawn-location"
  | "token-pool"
  | "token-on-card"
  | "die-value"
  | "deck-order";

This does not need to be implemented literally as this exact TypeScript union, but the conceptual restriction should influence domain modeling.

Derived information may exist digitally.

For example:

reachable locations
shortest path
remaining rounds
available actions
scenario difficulty

does not need physical representation because players can derive or calculate it from visible game state.

Persistent state should generally have one.

3. Target Physical Component Budget

The initial physical game should aim for approximately:

4–6 character pawns
30–50 cards
8–12 identical action/effort tokens
0–10 additional generic markers
0–2 six-sided dice

Do not interpret these as hard production limits.

They are design constraints intended to prevent unnecessary systems.

The first meaningful prototype should ideally work with approximately:

6 Character cards
4–9 Location cards
18–24 Situation cards
4–6 Objective / Scenario cards
a small number of system/reference cards
8–12 reusable Effort tokens
4–6 pawns

Expansion content should preferably add cards rather than new component types.

4. One Standard Card Format Where Practical

Prefer a shared standard card size for:

Characters,
Locations,
Situations,
Skills,
Items,
Vehicles,
Objectives,
Team Assets.

This simplifies:

home printing,
prototyping,
sleeving,
manufacturing,
replacement,
expansion packs.

Different card orientation or layout may communicate different types without requiring different physical dimensions.

5. Cards as State Machines

Cards should not only represent content.

Where practical, their physical state should represent game state.

Available mechanisms include:

card position
card zone
card orientation
card side
cards attached to another card
cards underneath another card

This should replace separate counters whenever it remains readable.

6. Card Orientation

A card can naturally represent several states.

Recommended semantic pattern:

0°   normal / ready / active
90°  temporary altered state
180° secondary / disabled / transformed state

Do not require four orientations everywhere.

The principle should be used only where intuitive.

Examples:

Situation
upright → active
sideways → urgent

Character
upright → ready
sideways → impaired
upside down → disabled

Ability
upright → available
sideways → used this round

Orientation should remain visually obvious across the table.

Avoid requiring players to distinguish subtle orientation differences.

7. Public Double-Sided Cards

True front/back state changes are especially useful for components already visible on the table.

Strong candidates:

Location:
normal ↔ changed

Vehicle:
operational ↔ damaged

Objective:
active ↔ completed

Public Situation:
state A ↔ state B

Example:

Open Pass
↕
Blocked Pass

or:

Village
↕
Evacuated Village

8. Hidden Decks Must Keep Uniform Backs

Do not place unique gameplay information on the reverse of cards drawn from a hidden deck if this would reveal future content.

Therefore:

Cards in hidden draw decks should normally share a common back.

For those cards, alternate state should instead use:

orientation,
placement into another zone,
attachment,
an associated generic marker,
or transformation into another card.

This distinction should be reflected in the content model.

9. Card Transformation

A card may change role during a game.

This is encouraged because it creates state without adding components.

Example:

Situation
↓
resolved opportunity
↓
personal Item

Situation
↓
discovery
↓
Team Asset

Situation
↓
location improvement
↓
Location Asset

A single card can therefore tell a small mechanical story.

Example:

Abandoned Workshop
↓
players investigate it
↓
Workshop Tools
↓
becomes a Team Asset

The engine should support entity/card transitions between zones and roles.

10. Zones as Gameplay State

Physical zones should carry meaning.

Possible zones:

Situation Deck
Discard
Active Situations
Character Inventory
Character Skills
Team Assets
Location Assets
Objectives
Out of Play
Completed / Resolved

Prefer:

move a card to a meaningful zone

instead of:

update a numeric property.

This also makes the table state readable at a glance.

11. Avoid Persistent Partial Progress by Default

The base game should generally avoid states such as:

Bridge repair 3 / 7
Research 2 / 5
Rescue 4 / 9

because every concurrent progress track requires additional physical bookkeeping.

Default interaction model should therefore prefer atomic resolution:

Repair requires 3 Effort.

Players either spend the required capacity during the relevant interaction or they do not complete it.

Persistent multi-round progress may exist for:

major objectives,
exceptional scenario elements,
deliberately important projects.

It should not be the default Situation model.

12. Avoid Long Countdown Tracks

Similarly, normal Situations should not require:

countdown markers.

Prefer a small lifecycle such as:

AVAILABLE
↓
URGENT
↓
RESOLVED / EXPIRED / TRANSFORMED

This can be represented physically by:

upright
↓
sideways
↓
move / flip / discard

A designer looking across the table should immediately recognize urgent content.

13. Shared Renewable Effort Pool

The base game should prefer a renewable round-based action economy over persistent money or resource accumulation.

Example:

At the start of a round:
Team receives 10 Effort.

During the round:
Spend Effort.

End of round:
All spent Effort returns.

Next round:
Start again with the same pool.

This is physically represented by a small number of identical tokens.

Possible costs:

basic action: 1
complex action: 2
exceptional action: 3

Avoid building the core game around large stocks of:

money
food
wood
fuel
energy
ore

unless a particular theme specifically requires one.

14. Effort Is Abstract Capacity, Not Literal Time

Even when one round represents:

one minute,
one hour,
one day,
one week,

one Effort does not need to correspond to a fixed amount of real-world time.

Effort represents:

how much meaningful coordinated activity the team can accomplish during that round.

This allows different thematic scales while preserving the same rules.

15. Dice Are Optional Inputs, Not Success Checks

The engine may support one or two standard d6 dice, but the base rules should not depend on:

choose action
↓
roll
↓
action succeeds or fails

This conflicts with the objective of minimizing luck-driven outcomes.

If dice are used, prefer:

roll first
↓
random input becomes visible
↓
players strategically decide how to use it

or:

interaction always succeeds
↓
die determines which discovery/outcome occurs

The engine should therefore support dice, but no core mechanic should require them.

16. Map Is a Graph, Not a Grid

The engine must not hardcode a rectangular board.

Represent geography as:

Location = graph node
Movement connection = graph edge

Coordinates or layout information are only presentation metadata.

Conceptually:

interface LocationNode {
  id: LocationId;
  tags?: string[];
  position?: PhysicalPosition;
}

interface MapEdge {
  from: LocationId;
  to: LocationId;
  tags?: string[];
}

17. Supported Map Geometries

The same engine should support examples such as:

2×2

■ ■
■ ■

2×3

■ ■ ■
■ ■ ■

3×3

■ ■ ■
■ ■ ■
■ ■ ■

1×6

■—■—■—■—■—■

Ring

  ■—■
 /   \
■     ■
 \   /
  ■—■

Bottleneck / H-style

■—■     ■—■
  |     |
  ■—■—■
  |     |
■—■     ■—■

Hub

    ■
    |
■ — ■ — ■
    |
    ■

Irregular graphs are explicitly supported.

18. Practical Map Size

Recommended range:

4–9 Locations

Typical scenarios may use:

6 Locations

Examples:

2×2

may work for:

tutorials,
very short games,
children learning the system.

6–7 Locations

may be the primary range.

3×3

may represent a larger or strategically more complex scenario.

Do not assume that larger thematic geography requires more cards.

A Location may represent:

a room,
station module,
neighborhood,
island,
country,
world region.

19. Geography Is a Strategic Variable

Different topology should affect play rather than merely appearance.

Examples:

Line

Encourages:

logistics,
relay movement,
transport planning.

Ring

Creates:

alternative routes,
fewer hard bottlenecks.

Hub

Creates:

central meeting point,
strong transfer location.

Bottleneck

Creates:

divided teams,
transport pressure,
control of a critical connection.

Grid

Creates:

flexible routing,
broad tactical positioning.

Scenario generation and automated testing should therefore treat map topology as a first-class parameter.

20. Map Analytics

The simulator should be able to derive:

graph diameter
average path length
shortest paths
bottleneck nodes
bridge edges
connectivity
distance from starting positions
distance to objectives

These metrics should support:

scenario validation,
difficulty estimation,
procedural placement,
A/B testing.

Do not require players to see these metrics.

21. Theme Scale Profile

Each thematic set should define its spatial and temporal abstraction.

Conceptually:

scale:
  locationMeaning: island
  roundMeaning: day
  mapExtent: archipelago
  defaultMovementMeaning: sailing

Another theme:

scale:
  locationMeaning: station-module
  roundMeaning: minute
  mapExtent: space-station
  defaultMovementMeaning: walking

Another:

scale:
  locationMeaning: world-region
  roundMeaning: week
  mapExtent: global
  defaultMovementMeaning: long-distance-travel

These values are primarily narrative metadata.

They should keep thematic content internally believable.

22. Relative Strategic Scale Should Remain Comparable

Themes may represent radically different real-world scales.

For example:

Pirates:
Location = island
Round = approximately one day

Space station:
Location = module
Round = approximately one minute

But the strategic scale can remain comparable:

crossing most of the map normally
≈ several meaningful actions

This allows the core mechanics to remain reusable.

A thematic set may intentionally deviate from this to create a distinctive feel.

23. Scenario Scale Validation

The scenario validator should eventually detect implausible or impossible combinations.

Example:

objective appears 4 normal moves away
expires this round
no suitable fast transport exists

Possible result:

potentially unreachable

This can be a warning rather than a hard error because intentionally impossible choices may sometimes be valid game design.

24. Mobility Envelope

For each scenario, the simulator should be able to estimate:

Which Locations can entity X reach
within 1 round?
within 2 rounds?
within 3 rounds?

This should account for:

topology,
movement profiles,
vehicles,
movement restrictions,
status.

Scenario generation can use this information when placing:

objectives,
urgent Situations,
optional opportunities.

25. Entity Model

Introduce or refine a generic physical entity concept.

Recommended conceptual hierarchy:

Entity
│
├── Character
├── Vehicle
└── Location Asset

Shared properties may include:

id
location
operational state
capabilities
tags

Do not force all entities to have identical behavior.

26. Characters

A Character typically has:

location
pawn
operational state
intrinsic ability
skills
carried items

A Character should generally have one primary defining ability.

Avoid large individual player boards.

Physical representation:

Character card
+
matching pawn

The pawn represents location.

The card represents:

identity,
abilities,
state,
owned Skills,
carried Items.

27. Character Pawn Colors

The physical implementation should support approximately:

4–6 distinct pawn colors

The engine must not assume exactly four.

Character cards should reference pawn identity separately from role identity.

This allows:

more Character roles than available simultaneously,
selecting 3–5 Characters from a larger Character pool.

The game should not require a unique custom miniature for each role.

Any distinguishable pawn/object can represent the Character.

28. Character Operational State

Characters should support a simple general state progression:

READY
↓
IMPAIRED
↓
DISABLED
↓
REMOVED

Not every theme or scenario must use every state.

29. Ready

The Character functions normally.

Physical representation:

Character card upright

30. Impaired

The Character has one simple disadvantage.

Examples depending on theme:

cannot use special ability
movement costs more
cannot perform a specific action type
reduced carrying capacity

Avoid stacking many penalties.

Physical representation:

Character card sideways

31. Disabled

The Character cannot perform some core activity independently.

Typical baseline:

cannot move independently
requires assistance

Possible interactions:

treat
assist
escort
transport

A Disabled Character should not normally mean:

player does nothing for several rounds.

The state exists to create cooperation, not player elimination.

Physical representation:

Character card upside down

32. Removed

REMOVED is a neutral terminal state for the current scenario.

It does not inherently mean death.

Possible thematic interpretations:

evacuated
lost
seriously injured
rescued
dead
escaped
captured
left the mission

The engine should use neutral terminology.

Example:

operationalState:
  | "ready"
  | "impaired"
  | "disabled"
  | "removed";

A theme may supply user-facing language.

33. Character Removal and Family-Friendly Themes

The engine should support permanent removal.

Individual thematic sets should decide whether to use it.

Family-oriented scenarios may map it to:

evacuated
unable to continue
taken to safety

rather than death.

A theme or scenario should be able to configure:

characterRemoval:
  enabled: false

or:

characterRemoval:
  enabled: true
  narrativeMode: evacuation

More serious themes may use a stronger interpretation.

34. Character Removal Must Not Mean Player Elimination

The engine already separates:

human player

from:

Character

Preserve this principle.

If a Character is permanently removed, the controlling human must still be able to participate.

Possible approaches:

shared control of remaining Characters,
reassignment to another Character,
control of a Vehicle or shared entity,
cooperative decision participation.

Do not design around eliminated players sitting idle.

35. Status as Strategic Cost

Negative state should not arise only as random punishment.

It may also be a deliberate strategic trade-off.

Example:

Safe route:
cost 3 Effort

Risky shortcut:
cost 1 Effort
Character becomes Impaired

Vehicle example:

Emergency flight:
perform one additional flight
Vehicle becomes Disabled afterwards

This allows operational state to act as a form of strategic risk without introducing another currency.

36. Recovery

Recovery should generally be accessible enough to prevent excessive death spirals.

Possible generic action:

restore(entity)

The content determines requirements.

Example:

Character restore:
Medical capability

Vehicle restore:
Technical capability

Possible transitions:

Disabled → Impaired
Impaired → Ready

Some effects may restore multiple levels.

37. Permanent Loss

Entities may transition:

Disabled → Removed

or exceptionally:

Ready / Impaired → Removed

Permanent loss should be supported for:

Characters,
Vehicles,
Location Assets,
scenario entities.

This enables irreversible decisions.

Example:

Use the damaged helicopter one final time, knowing that it will be lost after the flight.

This should be available to scenario designers, not automatically common.

38. Asset Categories

Use four primary ownership models.

38.1 Carried Item

A physical object owned/carried by a Character.

Examples:

rope
medical kit
scanner
radio
toolkit
artifact

Characteristics:

transferable
capacity-limited
located with Character

38.2 Skill / Knowledge

A learned or intrinsic non-physical capability.

Examples:

First Aid
Navigation
Engineering
Pilot
Negotiation
Tracking

Characteristics:

belongs to Character
normally non-transferable
does not use Item inventory

38.3 Team Asset

A shared capability or physical resource for which central ownership makes thematic sense.

Examples:

shared base
communication network
research database
large vehicle
camp
shared map

Team Assets should be used selectively.

Do not turn them into a generic shared inventory.

38.4 Location Asset

An improvement or capability tied to a specific place.

Examples:

repaired radio tower
supply cache
field hospital
bridge
safe house
observation post

A Location Asset remains associated with its Location.

This strengthens spatial gameplay.

39. Character Inventory

Recommended default:

2 carried Item slots per Character

This should be configurable by Character or theme.

Physical representation:

place Item cards adjacent to / underneath Character card

Avoid numeric weight calculations.

Prefer discrete slots.

40. Inventory Decisions

When capacity is full and a Character obtains another Item, possible choices include:

leave it
drop an existing Item
use an Item
transfer an Item
store it elsewhere

This creates meaningful logistics without resource bookkeeping.

41. Item Transfer

Default rule:

Characters at the same Location may freely exchange carried Items.

The meeting requirement itself provides the spatial cost.

Do not charge additional Effort for transfer by default.

A specific theme may override this if necessary.

42. Dropped Items

An Item may become associated with a Location instead of a Character.

Example:

Character drops Rope at Location C.

Physically:

place Rope card next to Location C.

Another Character arriving later may take it.

This provides useful emergent logistics.

43. Skills

Skills should not normally consume backpack capacity.

Do not initially impose a strict maximum number of Skills.

A 15–30 minute game is expected to naturally limit accumulation.

If simulation later identifies excessive skill concentration, address it through:

specialization,
acquisition conditions,
scenario incentives,

rather than arbitrary forgetting.

44. Capability Distribution

A central design goal is:

Assets belong to Characters, but their value belongs to the team.

The game should reward teams for distributing useful capabilities.

Avoid creating incentives for one Character to accumulate everything.

45. Capability Coverage

Content may use broad capability tags such as:

Mobility
Technical
Medical
Social
Observation
Survival
Navigation

The exact taxonomy should remain theme-configurable.

Scenario design should often reward diverse team coverage.

Example:

one Character has Technical ×4

should not universally dominate:

Technical + Medical + Navigation + Social

distributed across the team.

46. Development Cooperation

When a Situation produces a Skill or Item reward, do not automatically assign it to the Character who first encountered the Situation.

Allow rules such as:

reward recipient:
one participating Character

This enables:

one Character discovers an opportunity,

several Characters cooperate to resolve it,

the team deliberately gives the resulting Skill to the Character who benefits the team most.

This directly supports cooperative development rather than personal accumulation.

47. Soft Competition Without Individual Victory

It is acceptable and desirable for players to sometimes think:

"I would like that Item or Skill."

But the game should not reward:

"I personally become stronger than everyone else."

Avoid individual victory points.

The interesting tension should be:

I want this capability
vs.
the team is stronger if another Character receives it

48. Team Asset Capacity

When thematically appropriate, Team Assets may have limited capacity.

Recommended starting point:

maximum 2–3 active Team Assets

Obtaining another may require replacing one.

Example:

Vehicle cargo configuration
Base camp equipment
Shared tools

This creates strategic trade-offs while remaining physically visible.

49. Vehicles as Independent Entities

Do not model a Vehicle as a Character, even if the two share many properties.

A Character has agency.

A Vehicle is generally operated by Characters.

Recommended model:

Entity
├── Character
├── Vehicle
└── LocationAsset

50. Vehicle Properties

A Vehicle may contain:

location
operational state
movement profile
cargo capacity
passenger capacity
operator requirements
capabilities

Conceptually:

interface Vehicle {
  id: VehicleId;

  location: LocationId;

  status: OperationalState;

  movement: MovementProfile;

  cargoCapacity: number;

  passengerCapacity: number;

  requiredCapabilities?: CapabilityId[];
}

51. Vehicles as Mobile Containers

A Vehicle is mechanically a mobile shared container.

Example:

Jeep

Passenger capacity: 3
Cargo capacity: 4
Movement: Road / Range 2

Physical representation:

Vehicle card beside Location

Pawns associated with Vehicle = passengers

Item cards associated with Vehicle = cargo

When the Vehicle moves, passengers and cargo move with it.

52. Vehicle Cargo

Vehicle inventory should use discrete slots, not weight calculations.

Examples:

Character backpack:
2 Item slots

Jeep:
4 cargo slots

Helicopter:
3 cargo slots

Specific exceptional Items may consume multiple slots later, but do not require this initially.

53. Vehicle Passenger Capacity

Passenger capacity should likewise be a small integer.

Example:

Helicopter:
4 passengers

A Disabled Character should normally count as one passenger unless a theme explicitly says otherwise.

54. Vehicle Operator Requirements

Most ordinary Vehicles should avoid unnecessary skill restrictions.

Example:

car:
operator requirement = none

Specialized Vehicles may require:

Pilot
Sailor
Engineer
Operator

Example:

Helicopter:
requires Pilot

This creates meaningful Character specialization.

55. Character-Assigned Vehicles

A Character may start with an assigned Vehicle.

Example:

Rescue Pilot
starts with:
Rescue Helicopter

Keep the Character and Vehicle as separate entities.

This allows situations such as:

Pilot becomes Disabled
Helicopter remains at Location
Another Character with Pilot Skill may operate it

This is more flexible than combining both into one entity.

56. Vehicle Operational State

Vehicles use the same generic state model:

READY
IMPAIRED
DISABLED
REMOVED

Theme interpretation:

READY        operational
IMPAIRED     damaged
DISABLED     immobilized / grounded
REMOVED      destroyed / abandoned / lost

57. Vehicle Impairment

Use one simple consequence.

Examples:

movement costs +1 Effort

or

passenger capacity reduced

or

cannot use special movement ability

Do not stack multiple penalties unless a specific Vehicle requires it.

58. Disabled Vehicle

Default interpretation:

Vehicle cannot move.

Characters and cargo remain at its current Location.

A suitable Character may repair it.

59. Vehicle Removal

When a Vehicle is removed, associated cargo/passengers require a defined outcome.

Possible generic policies:

DROP
REMOVE_WITH_ENTITY
TRANSFER

Example:

Vehicle destroyed on land:
cargo drops at current Location

Vehicle lost at sea:
cargo removed

Vehicle evacuated:
cargo transfers to Base

The scenario/content defines the policy.

60. Character Removal and Inventory

Use the same generic policy for Character Items.

Example:

Character removed:
carried Items remain at current Location

or:

Character evacuated:
Items transfer to Base

Avoid hardcoding one universal behavior.

61. Movement Profiles

Movement should remain easy to understand physically.

Support three main movement archetypes.

Adjacent

move to a connected Location

Typical:

walking
basic movement

Range

move through up to N connections

Typical:

car
fast ship
train

Example:

range = 2

Direct

move directly to any compatible Location

Typical:

helicopter
aircraft
teleporter

62. Movement Modes

Connections and Vehicles may optionally use movement tags.

Examples:

foot
road
water
rail
air

Do not require every map to use multiple movement modes.

Simple themes may use only:

default

Movement tags exist to support themes where alternative mobility matters.

63. Vehicles May Reinterpret the Map

A Vehicle should not merely mean:

+1 movement

It may change which topology matters.

Examples:

Walking

uses normal graph edges.

Car

travels farther along road-compatible edges.

Boat

uses water connections.

Train

uses rail-compatible routes.

Helicopter

may ignore normal edges.

This creates strategic variety without changing the underlying map representation.

64. Direct / Global Movement

A Vehicle may support:

move to any Location

if the theme scale makes the travel-time difference negligible compared with one round.

Example:

regional rescue scenario
round = approximately one hour
helicopter = any Location

This is valid.

The game does not need kilometre-level simulation.

65. Fast Movement Requires a Constraint

A Vehicle that ignores normal topology should usually have at least one meaningful restriction.

Possible restrictions:

requires Pilot
higher Effort cost
limited passenger capacity
once per round
unavailable while Impaired
specific compatible Locations

Avoid introducing fuel currencies unless the theme genuinely needs them.

Prefer renewable or state-based constraints.

66. Transporting Disabled Characters

A Disabled Character cannot normally move independently.

Possible options:

Assisted movement

Another Character escorts them.

Example:

normal Move = 1 Effort
assisted Move = 2 Effort

Vehicle transport

Disabled Character occupies passenger capacity normally.

This creates cooperative rescue situations without new component types.

67. Location Determines Access

One central strategic principle is:

Location determines access.

Where a Character currently is determines:

what they can interact with,
which Items they can pick up,
whom they can assist,
whom they can trade with,
which Vehicle they can use.

68. Character Determines Capability

Second central principle:

Character determines capability.

Skills, Items and role abilities determine:

what interactions are efficient,
what Vehicles can be operated,
what entities can be restored,
which opportunities can be exploited.

69. Cooperation Connects Access and Capability

Third principle:

Cooperation connects location and capability.

Typical emergent problem:

Needed Item is with Character A.
Required Skill belongs to Character B.
Situation is at Location C.
Vehicle is at Location D.

The interesting game is deciding how to recombine these pieces efficiently.

This should be considered a core source of strategic depth.

70. Cooperation Modes

The engine should support several forms of cooperation through the same underlying systems.

Capability cooperation

Different Characters contribute different abilities.

Spatial cooperation

Characters need to meet or reach the same Location.

Inventory cooperation

Characters deliver and exchange Items.

Development cooperation

Characters help others acquire Skills or Assets.

Recovery cooperation

Characters restore impaired/disabled allies.

Transport cooperation

Characters use Vehicles to move people and equipment.

No separate subsystem is necessary for each.

71. Situation Placement

Situations should normally be associated with:

a Location

or occasionally:

the entire scenario
a Character
a Vehicle

Physical default:

place Situation card adjacent to Location card

This keeps world state readable.

72. Situation Lifecycle

Continue supporting:

hidden
revealed
available
engaged
resolved
ignored
urgent
expired
transformed

Physical implementation should normally use:

deck
zone
orientation
card movement

rather than status counters.

73. Situation Rewards

Situation outcomes may produce:

Item
Skill
Team Asset
Location Asset
Vehicle
information
scenario change
objective progress

The recipient/placement should be explicitly defined.

Examples:

give to one participating Character
place at current Location
add to Team Assets
introduce Vehicle at current Location

74. Positive, Negative and Ambiguous Situations

Preserve the original neutral Situation concept.

Content may represent:

opportunity
danger
discovery
request
visitor
weather
shortcut
trade
mystery
failure
crisis

Do not make the physical state model assume that every active card is a threat.

75. Physical Representation of Situation Urgency

Recommended:

upright = available
sideways = urgent / final opportunity

Then:

resolve
expire
transform
discard

This replaces countdown markers in most cases.

76. Objectives

Objectives should also use card state where possible.

Example:

upright = incomplete
flip / rotate / move = completed

Avoid separate progress counters unless the Objective intentionally requires multi-stage completion.

77. Round Tracking

Prefer one small round tracker.

Possible implementations:

one Round card + marker

or

small sequence of Round cards

or

rotating single tracker card

Do not use a large dedicated board merely to track time.

78. Theme-Specific Physical Vocabulary

A thematic set may use different narrative names for the same engine entities.

Example:

Character → Crew Member
Vehicle → Ship
Location → Island
Situation → Encounter
Effort → Time

Another:

Character → Specialist
Vehicle → Shuttle
Location → Module
Situation → Event
Effort → Capacity

The underlying rules remain unchanged.

79. Theme Pack Responsibilities

Each thematic pack should define:

world scale
map topology/templates
Location content
Character pool
Situation content
Objectives
Skills
Items
Vehicles
Team Assets
Location Assets
narrative labels

It should preferably not add new engine mechanics.

80. Theme Scale Contract

Each thematic pack should be able to answer:

What does one Location represent?
What does one Round represent?
What does one normal Move represent?
How many normal Moves cross most of the map?
What fast transport exists?
Can anything bypass normal topology?
What usually expires in one Round?
What usually lasts several Rounds?
What counts as personal inventory?
What counts as shared cargo?

If these answers do not form a coherent model, the theme requires redesign.

81. Example — Pirates

theme: pirates

scale:
  locationMeaning: island-or-sea-region
  roundMeaning: approximately-one-day
  normalMoveMeaning: sail-to-nearby-island

map:
  size: 6
  preferredTopologies:
    - ring
    - branching
    - irregular

mobility:
  default: adjacent
  vehicles:
    - ship

inventory:
  characterSlots: 2

vehicle:
  shipCargoSlots: 5

Possible Situation timing:

passing merchant:
1 round

approaching storm:
2 rounds

major expedition:
several rounds

82. Example — Space Station

theme: space-station

scale:
  locationMeaning: station-module
  roundMeaning: approximately-one-minute
  normalMoveMeaning: walk-through-corridor

map:
  size: 8
  preferredTopologies:
    - grid
    - ring
    - hub
    - bottleneck

mobility:
  default: adjacent

Possible fast movement:

service lift
internal shuttle
teleport system

Situation timing:

closing airlock:
1 round

reactor instability:
2–3 rounds

83. Example — Regional Rescue

theme: rescue

scale:
  locationMeaning: region
  roundMeaning: approximately-one-hour
  normalMoveMeaning: ground-travel

map:
  size: 6

mobility:
  default: adjacent

vehicles:
  - car
  - helicopter

Possible profiles:

Car:
Range 2 along roads

Helicopter:
Direct to any Location
requires Pilot
capacity 4

84. Physical Compilation Requirement

Introduce the concept:

The GameState must be physically compilable.

For every persistent state variable, it should be possible to explain how it appears on a physical table.

Example mapping:

Engine State	Physical Representation
Character location	pawn on Location
Vehicle location	Vehicle card at Location
Character status	Character card orientation
Vehicle status	Vehicle card orientation/side
Item ownership	Item next to Character
Skill ownership	Skill attached to Character
Vehicle cargo	Item attached to Vehicle
Vehicle passengers	pawns associated with Vehicle
Situation active	card at Location
Situation urgent	rotated Situation
Location changed	opposite card side
Asset acquired	card moved to owner/zone
Team Asset	central asset zone
Location Asset	card beside Location
remaining Effort	tokens in available pool
spent Effort	tokens in spent pool
objective completed	flipped/moved Objective
entity removed	remove from map / Out-of-Play zone
hidden future	deck order
random visible input	d6

85. Physical State Validation

The simulator may eventually provide a development/debug feature that lists:

persistent state fields
↓
their declared physical representation

Potential warning:

Field:
situation.progress = 4

No physical representation declared.

This should not necessarily fail the build.

It should help detect accidental digital-only complexity.

86. Complexity Budget

Introduce a conceptual physical complexity budget.

For the base game, aim for:

1 shared renewable action resource
1 basic Character status mechanism
1 inventory mechanism
1 Skill mechanism
1 map movement mechanism
1 Situation lifecycle mechanism
0–1 dice mechanisms

Avoid simultaneously introducing:

health
energy
money
fuel
food
ammo
morale
experience points

unless future testing demonstrates a strong need.

87. Base Game Limits

Recommended initial limits:

Characters in scenario:
3–5

available Character roles:
approximately 6–8

Locations:
4–9

typical Locations:
6

simultaneous active Situations:
approximately 3–4

carried Items per Character:
2

Team Assets:
maximum approximately 3

Objectives:
approximately 1–3 active

persistent currencies:
0 by default

dice:
0–2 optional

These should be configurable but treated as default complexity constraints.

88. Expansion Constraint

A normal content expansion should preferably require:

cards only

or:

cards + optional generic replacements

It should normally not require:

a new resource type
new dice
a new board
new tracker type
new miniature category

unless the expansion deliberately breaks this rule for a compelling reason.

89. Content-First Expansion Philosophy

Expansion should primarily add:

Locations
Characters
Situations
Objectives
Items
Skills
Vehicles
Assets
map layouts
scenario templates

rather than additional rules.

A new thematic set can feel significantly different by changing:

scale
topology
mobility
Character specialization
content distribution
Vehicle availability
Situation timing

while preserving the same engine.

90. Physical Setup Definitions

Scenario definitions should be able to include physical layout instructions.

Example:

map:
  layout: custom
  nodes:
    - id: A
      row: 1
      column: 1

    - id: B
      row: 1
      column: 2

    - id: C
      row: 2
      column: 2

  edges:
    - [A, B]
    - [B, C]

The UI may render this graph digitally.

Printable scenario instructions can show the same arrangement visually.

91. Topology Templates

Support reusable templates such as:

grid-2x2
grid-2x3
grid-3x3
line-4
line-6
ring-6
hub-5
bridge-6
double-cluster
custom

Theme packs may prefer or restrict certain templates.

92. Scenario Generator and Geography

The Scenario Generator should understand semantic spatial properties.

Examples:

central location
remote location
bottleneck
edge location
cluster
far from start
near starting team

This allows intentional content placement.

Examples:

urgent opportunity near one Character

major Objective beyond bottleneck

repair Asset in central Location

Vehicle starts in remote cluster

93. Geography and Content Generation

Do not distribute Situations completely uniformly by default.

Scenario templates should be able to request patterns such as:

one remote Objective
one nearby Opportunity
one Situation at a bottleneck
one Vehicle outside starting area

This creates spatial stories rather than random clutter.

94. Status and Geography Interaction

Entity state should affect mobility naturally.

Examples:

Impaired Character:
cannot use fast personal movement

Disabled Character:
cannot move independently

Impaired Vehicle:
reduced movement

Disabled Vehicle:
cannot move

Removed Vehicle:
no longer exists on map

These interactions should remain explicit and simple.

95. Vehicle and Skill Interaction

Skills may unlock Vehicle use.

Example:

Pilot
→ operate Helicopter

Another Character may possess:

Mechanic
→ restore Vehicle

Another:

Medic
→ restore Character

This naturally creates cooperative dependency without special teamwork rules.

96. Avoid Hardcoded Character Roles

The engine should not contain functions such as:

if (character.type === "pilot") ...

Use capabilities:

can-operate-air-vehicle
can-restore-character
can-restore-vehicle

User-facing content may label these:

Pilot
Medic
Mechanic

This keeps the engine thematic-neutral.

97. Avoid Hardcoded Vehicle Types

Likewise, do not hardcode:

car
helicopter
boat

into core mechanics.

Represent them using:

movement profile
capacity
operator requirements
tags

Themes provide the narrative identity.

98. Physical Readability Is More Important Than Simulation Precision

When deciding between:

more realistic

and:

easier to understand on the table

prefer tabletop clarity unless realism materially improves decisions.

Examples to avoid:

exact kilograms
fuel consumption per kilometre
movement speeds in km/h
precise treatment timers
multiple injury types

Prefer:

2 inventory slots
Range 2
Direct movement
Impaired
Disabled

99. One-Look Table State

An important usability target:

A player should be able to look at the table and understand most of the current game state without reading a dashboard.

They should visually recognize:

where everyone is
what Situations exist
which ones are urgent
who is impaired
which Vehicle is available
who carries what
what Assets the team has
how much Effort remains

This is especially important for approximately age 10+.

100. Engine vs Physical Rules

The engine may internally calculate sophisticated information.

For example:

pathfinding
effective choice count
scenario difficulty
trajectory metrics
AI evaluation

These are not physical game mechanics.

Maintain a strict separation between:

simulation intelligence

and:

player-facing rules

The physical game should stay simple even if the simulator becomes sophisticated.

101. Simulation Metrics to Add

Extend Addendum 1 analytics with physical/spatial metrics.

Recommended:

map diameter
average travel distance
movement actions per game
travel Effort
bottleneck usage
Character separation
meeting frequency
Item transfer frequency
Vehicle usage
passenger utilization
cargo utilization
Vehicle dependency
recovery actions
entity impairment frequency
entity removal frequency

102. Capability Distribution Metrics

Also measure:

capability concentration
team capability coverage
Skill distribution
Item distribution
Character contribution

Important question:

Does the system reward creating one super-Character?

If yes, flag for review.

Preferred behavior:

useful capabilities naturally spread across the team because spatial position, inventory limits and specialization make distribution advantageous.

103. Cooperation Metrics

Possible metrics:

number of assists
Item transfers
shared interactions
recovery actions
passenger transport
multi-Character Situation resolutions
reward assigned to another Character

These can help measure whether the game actually generates cooperation rather than only shared victory conditions.

104. Transport Metrics

For each Vehicle track:

uses
distance bypassed
passengers transported
cargo transported
Effort spent
Situations enabled
Objectives enabled
time saved
downtime due to damage

This can reveal whether a Vehicle is:

essential
useful
irrelevant
dominant

105. Status Metrics

For Characters and Vehicles:

time Ready
time Impaired
time Disabled
removal frequency
recovery frequency
average recovery delay

Watch for:

death spirals

where early impairment disproportionately guarantees failure.

106. Removal Risk

Permanent removal should normally be uncommon in family-oriented content.

Simulation should flag scenarios where:

Character removal occurs too frequently

or:

one early removal nearly guarantees loss

The threshold should remain content-specific.

107. Human Playtest Questions

Physical playtests should specifically evaluate:

Can players understand card orientation quickly?

Do they forget to rotate cards?

Is inventory ownership visually obvious?

Is it obvious who is inside a Vehicle?

Are Location connections easy to read?

Can players see urgent Situations from across the table?

Do Items create table clutter?

Can children understand the difference between Item and Skill?

Does Character status feel intuitive?

Do players naturally help distribute capabilities?

These cannot be validated by automated simulation alone.

108. Implementation Priorities

Incorporate these changes incrementally.

Priority 1 — Physical state audit

Review existing GameState.

For every persistent field, identify:

physical representation
or
derived/digital-only information

Flag fields with no reasonable physical representation.

Priority 2 — General map graph

Ensure map representation supports arbitrary graph topology.

Remove assumptions tied to a fixed 2×3 matrix.

Support:

4–9 nodes
custom edges
optional layout coordinates

Priority 3 — Entity operational state

Add/refine:

READY
IMPAIRED
DISABLED
REMOVED

for applicable entities.

Do not hardcode thematic labels.

Priority 4 — Asset ownership model

Support:

Carried Item
Skill
Team Asset
Location Asset

and physical ownership/location.

Priority 5 — Character inventory

Implement discrete Item capacity.

Recommended default:

Support:

pickup
drop
transfer when co-located

Priority 6 — Vehicles

Introduce independent Vehicle entities with:

location
status
movement
cargo
passengers
operator requirements

Priority 7 — Movement profiles

Support:

Adjacent
Range N
Direct

plus optional movement compatibility tags.

Priority 8 — Theme scale metadata

Add Theme/Scenario scale description:

location meaning
round meaning
movement meaning
map extent

Do not introduce real-world unit calculations.

Priority 9 — Physical state-oriented UI

Update the web simulator so it visually resembles the intended tabletop state where practical:

cards
orientation
zones
pawns
attached Items
Vehicles

Avoid introducing UI-only state representations that could not exist physically.

Priority 10 — Spatial and cooperation analytics

Add the metrics described above after the rules are stable.

109. Non-Goals

Do not currently implement:

kilometre-based movement
exact travel duration
continuous coordinates
weight simulation
fuel economy
complex damage systems
body-part injuries
large health tracks
large skill trees
large personal inventories
multiple currencies
player-specific victory points

These conflict with the intended physical simplicity unless a future experiment strongly justifies them.

110. Core Physical Design Rules

Use these as default review criteria for future mechanics.

Rule 1

Persistent state should usually be visible on the table.

Rule 2

Prefer moving, rotating or flipping an existing card over adding another marker.

Rule 3

Prefer slots over numeric capacity.

Rule 4

Prefer renewable per-round capacity over accumulating currencies.

Rule 5

Prefer one meaningful state transition over several numeric damage/progress points.

Rule 6

Map topology should generate strategy without requiring extra rules.

Rule 7

Character capabilities should be spatially meaningful.

Rule 8

Vehicles should change mobility and logistics, not create a separate simulation game.

Rule 9

Different themes may radically change narrative scale while keeping the same mechanical grammar.

Rule 10

Complexity should emerge from combinations of simple entities, not from exceptions.

111. Updated Core Gameplay Model

The emerging physical game can now be summarized as:

WORLD
4–9 Location cards connected as a graph

CHARACTERS
3–5 active Characters represented by pawns + Character cards

CAPABILITIES
intrinsic abilities
Skills
limited carried Items

TRANSPORT
optional Vehicles
passengers
cargo
alternative movement

WORLD CONTENT
Situation cards located in the world

OBJECTIVES
active team goals

ACTION ECONOMY
one renewable shared Effort pool

STATE
primarily represented through:
position
orientation
card side
card zone
ownership

112. Updated Strategic Model

The central strategic relationships are:

Map topology determines access.

Character location determines immediate opportunity.

Character capabilities determine what can be done efficiently.

Items and Skills distribute capability across the team.

Inventory limits prevent unlimited personal accumulation.

Vehicles redistribute Characters and equipment across the map.

Operational state can temporarily or permanently remove capabilities.

Cooperation reconnects capabilities that have become spatially separated.

This should produce complex tactical situations from a relatively small ruleset.

113. Updated Cooperation Goal

The design should specifically encourage behavior such as:

help another Character gain a useful Skill

give a useful Item to the Character who needs it more

travel to meet another Character and exchange equipment

use a Vehicle to transport a specialist

rescue or restore a disabled teammate

sacrifice a personal opportunity to improve team capability coverage

The system should make these behaviors strategically useful rather than merely socially encouraged.

Without turning the game into an explicit educational exercise, the mechanics may naturally reinforce:

shared success
specialization
mutual support
resource sharing
helping others develop
recognizing different strengths
interdependence

A desirable strategic lesson is:

The strongest team is not necessarily the team with one strongest Character.

Instead:

A resilient team distributes capabilities and enables its members to support one another.

This should emerge through gameplay rather than instructional text.

115. Final Constraint

The central implementation constraint from this addendum is:

Every new game mechanic should be evaluated both as software and as a physical tabletop operation.

Before adding a persistent property, ask:

How does a player see it?
How does a player change it?
How many components does it require?
Can a 10-year-old understand the transition?
Can the table state be restored from the physical components alone?

If the answer requires:

remembering hidden numbers
writing values down
many specialized markers
checking a companion application

prefer a simpler representation.

116. Target Result

The physical game should ultimately feel richer than its component count suggests.

A typical game state may consist only of:

6 Location cards
3–5 Character pawns
3–4 active Situation cards
3–5 Character cards
a few attached Item / Skill cards
0–2 Vehicle cards
1–3 Objective cards
a small Effort token pool

Yet the interactions between:

topology
distance
specialization
inventory
transport
status
timing
opportunities
objectives

should produce substantially different strategic situations between games.

That is the core objective of this physical-first extension:

Keep the table simple enough for a family game while allowing the combinations of location, capability, ownership, mobility and changing state to generate the strategic depth.