infinite-pokemon-region

# Buildings: creative exteriors, dependable services

Invent architecture that belongs to the location: canal houses, stilt huts, courtyard homes, workshops, bathhouses, greenhouses, windmills, railway halls, mountain lodges, observatories, cliff archives, hollow-tree shelters, or unfamiliar variations. These examples do not restrict style. Generated exteriors and interiors may vary when the asset and building-placement capabilities are present.

Every enterable building needs an explicit footprint, reachable entrance, matching door coordinates, valid arrival point, and a return exit. Roof art can overhang the footprint; doors must still align with the collision map. Do not draw additional apparent entrances that cannot be used without clearly marking their purpose. Decorative background buildings may be nonenterable, but should not imitate a functional service entrance.

## Hospital / community center contract

A place advertised as a hospital, healing center, or full community center must provide all of these, regardless of its architecture:

| Facility | Required behavior |
| --- | --- |
| Reception and caretaker | Clearly marked, reachable interaction; explain available services |
| Healing | Restore party HP and move PP; recover fainted companions; safe to use repeatedly without a consumable or victory prerequisite |
| Saving | Accessible checkpoint/save terminal, successful-save feedback, and access to run/checkpoint management according to host permissions |
| Trading | Clearly marked trading desk with the supported trade interface; when no partner is available, explain that honestly |
| Exit and circulation | A clear route from entry to every service and back outside; no furniture, NPC, or story lock may obstruct essential care |

The artistic treatment is free: a rural clinic, modern hospital, garden hall, or floating community pavilion can satisfy the same contract. Maintain recognizable care/save/trade signage even when adapting colors and motifs. Extra services such as a noticeboard, storage desk, or rest area are optional.

Saving follows the active run. The host can create or branch shared checkpoints; a guest must receive accurate autosave/host-managed messaging instead of a false private rewind. Healing and saving must remain available before and after the regional master is defeated.

Trading requires engine support, two eligible participants in the same run/session, explicit agreement to the offered companions, revalidation at acceptance, and an atomic exchange with retry protection. A cancelled or disconnected offer must not lose or duplicate a companion. Cross-save or cross-branch exchange needs a separate implemented policy. Dialogue and image generation cannot perform trades or declare one complete.

Do not publish a full service center as operational when a required action is unsupported. In a design job, preserve the building brief and list missing service capabilities. In today's live map-story job, leave the existing shelter mechanics intact and do not advertise trading. Existing template shelters provide healing; they are not yet implementations of this full center contract.

## Other building families

- **Homes and social places:** resident routines, gardens, communal kitchens, libraries, cafes, meeting halls. Optional conversations, no mandatory invented rewards.
- **Work and travel:** shops, mills, ferries, train stations, workshops, farms, ranger posts. Only offer purchasing or travel if the engine supplies those actions.
- **Exploration landmarks:** towers, shrines, ruins, laboratories, conservatories. Connect their identity to established region history.
- **Dojo:** use the regional reference for its master, challenge, and completion rules. A trainer sprite in an arbitrary house is not automatically a Dojo.

For asset-capable requests, use the visual-assets reference for door sockets, hitboxes, occlusion, service anchors, and staged publication.

# Continue the land across blocks

A **block** is one loaded outdoor map, currently 32×24 tiles. A **region** in world design is a connected group of blocks; it is not the existing TypeScript `Region` map record. See the regional reference for that distinction.

## Read the boundary before choosing the destination

Use the current saved run's source blocks, observed adjacent blocks, movement context, and planned neighbors. The live context's `terrainContext` identifies occupied observed neighbors as possible approaches; several players can approach the same target. Do not invent a single predecessor if none is known. `neighborEdges` describes the actual edge of each adjacent block facing the target. Those profiles are observations of current geometry, not permission to edit it.

Honor every observed neighboring edge, not just the route the first player took. Continue path position and width, banks, tree belts, fences, building density, palette, and major landforms where possible. Edge indices run west-to-east on north/south edges and north-to-south on east/west edges; do not reverse them when matching opposing edges. Nonadjacent descriptions provide broader context but are not direct edge constraints.

In a geometry-capable job, carry compatible materials inward from the boundary before blending toward the interior. Keep a readable entrance apron and enough room to turn. Around corners, reconcile the two adjoining seams together. Match real walkability and door/bridge anchors as well as colors. Never rewrite a visited neighbor to make a proposal fit. An unobserved planned neighbor can be revised only if the scheduler explicitly allows it and revalidates its dependents.

## Gradual change

Change one or two major properties at a time: surface material, building density, vegetation, moisture, or elevation. A single block may be a mixed transition zone. Use several blocks when the destination is substantially different; roughly a quarter to a third change in dominant coverage per step can be a useful composition heuristic, not a rigid law.

| From → destination | Plausible sequence |
| --- | --- |
| City → fields | Streets → residential edge → gardens and farm plots → farm lane → open fields |
| Meadow → forest | Open grass → bushes and scattered trees → groves → dense woods |
| Forest → coast | Woods → thinning sandy woodland → salt grass/dunes → beach or harbor |
| River → sea | River bend → wider channel → reeds and estuary → tidal shore |
| Green hills → desert | Meadow → dry pasture → scrub → gravel and exposed sand → dunes |
| Lowlands → snow | Foothills → rocky upland → frost patches → snowy woodland → deep snow |
| Settlement → ruins | Maintained houses → unused buildings → broken walls → overgrown foundations |
| Town → industry | Shopfronts → workshops → service yards → quarry, docks, or waterworks |

Preserve a visual thread through the sequence: the same canal, road paving, distant ridge, crop, fence style, or roof color. Story changes should explain the transition through observable details—a city gate, irrigation works, abandoned railway, or increasing salt exposure—rather than an abrupt unrelated biome roll.

A discrete entrance can justify a stronger change: entering a cave, stepping indoors, or taking a supported tunnel. Establish the connector in the scene and use its actual engine transition. Do not invent a teleport, season change, or catastrophe merely to excuse an incompatible seam.

## Planning and validation

When the supplied schema supports rich plans, record the source/neighbor identities and hashes, dominant and secondary materials, proposed transition direction, matched connectors, and unresolved constraints. These are planning concepts, not additional keys in today's strict map-story response.

Before publication, geometry validation should check reciprocal traversable exits, connected mandatory routes, coherent water crossings, collision footprints, and the service/Dojo anchors. If constraints conflict, retain the safe existing block and ask the scheduler to revise the unobserved plan; do not turn a blocked route into a fictional promise.

With today's template compiler, select a compatible supported biome and sensible feature patches, and make the story acknowledge the existing physical setting. Matching edges in a prompt does not enforce terrain seams: arbitrary geometry blending remains an engine extension.

# Creatures, traits, goods, and rides

The region-story-v2 response may include up to three `creatures`, three `shopGoods`, one `vehicles` entry, and a guide `npcTraits` profile. Use empty arrays and a null NPC-trait profile when existing content fits the place, following the supplied output schema. Favor a few coherent discoveries over unrelated novelty. Reuse the exact established profile when bringing a species or item into another block; its name, type, and appearance are identity-bearing data. These definitions belong only to the active run and checkpoint history.

## New creature profiles

Each creature blueprint supplies `name`, `description`, `base`, `types`, `move`, `traits`, and `art`. `base` is an engine family (bulbasaur, charmander, squirtle, pikachu, oddish, or pidgey); the generated creature has a separate stable species identity and display name. Choose one or two types from the supplied schema and one or two traits. Do not invent stats, rewards, abilities, evolutions, or executable commands outside that schema.

Traits include hearty/sturdy (modest extra HP), bold (small attack bonus), gentle (small damage reduction), elusive (slightly harder capture), and curious/swift/radiant (personality or visual flavor). Individuals can differ within a species. Type affinities and the named special move use the prototype's existing combat rules, not arbitrary effects inferred from prose.

The `art` recipe chooses a quadruped, bird, fish, serpent, golem, or sprite body; hex primary/accent colors; plain/spots/stripes/crest pattern; and boolean horns/wings. Use a silhouette and palette suited to the biome and neighboring species. These are engine-rendered pixel-art SVG recipes, not image-generator output. External image importing remains unavailable. Example concepts: a reed grazer near wetlands, a mineral-backed creature beside ruins, or a lantern-colored sprite near a story landmark.

## Hybrid nursery

The engine can pair two distinct owned, healthy level-5 companions at a nursery. Parents remain owned; care costs 120 coins, eggs hatch after 32 accepted movement steps, and parents rest for 64 steps before another egg. Their baby inherits types, visual features, and traits, with a bounded trait variation. Same species-parent combinations share a canonical hybrid species identity; individual parent IDs and the child's lineage remain recorded.

Do not generate an egg as an inventory reward or declare a hatch, parent pairing, or ownership transfer in prose. Only the nursery action creates an egg. Hatching adds a level-1 companion to the party or storage. Bred companions are not counted as wild captures on the leaderboard.

## Shops and currency

Shops retain preset Poké Balls, Great Balls, Potions, Super/Hyper Potions, Revives, Ethers, Repels, and a Bicycle. Prices are this prototype's economy, not a claim of exact original-game pricing. All purchases are server-priced, charge existing coins, and validate stock and ownership. A generous merchant can offer the defined modest discount.

Generated `shopGoods` have a name/description, `effect` (heal, pp, repel, capture), `tier` (1–3), `icon` (bottle, herb, orb, charm), and hex color. The engine derives effect strength and price; the harness cannot grant free items or set prices. Use local lore: a spring herb that heals, an orchard scent that repels encounters, or a crafted orb for capture. The icon is rendered from the validated recipe. Do not promise unsupported status ailments, teleportation, free money, or permanent stat increases.

## Vehicles

Generated `vehicles` have name/description, form (bicycle, scooter, cart, mount), hex color, and speedTier (1–2). The engine derives price and step duration. Rides are owned once per trainer, work outdoors, and retain the ordinary collision footprint and blocked terrain. Buildings temporarily park the selected ride. A floating-looking cart does not gain flight; a water-themed ride does not cross deep water. New traversal mechanics need explicit engine support before they can be advertised.

## NPC traits and records

For `npcTraits`, select a supported temperament and interest, plus a short concrete quirk grounded in this place. Keep identity stable on revisits. Guide traits inform dialogue; merchants, caretakers, breeders, and trainers also have stable seeded profiles. Traits do not authorize arbitrary actions.

Leaderboards are authoritative and local to a run: wild capture count, unique caught species IDs, visited map blocks, recorded individual tiles, and distinct trainers defeated. Starters and eggs do not inflate catches; rematches do not inflate distinct trainer counts. Do not invent scores or merge counters from sibling saves. Global cross-server competitive ranking is not implemented.

# Interior design contract

Each room proposal has `sceneId`, `name`, `furniture`, and `rugs`. The context lists eligible room IDs, existing furniture, fixed spawn, and protected objects. Coordinates use the enclosing32×24 map grid. The rectangular floor is x9–22, y5–18 inclusive; every placement's full footprint must stay inside it. The exit tile at16,19 remains fixed and accessible.

Furniture:1–10 items, each with `kind` (`table`, `counter`, `bookcase`, `bed`), `name` (2–40 characters), `text` (5–180 characters), x/y integers, width1–5, height1–3. Furniture is solid and inspectable. Proposed furniture replaces the old furniture, not doors, NPCs or the terminal. Overlaps, blocked arrivals and inaccessible services/exits cause rejection.

Rugs:0–4 rectangles with x/y, width1–5, height1–4. Rugs are decorative, passable floor coverings. They cannot enlarge a room or create a doorway. Room names are3–48 characters. All proposals must obey the request's JSON schema.

Design examples rather than mandatory templates:
- Ranger cabin: clustered map table, bunk along a wall, supply bookshelf; keep the entrance and caretaker approach open.
- Shore station: navigation counter and chart cabinet, with a rug leading inward from the entrance.
- Archive: separated reading tables and bookcases, with clear loops between stacks.
- Rest house: beds along opposing walls, care counter at the back, a broad central aisle.

Use descriptions to connect furniture to established local lore. The engine, not text, implements healing, purchases, breeding and saving. Do not invent executable scripts, remote assets, unlisted furniture types, new service commands or unrestricted wall geometry.

# Behavior contract

A movement policy contains all four fields:

```json
{"movement":"wander","radius":2,"intervalSeconds":4,"waypoints":[]}
```

- `movement`: `stationary`, `wander`, or `patrol`.
- `radius`: Manhattan distance from the NPC's fixed home, integer1–3.
- `intervalSeconds`: integer2–8. The server decides when a legal step can occur; this is not a real-time command.
- `waypoints`: up to6 `{x,y}` offsets from home, each integer−3…3 and within radius. A patrol requires at least one. Use empty points for stationary/wander. Choose passable endpoints, never furniture, services or walls.

Map binding: `{"sceneId":"outdoor","npcId":"guide","behavior":{...}}`. `sceneId` may also be `sanctuary` or `home` if present in the supplied catalog. A live NPC job currently targets the outdoor guide; other NPCs receive generated policies through map proposals.

The engine enforces one cardinal tile per step, a320ms interpolation, solid NPC hitboxes, player and NPC occupancy, a home radius, no door crossing, protected arrivals, and reachable service/interaction paths. Movement pauses within two tiles of players and during battles in the scene. A blocked wander tries another legal direction; a blocked patrol waits or finds a route. Healers, merchants and nursery keepers remain stationary so their services can always be found. These rules cannot be changed by the proposal.

Examples of intent: an archive guide patrols between two reading spots; a trail guide wanders a clearing; a caretaker stays beside supplies. A `rest` intention offers existing engine healing when the player talks to the guide; prose cannot invent buffs, items or progression. Derive memories from observed events rather than claiming knowledge of another save. Keep dialogue brief and consistent with temperament. Describe intentions without promising that a blocked movement already happened.

# Regions spanning multiple blocks

World-design **regions** are named, connected groups of outdoor blocks with a recognizable geographic and social identity. Existing code calls each individual block `Region`; use `worldRegionId` in a future rich-plan contract to avoid treating every 32×24 map as a whole region. That field is not currently accepted by the map-story schema.

Plan flexible clusters, often roughly 12–36 connected blocks rather than fixed squares or a mandatory exact count. Rivers, ridges, travel routes, settlements, and story development can shape their boundaries. Propose membership as the frontier grows. Keep accepted membership and stable IDs in the run's canonical region registry; a region must not reroll its name or master each time a block is requested.

## Region commitments

Reserve at least one full service center and **one primary Dojo with a persistent master** when establishing a region plan. Place these on a connected travel network and signpost the Dojo before players reach the region's main exit routes. The generator may choose their location and visual design, but must not postpone them indefinitely while inventing more filler blocks. A service center should be reachable before the master challenge.

Blocks may include multiple towns, landmarks, side routes, and transition zones. They share some terrain, architectural, ecological, and narrative motifs without looking identical. Adjacent regions may have different identities, but their border blocks still follow the continuity reference.

When planning from a frontier:

1. Continue an existing region if its geography, storyline, and reserved facilities still fit.
2. Propose a border transition when a genuine new regional identity is warranted.
3. Check the registry before proposing facilities or characters, including already reserved but unvisited locations.
4. Publish membership and reservations atomically with the block plan, so simultaneous multiplayer approaches cannot create competing masters.

The registry belongs to the saved run. Forks inherit accepted regional history at their checkpoint; later regional choices in sibling runs are not evidence for this one.

## Dojo and master contract

Each primary Dojo has a stable Dojo ID and master ID, a regional theme, readable entrance, reachable reception/training space, an arena, and an exit. Optional pupils and practice challenges can teach the theme. Styles might include a garden court, tide platform, mountain hall, urban training club, or ruined monastery.

The master is a persistent opponent for the player to defeat—not a random NPC generated anew on every visit. Specify personality, battle style, team proposal, and the narrative reason the challenge matters. Teams must use supported species, moves, levels, and battle rules. Story or art never authorizes impossible combat mechanics.

The engine owns challenge eligibility, deterministic combat resolution, completion flags, rewards, rematches, and any region progression. Persist each trainer's challenge result unless the session explicitly defines shared completion. Record regional consequences separately from personal victory. Rewards must be idempotent; a repeated request or reload cannot award a second badge/reward accidentally. Defeat should leave a reachable healing and retry path.

A previous master victory remains true after revisiting. Forking from before the battle leaves that fork unbeaten; forking after it retains the result. Do not claim a victory from another save or convert existing co-op guardian encounters into Dojo completion without an explicit engine rule.

## Current compatibility

The live engine currently has independent map blocks, route trainers, and a cooperative guardian. It has no persistent multi-block region registry, Dojo placement schema, master roster, or Dojo-specific victory flags. Apply this document in rich planning jobs or when those capabilities are supplied; ordinary map-story output must not pretend these systems are already operational.

# Runtime contract and capability negotiation

The request's supplied output schema and capabilities determine what can be executed. Reference catalogs grant creative latitude within that contract; they do not add engine mechanics. Treat unsupported creative ideas as design material only when a planning output is requested. Never append undeclared fields to a live response or announce a service that does not exist.

## Current map-story jobs

The current schema is region-story-v3. It retains the earlier fields and also accepts optional creature, NPC-trait, shop-good, and vehicle blueprints described in [creatures and economy](creatures-and-economy.md). These use bounded pixel-art recipes, prices, and effects controlled by the engine.

The response is exactly `{ "snapshotId": "the supplied identity", "story": { ... } }`. The story schema in `game/shared/model.ts` accepts:

| Field | Current constraint |
| --- | --- |
| `name` | 3–42 characters |
| `description` | 10–400 characters |
| `biome` | `meadow`, `forest`, `coast`, or `ruins` |
| `npcName` | 2–28 characters |
| `greeting` | 5–400 characters |
| `hook` | 5–240 characters |
| `features` | Up to 8 patches; use a few purposeful patches rather than filling the map |

Each feature has only `kind`, `x`, `y`, `width`, `height`. Allowed kinds are `trees`, `pond`, `flowers`, `tallGrass`, and `stones`; x is 3–27, y is 3–20, width is 2–6, and height is 2–4 (integers). These are 32×24 blocks. Geometry, reciprocal exits, tutorial anchors, shelter shells, exits and service anchors remain compiler-owned; interior furniture/rugs can be proposed through `interiors`. Existing protected geometry takes precedence over patches. The five opening layouts are fixed. Later `meadow` proposals currently use the river/meadow layout; the other supported biomes select their corresponding layout.

Choose supported biomes and patches in the context of actual neighboring surfaces, not only map names. A forest fringe can use a meadow/forest proposal with a few tree patches; a ruin being reclaimed by nature can combine stones and vegetation. Rich city, snow, desert, wetland, or custom-building geometry is not currently importable. Do not describe an unsupported city as if its buildings had appeared merely because the output biome was set to `meadow`.

## What the context means

`lineage` identifies the current run and checkpoint ancestry. `maps` distinguishes observed and planned blocks and includes their biome labels. `terrainContext.neighborEdges` describes actual bordering tiles and open positions of adjacent blocks; `approachBlockIds` are occupied observed adjacent blocks, not a guaranteed single predecessor. A `fixedOpeningLayout` name, if supplied, overrides assumptions drawn from the biome label for the target's geometry.

Current `terrainContext` is descriptive. It enables informed proposals; it does not claim that the template compiler enforces arbitrary seam matching or gradual terrain coverage. If a transition cannot be represented, preserve truthful supported output and leave the richer geometry to a separate engine-capable planning job.

## Rich world-design jobs

When the host supplies a richer schema and explicit capabilities, use the terrain, continuity, building, region/Dojo, and asset references selectively. Relevant capabilities include editable block geometry, region registry/reservations, building placement, service actions, Dojo/master battles, image generation, and validated asset import. Record unresolved capabilities in the designated planning field; do not invent a new response format.

Trade actions, region membership, rewards, accepted asset manifests, and published block geometry become facts only after engine validation and persistence in this run. Verification jobs remain nonce-only; NPC jobs remain bounded intention proposals. Preview mode must not generate maps, stories, or images.


`npcBehaviors` (up to12 bindings) and `interiors` (up to2 room proposals) are optional. See the bundled [NPC](npc-behavior.md) and [interior](interiors.md) contracts. The supplied `designContext` lists exact actor IDs and protected room objects. Do not invent target IDs. NPC movement uses shared runtime policies, and interior proposals must pass the same collision/access validation as authored layouts.

# Terrain and object vocabulary

Choose a coherent environment, then vary its composition. These examples are a starting vocabulary; new motifs are welcome when their gameplay category and continuity are clear. A new visual appearance does not grant a new movement or interaction mechanic. Consult the runtime contract before emitting fields.

## Environment families

| Family | Useful variations | Natural neighboring transitions |
| --- | --- | --- |
| City | Dense streets, brick alleys, canal quarter, plazas, railway district, rooftop silhouettes | Residential streets, parks, warehouses, gardens |
| Town and village | Market square, terraced homes, fishing hamlet, mountain village, garden town | Orchards, allotments, farm lanes, woodland edge |
| Outskirts | Scattered cottages, small workshops, drainage channels, abandoned lots | Suburbs → garden plots → farmland |
| Farmland | Crop rows, orchards, pasture, windmill lanes, irrigation ditches, rice terraces | Hedgerows, meadow, riverbank, scrub |
| Grassland | Short lawn, flower meadow, prairie, grazing land, breezy hills | Farms, sparse trees, heath, savanna |
| Woodland | Sparse grove, mixed forest, pine forest, bamboo thicket, old-growth canopy | Meadow → shrubs → scattered trees → dense forest |
| Wetland | Reed beds, marsh pools, mangroves, mossy bog, flooded woodland | River shallows, damp meadow, estuary |
| Fresh water | Spring, creek, river bend, waterfall basin, lake margin | Springs → stream → river → delta; shallow banks before open water |
| Coast | Pebble beach, sand dunes, tide pools, sea cliffs, harbor, boardwalk | Estuary, salt meadow, fishing town, rocky upland |
| Highlands | Rocky pasture, foothills, ravine, mountain pass, alpine meadow | Low hills → rocky slopes → upland terrain |
| Cold terrain | Frosted grass, snowy pine woods, drifts, frozen shore, glacier approach | Cold foothills and sparse snow patches before deep snow |
| Dry terrain | Dry grass, thorn scrub, ochre canyon, gravel flats, dunes, oasis | Grassland → dry grass → scrub → exposed sand or stone |
| Volcanic terrain | Dark scree, cooled lava, warm springs, ash meadow, basalt ridge | Ordinary rock → dark rock → sparse plants → ash or basalt |
| Ruins | Mossy walls, broken terraces, buried courtyards, old aqueduct, shrine paths | Existing settlement or forest gradually reclaiming masonry |
| Industrial terrain | Workshop yards, quarries, loading docks, waterworks, disused rail | Town edge, service road, spoil heaps, recovering scrub |
| Underground | Cave mouth, limestone chamber, mineral grotto, mine passages, flooded cavern | An explicit entrance, stair, or tunnel connects surface and interior |
| Unusual places | Giant-root glade, luminous fungi, meteor grove, wind-carved stone garden | Introduce the motif through small details before its main landmark |

Vary route shape, sightlines, open space, vegetation density, landmarks, and settlement density—not merely the place name or palette. Reuse the region's architectural language while giving each block a distinct navigational identity. Keep busy decoration away from doorways and readable path edges.

## Gameplay categories

Classify every proposed element independently of its art. A scene can layer multiple categories on one tile only if the collision and interaction result are unambiguous.

| Category | Examples | Required meaning |
| --- | --- | --- |
| Ground/surface | Grass, sand, paving, dirt, snow, floorboards | Base material; normally traversable unless another layer blocks it |
| Path | Worn trail, brick lane, stepping-stone motif, bridge deck, boardwalk, stairs | Visible route. Path art alone cannot override water, walls, height differences, or a locked connector |
| Blockage | Tree trunk, dense hedge, cliff, boulder, deep water, fence, wall | Explicit footprint and collision; keep mandatory routes reachable |
| Decoration | Flowers, fallen leaves, moss, puddle sheen, grass tufts, lamps, roof trim | Cosmetic unless a separate solid/interactable object is declared; no invisible walls |
| Interactable | Sign, supply bundle, berry shrub, well, terminal, noticeboard, memorial | Facing target, prompt, action identifier, persisted state where relevant; no invented reward execution |
| Building | Cottage, center, Dojo, greenhouse, tower, shop, mill | Exterior footprint, actual door, reachable interior/exit, and any declared services |
| Encounter area | Tall grass, cave floor, reeds, shallow-water habitat | Encounter policy is a separate engine capability; a texture must not silently introduce combat |

Examples of deliberate variants:

- A shallow-looking decorative puddle is traversable; a river is blocked unless a supported crossing exists.
- A flowering hedge can be a solid boundary, while scattered flowers remain traversable.
- A tree canopy may overlap a player visually; its collision belongs to the trunk or specified dense grove footprint, not every transparent pixel.
- A supply object disappears for the correct player/run after collection; painted scenery never pretends to dispense inventory.
- A bridge requires both a continuous deck and matching connections on each bank. A bridge-shaped image is insufficient.

## Selection sketch

For a city-to-field story, prefer an outskirts block with fewer buildings, softened paving, gardens, and one surviving urban landmark. The next block can introduce farm tracks and larger open plots, followed by predominantly meadow. Add a new visual motif because the place needs it, not to fill every tile.

# Visual assets and image generation

Keep the classic top-down handheld pixel-art presentation: current logical tiles are 16×16 pixels and the viewport is 240×160. Use crisp pixel clusters, controlled palettes, a consistent overhead perspective, readable silhouettes, and coherent light direction. Buildings can have original architecture and large roof silhouettes; do not force every building to reuse the same template.

## Choose an asset source by context

Reuse an accepted asset when continuity calls for the same material, landmark, or character. When a novel asset is useful and the supplied harness exposes image generation **and** a game asset-import pipeline, use the available image-generation tool with the relevant accepted references. Do not assume a tool exists because another Codex interface has it. Respect the host's generation allowance and queue budget.

Useful asset families include:

- Transition terrain strips: paving fading into dirt, grass thinning into sand, scattered snow, forest fringe, marsh banks.
- Ground tiles and border variants: inner/outer corners, edges, small variations, riverbank and shoreline connections.
- Vegetation and rocks: multiple silhouettes with compatible palettes; explicit trunks/base footprints and optional canopy layers.
- Building kits: facade, roof, entrance, signage, interior floor/walls, furniture, and service markers.
- Character sheets: consistent master/caretaker identity, required facings and supported animation frames.
- Interaction sprites: terminals, trade desks, signs, supply items, and their supported state variants.

## Asset brief and import contract

When the job's schema supports asset requests, identify the asset's role, region/block/run lineage, accepted visual references, palette, pixel dimensions, tile dimensions, required edges or frames, transparent areas, and intended placement. Describe what should remain consistent and what may change. Do not include credentials or unrelated user data in image prompts.

For buildings, specify entrance sockets, exterior collision footprint, foreground occlusion, interior transition, and service anchors separately from pixels. A hospital/community center's brief must preserve healing, saving, trading, and exit access. A Dojo brief must preserve master/arena access and its stable identity.

Example design brief: “An outskirts clinic beside the established brick road. Keep the neighboring warm red roof palette; use timber extensions and a garden toward the fields. A visible south entrance, care sign, and space for separate healer, save, and trade stations. Match the supplied building scale and top-down perspective.” This is an artistic brief, not a live map-story JSON response.

Import into a run-scoped staging area. Validate dimensions, format, transparency, palette/readability, tile seams, collision/door alignment, and required services. Store the final accepted asset by content hash with its generation/reference metadata. A visually plausible image is not a valid map until collision, interactions, and connectivity pass validation.

Generated pixels must never define physics implicitly. Solid silhouettes need declared hitboxes; paths need real traversability; signs and doors need working interaction metadata. Keep distant roof/canopy pixels separate from ground collision and use foreground layers when they overlap the player.

## Streaming and checkpoints

Generate assets for buffered adjacent blocks ahead of entry. Publish the validated block data and its asset manifest together. Until then use a safe accepted placeholder, or keep the unpublished proposal staged. Do not swap a building's door, footprint, or required services underneath a player.

Checkpoint manifests should pin immutable accepted asset hashes. A fork inherits the referenced versions, not an editable shared asset path that a sibling can replace later. Shared content-addressed storage is acceptable when immutable; keep unpublished work and mutable manifests scoped to the run.

## If tooling is unavailable

The current game invokes read-only structured map/NPC jobs. It renders classic static artwork and now also validated pixel-art SVG recipes for creature profiles, goods, and vehicles; see [creatures and economy](creatures-and-economy.md). It does not expose a working image-generation/import job. Do not call extra tools, emit image paths, claim images were generated, or expand the strict story schema in that job. Use supported terrain features for live output. In an explicitly requested design/planning job, provide an asset brief and capability requirements using the supplied planning format instead.