Map Tiles, Fog of War, and Cartography

Purpose

This file defines the actual map exploration model for the MMO.

Survey expeditions should not only return vague text or route flags. They should produce structured tile knowledge, fog-of-war clearing, and tradable cartography data.

Core Rule

The game world should be explored as tile knowledge, not as a fully revealed static map.

Players can:

• reveal tiles for themselves
• record tiles into chart data
• verify old tiles again when they become stale
• share or sell charted tile information if they have enough Cartography skill

That keeps exploration valuable over time and gives Survey expeditions a concrete output.

Map Hierarchy

Use three map layers:

1. Region Map

This is the planning layer.

• shows major regions, towns, roads, coastlines, and known landmarks
• used for route planning and board browsing
• does not need fine-grained local detail

2. Area Tile Grid

This is the main exploration layer.

• each explorable area is a tile grid
• survey, route travel, and site discovery update tile knowledge here
• fog of war is applied at this layer

3. Site Footprint

This is the point-of-interest layer.

• ruins, dens, springs, ore seams, and camps occupy one or more tiles
• site footprints can be hidden, partial, discovered, or stale

The authoritative backend cares about tile ids and site ids. The client can render them with richer art.

Tile Model

Each tile should have at least:

• area_id
• tile_x
• tile_y
• terrain_family
• elevation_band
• movement_class
• hazard_tags
• visibility_tags
• site_ref if present
• resource_hint if present
• drift_score

The game does not need to show every field to the player. Most of these are resolver data.

Fog Of War States

Each player or guild should track tile knowledge in bands.

unknown

• tile is hidden by full fog
• no route planning detail
• no trusted site information

rumored

• tile is not fully charted, but the player has hearsay or low-confidence data
• can show vague biome, rough risk, or rumor icons
• should not count as reliable survey completion

revealed

• tile has been meaningfully seen or traversed by the player
• enough detail exists to use it personally
• not yet guaranteed as a shareable trade good

charted

• tile has been recorded into a map item or archive entry
• detail is high enough to share, sell, or use for contracts
• should include freshness and confidence values

stale

• tile was charted before, but drift, weather, raids, monster movement, or time make the data less reliable now
• still useful, but marked with caution

Survey Expedition Outputs

Survey expeditions should reveal structured tile results instead of only generic knowledge gains.

Typical outputs:

• route strips of revealed tiles
• local clusters around discovered sites
• hazard notes for specific tiles
• site footprints
• freshness and confidence changes on already known tiles

Different survey jobs should reveal different shapes of knowledge:

Route Survey

• reveals a corridor of tiles between two known points
• improves route confidence and travel safety

Area Sweep

• reveals a tile cluster around a target area
• good for hidden sites, monster dens, and gather spots

Site Verification

• refreshes a previously charted site and nearby tiles
• mainly used to fight staleness

Emergency Recon

• reveals only urgent risk tiles such as washed roads, bandit routes, plague zones, or monster pressure pockets
• lower detail, higher urgency

Skill Split

Exploration should use two distinct but related skills:

Surveying

Surveying is about finding, confirming, and traversing.

It improves:

• tile reveal amount
• route confirmation
• hidden site discovery
• confidence on field findings

Cartography

Cartography is about recording, packaging, and sharing knowledge.

It improves:

• how many revealed tiles can be saved into map items
• map precision and freshness retention
• hazard notes and annotations
• copy quality when maps are traded or archived

Cartography Threshold Rule

The player should not automatically be able to monetize every discovered tile.

Recommended progression:

• Untrained or Familiar: can personally reveal tiles but cannot create high-quality chart items
• Practiced: can save specific tiles and short route strips into shareable chart data
• Skilled: can package contiguous tile clusters and annotate hazards or site notes
• Expert: can produce cleaner copies, merge reports, and reduce staleness loss on shared maps
• Master: can create highly trusted archive-grade maps with strong precision and long freshness

This is the main reason Cartography should exist as its own skill.

Knowledge Quality Model

Every charted tile, route, or site record should carry three distinct values:

• confidence: how likely the information is correct
• freshness: how recently it was verified
• precision: how exact the tile bounds, route corridor, or site approach is

Recommended responsibility split:

• Surveying mostly improves discovery confidence and hidden-site confirmation
• Cartography mostly improves recorded precision, annotation depth, and freshness retention
• fast-changing areas such as coasts, monster dens, depleted resource sites, and event zones should lose freshness faster than stable roads or civic tiles

Suggested formulas:

confidence = field_result_quality + surveying_bonus + verification_bonus - hazard_penalty freshness_loss = base_drift × area_change_rate × event_multiplier × copy_penalty

Map Item Types

Use structured cartography goods instead of generic text notes.

tile_snapshot

• one tile or a very small cluster
• useful for hazard reports, rare nodes, or contract proof

route_chart

• ordered tile corridor between two points
• useful for travel safety and caravan work

map_sheet

• contiguous block of charted tiles
• useful for exploration trade and guild archives

site_chart

• site footprint plus surrounding approach tiles
• useful for ruins, dens, springs, seams, and seasonal sites

Each cartography item should store:

• tile bounds
• detail level
• confidence rating
• freshness value
• annotations
• creator identity
• secrecy or sharing permissions

Reading or trading a chart should use those values rather than a flat rarity tag. A beautifully recorded but stale map should behave differently from a rough but freshly verified field sketch.

Copy and Lineage Rules

A chart item should remember whether it is an original field record or a copy.

• source surveys create generation 0 originals
• every copy increments copy_generation
• copies can never exceed the source item's confidence, freshness, or precision
• copied annotations should degrade before core tile bounds do

Recommended copy loss by Cartography band:

Crafter Band	Confidence Loss	Freshness Loss	Annotation Loss
Practiced	15	15	loses one detailed annotation layer
Skilled	10	10	keeps hazards, drops fine notes first
Expert	5	5	nearly complete copy
Master	2	2	archive-grade copy

After generation 3, most map goods should be poor trade stock unless reverified in the field.

Sharing And Trade

Cartography data should move through multiple channels:

• direct trade
• guild archives
• expedition group auto-share
• contract attachments
• market sale of map goods where allowed

Important rule:

• personal revealed knowledge is not automatically public
• only charted knowledge can become a tradable or shareable object

That keeps exploration and cartography distinct and valuable.

Access and Sharing Permissions

Map items and archives should support explicit permission scopes:

• private
• party
• guild
• contract-limited
• public sale

Rules:

• personal revealed knowledge stays private until charted into an item or archive record
• expedition auto-share should create permissioned chart records, not leak permanent global knowledge
• guild archives store shared copies or deposited originals, depending on guild policy
• contract-limited maps should expire or revoke access when the contract closes if the design wants secrecy to matter

Guild Archive Rules

Guild archives should keep both provenance and a usable merged read model.

• every submission should record contributor, submission time, and source generation
• the archive should keep the immutable submitted version plus the current best merged version
• archive permissions should be separable from guild treasury or officer permissions
• archives never refresh automatically; only new survey or verification work updates them

Knowledge Import and Merge Rules

Acquiring a map item should update player knowledge without pretending the player personally visited the area.

• high-confidence, fresh charts grant charted knowledge
• middling charts grant rumored knowledge with usable route hints
• stale charts import as stale
• bought or copied charts never count as revealed; only personal travel or survey does

When multiple charts disagree, merge in this order:

1. highest freshness
2. highest confidence
3. highest precision
4. newest archive entry as tiebreaker

If two nearby sources conflict within close quality bands, mark the affected tiles or site as disputed and queue them as strong candidates for Site Verification or Route Survey.

Drift And Reverification

Map knowledge should not stay perfect forever.

Tiles can become stale because of:

• raids
• storms
• monster migration
• depleted resource sites
• new public works or destroyed roads
• magical or corruption events

Reverification should be a normal reason to run Survey expeditions.

Use tiered drift rates so staleness feels believable.

• stable road and civic tiles: slow drift
• frontier travel corridors and common resource sites: medium drift
• coasts, monster territory, raid-prone roads, and event zones: fast drift
• active crisis or magical anomaly zones: extreme drift until reverified

Any world event that changes roads, resource supply, monster pressure, or town building state should be allowed to write direct freshness loss to nearby tiles.

Client Model

The Phaser client should render the map as tile knowledge, not as one giant painted image.

Recommended rules:

• use chunked tile loading for area maps
• render terrain and props in tile layers
• render fog as a separate overlay layer
• render stale tiles with a distinct muted or hatched overlay
• keep authoritative tile data separate from art layers

For area maps using the Tiny Swords pack, use the 64x64 terrain grid and keep fog as its own layer above terrain but below markers and annotations.

The world map scene should show:

• known region boundaries
• charted routes
• fogged unexplored area tiles
• player and guild map markers
• event warnings on relevant tile clusters

Browser-Fit Rule

Tile discovery should be expedition-driven, not manual one-tile clicking.

The player should review map state from:

• survey result summaries
• route overlays
• chart items
• town board map requests

That keeps exploration compatible with short sessions and async resolution.

Technical Model

Core Records

Store:

• map_area
• map_tile
• character_tile_knowledge
• tile_snapshot
• map_sheet
• map_sheet_tile
• map_annotation
• guild_map_archive_entry
• tile_drift_state
• map_item_copy_lineage
• map_access_grant
• tile_knowledge_merge_log

Commands

Support commands such as:

• start survey expedition
• record tile knowledge from survey result
• create tile snapshot
• assemble map sheet
• consume chart item
• copy chart item
• archive chart
• share chart to group or guild
• merge archive entry
• verify stale map data

Resolution Rules

• survey results write revealed tile knowledge first
• cartography conversion writes charted items second
• stale drift runs independently over time based on tile state and world events
• map item trade references structured tile ids, not freeform text
• using a chart item writes imported knowledge state based on freshness and confidence thresholds
• copying or archiving a chart writes lineage and permission records
• verification can promote rumored or stale data back toward revealed or charted
• event or drift updates should invalidate route-safety summaries and archive freshness automatically

Related Systems

• exploration, cartography, and resource discovery
• expedition types
• market contracts and logistics
• dynamic events and world state
• client and SVG pipeline