Can the Baker Fetch Flour and Still Have Time to Bake?
Atlas #11 · The living island
Concept art from the Atlas ontology: Three lanes share one oven (concept 321)
In this post
Imagine reaching the bakery in Llanrhos after the baker has returned from the mill. The flour should be there because somebody carried it, even if nobody watched the journey. This is the proposed first example for Atlas's next piece of life simulation, not a scene the game can already perform from end to end.
A player could follow the baker along the lane, arrive at the mill first, or spend the morning somewhere else. Those choices should reveal different parts of the same day. They should not decide whether the flour arrived.
The ambition is larger than a convincing walk. The baker needs time to collect flour, somewhere to put it, fuel and an oven, and enough working time left to make bread. Later, a customer must be able to buy that bread, carry it home, leave it in a cupboard and feed a family from it. A household cannot eat a loaf that exists only as scenery on a shop counter.
Atlas already has a prototype for people's daily lives and an economy that describes production and needs. Making the goods, the people and the player's observations agree is the work described here.
Schematic design, not a game capture or a map of Llanrhos. The first proposed case is flour collection and baking; the household chain extends it. The arrows represent work and handovers that still need implementation; other baking inputs are omitted. Open the diagram to read it at full size.
Walking to the Mill Takes Time#
A route describes a way through space. A life segment describes an interval in someone's life. Keeping those words separate helps reveal where a plausible-looking day can still be wrong.
The watermill and bakehouse are places. The route connects them. A journey puts a particular traveller on that route at a particular time. The traveller's life then contains intervals of walking, waiting, loading, returning and working.
Atlas concept art, The millrace turns the wheel. The watermill illustrates the kind of workplace the baker visits. This is a generic setting, not a view of Llanrhos or a capture of the proposed delivery.
The code and working designs use the following vocabulary. The first group already exists in the lives prototype:
| Word | What it means |
|---|---|
| Person | A particular inhabitant, with identity, household, role and plans. |
| Place | An identifiable physical location, such as a home or workplace. |
| Plan | A calendar-selected daily routine: a working day, harvest day or day of rest. |
| When | The calendar conditions under which a plan applies. |
| Step | A timed instruction within a plan, telling the person where to go and what to do. |
| Rate | How often a step occurs. A yearly rate is an expected frequency, not proof that an exact quota was completed. |
| Segment | An evaluated interval with a start, end and activity. The intervals form the person's day. |
| Act | The interval's structural action: staying, walking, travelling a route or dwelling at its destination. |
| Route | Spatial points and road or path classes between places. It does not itself specify a departure. |
| Journey | Scheduled travel on a route. In the current prototype this means a recurring round trip, including a stay at the far end. |
| Leg | In the freight router, a portion of a trip using one transport mode. |
| Mode | The means of travel: on foot, by cart, by pack animal or by boat, with its movement rules. |
A step is therefore an instruction in the authored routine. A segment is part of the evaluated result. Neither word, by itself, proves that the baker had flour to collect or enough hands to carry it.
A Heavy Load Can Delay the Bread#
The proposed delivery must use the world's cart tracks and footpaths, including the local connections to the mill store and bakery. A line drawn straight between their centres is not evidence that a person can walk it.
The route and transport mode determine travel time. The load must fit that mode's carrying capacity. Several purchases in the same basket share its limit; each does not get a fresh basket's worth of space. Loading, unloading and waiting take time too.
If the flour is too heavy, the baker needs a smaller load, another trip or suitable transport. If the return trip leaves no time to bake, the day is infeasible. A continuous animation is not enough to make that day work.
That is why the smallest example begins with flour collection and baking. It is already a meeting of geography, work and inventory.
Who Owns the Bread in the Cupboard?#
A cupboard is a drop-off point. So is a mill store, a bakery shelf, a merchant's warehouse or a market stall. Goods can remain there between visits.
This removes the need to make every exchange a perfectly synchronized meeting. A customer brings bread home; another family member prepares supper later. A boat unloads into storage; someone collects the cargo after the crew has gone.
The design adds some words that are not yet implemented as a complete system:
| Word | What it means |
|---|---|
| Job | An obligation to accomplish something, such as collecting flour. It may require several activities and journeys. |
| Consignment | Goods allocated to a particular delivery. |
| Stock location | A physical place where goods can remain. |
| Inventory | The goods and quantities there, or carried by someone. |
| Owner | The person, household or institution the property belongs to. |
| Custodian | Whoever currently holds or looks after it. |
| Reservation or claim | The goods allocated to a job or recipient. |
| Conversion | A production or use operation that consumes inputs and produces outputs. |
Baking is a conversion: flour and other inputs become bread. Carrying changes the flour's location and custody. Buying may change its ownership. Eating consumes the bread. These operations need common accounting, but they do different things.
Atlas already represents freight work as a service conversion. That accounts for the carrier's work and resources; it must not manufacture a second copy of the cargo at its destination.
Ownership also survives a handover. A delivery hand carrying somebody's purchase need not own it. Taking an object without permission would change possession, not automatically make the taker its legal owner. Those distinctions will matter beyond bread.
One Baker Can Carry Flour and Sell Bread#
The craftsperson class includes bakers and millers. A particular baker, their household and their bakery are world instances. The existing economy table called “people” describes role types, not a list of named inhabitants. The ontology describes kinds of things and relationships; the simulation holds the particular things and their changing state.
The ontology site also contains named places. That makes it both a vocabulary and a catalogue. A page for a named lake does not make that lake a new type of lake. The catalogue should point to its canonical world record, with its actual outline and status. The same boundary applies to settlements, buildings and eventually people.
Some distinctions cross the boundary in useful ways. A baker has an occupation, but acts as a carrier while collecting flour and as a seller when serving a customer. Those temporary roles should not create new people or silently replace the baker's livelihood.
The keys connecting these meanings are being defined alongside the existing ontology vocabulary. Existing population and service-role keys come first. Missing concepts need proper definitions and relationships, rather than a parallel list invented by the life simulator.
A segment also needs more than the display text “works at the bakery.” The renderer must distinguish carrying a sack from kneading dough, putting bread into an oven or handing over a purchase. Semantic activity keys can connect participants, tools, goods and workplace affordances to explicit visual implementations and animation bindings. The words shown to a reader can change without changing those keys.
That contract is being designed. The current structural actions do not yet provide this complete semantic activity and animation layer.
Getting World Records into the Game#
Relationships such as person to household, job to workplace and workplace to settlement belong in a connected data model. They should not rely on matching names across unrelated files.
The existing world-query database already joins settlements, placed buildings and economy data. It is a derived, read-only projection, including a downloadable database file (SQLite) and a hosted read-only copy (D1) for the website. It is not an authoring database to edit behind the builder's back.
The intended boundary is to maintain each definition and world record through the tools that own and validate it, validate their references, then assemble compatible runtime snapshots. The game, lightweight world-builder and website should read the same identified facts. The final division of the authoring tables is being designed alongside the existing world catalogue.
The first extracted life-rules component is already stored as versioned data in a cloud archive, R2. Changing its culture profiles, recurring calendars, seasonal windows or market-day role rules changes generated plans without rebuilding the app. That is a useful component, not the completed runtime content pipeline. Much of the activity-step authoring still lives in code.
The Baker Still Works When You Walk Away#
Atlas calls the transition from a population description to visible individuals deterministic collapse, part of its observer model. The intended effect is simple: arriving at the mill reveals the people who belong there at that time. It should not invent a new delivery outcome because somebody arrived to look.
The current lives prototype can evaluate a person's day and query nearby people deterministically. The larger design extends that agreement to jobs, ownership and inventories.
Routine movements should be evaluated from schedules, rates and indexed intervals rather than keeping every unseen person running through minute-by-minute updates. An inventory can be projected from validated recurring flows and recorded changes. An intervention must affect the relevant future instead of resetting when the player leaves.
This is not a promise of free computation. Queries, routing, validation and changed circumstances still cost work. The goal is to avoid continuous per-person ticking while preserving causality: flour cannot be baked before it arrives, and observing the cupboard twice cannot create another loaf.
The test is whether following the baker, seeking directly to the afternoon or arriving with another observer gives compatible answers. The same identities, places and goods must survive all those views.
What the Game Can Do Today#
The daily-lives prototype, its spatial observer queries and the newly extracted life-rules content are working components. The rules change real generated plans; their default values preserve the previous fixture behavior. The new rule-content changes have not yet been merged into the shared game source. The full baker chain is not available in a released game build.
The lightweight world-builder has a CPU mode and headless player-movement tests. Its existing walking traces do not prove inhabitant logistics. The proposed shared life evaluator and inventory queries still have to join that testing interface.
The complete baker journey, its causal flour-to-bread accounting, the household cupboard chain and the semantic animation contract remain design work. There is no finished screenshot of that system to show. The diagram above is deliberately a diagram.
At the end of the proposed morning, the baker's sack is empty. Later, somebody opens a cupboard.
