Resources and Structures

The settlement layer is two types and one number. The number is the interesting part.

Resources

A .resource.json file is a material. It carries almost nothing mechanical — a unitName and a gatherVerb, both purely so gathering narrates as cutting poles or digging clay rather than as "you gather some resources" nine times running.

One unit of anything is one unit of carrying capacity. That abstraction is doing a lot of work and it is worth keeping: the moment stone weighs more than cord you need a weight system, an encumbrance curve, and a table nobody reads.

Resources live on the character's resources array, never in inventory. An item is equipped or consumed; a resource is spent on a structure. Two lists because they are two different things.

The two tiers of gathering

Terrain carries yields — what open ground of that kind gives, one unit at a time, no roll, forever. Discoveries carry resourceYield — three to five units for a roll.

Every resource must be obtainable from open ground somewhere. The node tier is the reward; the ambient tier is the guarantee. If a material exists only on nodes, a region that happens not to place one has a build ladder that cannot be climbed, and the player will not be able to tell that from bad luck. The wiring script asserts this.

Structures

A .structure.json file is a blueprint. Built instances go in the region's structures array — deliberately NOT inside tiles, because tiles is authored and [ID: REGION] spends a section telling the GM never to write there.

The fields that carry the design:

• cost — resource references and quantities. Paid in full; there is no partial construction.
• requires — other structures that must stand on the same tile. This is what turns a list of costs into an order, and what makes a tile become a camp.
• storage — units held at the tile. See below.
• tokenOffset — where its prop sits inside the hex.
• interior — a region this opens up. Only structures big enough to stand in get one.
• onBuilt — GM instructions for the moment it stands. Not flavour.

The one number that matters

Carry capacity is 10 + _might × 2. For a starting character that is 16.

@Missing file costs 42. @Missing file holds 60.

Those three numbers are the whole mid-game. The hut cannot be carried in one trip, so a store is mandatory, so the loop becomes gather → haul → deposit → repeat. Change any one of them and check the other two:

• If the hut fits inside one carry, the basket is decorative and the haul loop never happens.
• If the hut costs more than basket plus carry, it can never be paid for at all.

make-settlement-content.js asserts both, prints the ladder, and refuses to be quietly wrong. Edit costs there rather than in the files.

Props are tokens, and why

The honest version: the GM cannot attach a fill image to a polygon at play time. It can place tokens.

If props were map areas, every structure the player built would be an empty outline on the map — worse than nothing, because it would look broken rather than unfinished. So a built structure is a token, linked to its blueprint so the picture shows, placed at the tile position plus the blueprint's tokenOffset so several props on one tile fan out instead of stacking.

The position is written back onto the built instance as tokenX/tokenY. That looks like storing something derivable, and it is not: it can only be derived while standing on that tile, and recording it means nothing ever has to re-derive hex geometry to find a prop again.

Prop tokens are permanent. Unlike creature tokens they are never removed.

Interiors and the one pin

A structure with an interior opens a child region — for the hut, a one-tile map with axialRadius: 0. The same schema, the same token expressions, the same tooling; a hut interior is just a very small region.

When such a structure is finished the GM adds a pin linked to that region. It is the only pin in the game. Everything else on a map is either an authored area or a token, and the instruction says so in those words because a GM with pin-placing licence will start marking things.

Adding to the ladder

Keep new structures on the existing resources unless there is a real reason to add a sixth. Give each one a requires that puts it somewhere sensible in the order, a tokenOffset that does not collide with the ones already in use, and an onBuilt that says concretely what changes.

Then re-run the content script and read the ladder it prints. If a build is not gated by either a prerequisite or a haul, it is not part of the progression — it is a shopping list entry.