Roadmap

What is designed and not built yet. Kalem's own plans are in Kalem's next version and its status.

The live world

• The world lives on Caria's server and is deployed from the IDE, to staging and to production: a definition package → a try on the server → a migration report → approval. Passwords stay in the IDE's Password Safe.
• The server writes the world's saves with compare-and-swap. A missing player does not stop time; when the server was down, the world goes on from its last saved game time (simulating the time it was down is not chosen). Recovering from a crash does not rely on anything running on shutdown.
• A living world has no stopping debugger, only watching: logs, breakpoints that do not stop, the profile.
• Ids in the live world: sessionId + entityId + nodeId, and for a script instance also bindingId + generation; an id made on a client is never taken as the server's.

Events

• Models and their components declare their own events; shared events are not copied. Event ids are versioned and their payload bound to a schema: loading the same id with another schema or producer is an error.
• Scopes world, city, district, building, region, object; widening a scope needs explicit permission, and receivers in space are found by an index.
• An infrastructure event reaching a character is not the character knowing of it: perception is a system of its own.
• Planned events:

Event	Payload, at least
world.sessionStarted	sessionId, seed, gameMinute
world.dayStarted	dayIndex, gameMinute
world.clockControlChanged	paused, speed, gameMinute
city.powerChanged	serviceAreaId, powered, revision; a street's cut does not cut the whole town
city.weatherChanged	weatherStateId, revision
incident.started / changed / ended	incidentId, kind, severity, area, revision

For buildings and objects: building.visitorExited, region.entered/exited (membership in space), door.stateChanged, interaction.started/completed/cancelled, activity.started/ended, environment.changed. Events that do not come from a field's change (incident.*) are sent by scripts.

• Filters by service area, building and region.

Commands and delivery

• An event envelope: eventId, type, version, side, sessionId, source, scope, payload; on the server also sequence, gameMinute, stateRevision, and correlationId when a command caused it.
• A command such as door.tryOpen goes through access, locks, effort, time and reservations; its cost is applied once, and the server decides the moment it can be passed. A failed command makes no event and answers with its reason.
• Retries over the network are idempotent by request id; "exactly once" is not promised. A commit is a step of the simulation, not a database transaction per event. Core checks (doors, energy) cannot be skipped by a script's error.
• Speed changes only game time; limits on processor time stay in real time.

On screen

• The server publishes the current value of contract signals over SSE (source, signal, value, revision, minute). The model publishes a signal, not a script; without a script the default value is published, and the revision moves only on an accepted change.
• A client refuses an old update, gives a late script the current value, and never replays history. A new or streamed-in client takes a snapshot; after a break, revisions are reconciled first.
• Replication by area of interest and permission; a client cannot publish a server event.
• Visual effects never travel over the network frame by frame; out of view, visual work stops and the server's rules go on.
• Client lifecycle events: dispose when a binding is removed (with its reason), viewEntered / viewExited when the game camera's view is crossed (not every frame; no occlusion). Visibility never changes a server rule, and an actor's perception is not taken from it.
• The same effects in the native game (Cocos).

The town

• The ground: one terrain per scene, a height field (slopes, hills) with painted surfaces (grass, dirt, sand, stone); one sea level, the sea showing wherever the terrain is below it, so the coast forms by itself; lakes and rivers later.
• Roads are models, from one kit of pieces that fit together (straight, curve, slope, stairs, junction); a piece sets the terrain under it to its own shape. Everything else stands at its coordinates, as placements do today.
• Navigation is drawn, apart from the looks: areas drawn on the scene as polygons, of four kinds: pedestrian, vehicle, shared (a narrow street with no pavement) and crossing. Models carry no navigation; the areas say where each can go and how far. The IDE bakes them into a navigation mesh for Play and for deploying; the server finds routes with A* (a proven library) and gives residents their plans; lanes and directions come with traffic, inside the vehicle areas.
• A placement's own values in the scene (property and field values that differ from the package), and layers that switch groups of placements (winter decorations, a festival).
• Streaming what is near the camera, levels of detail, and far cells drawn from proxies.
• The server knows space without models: where placements stand and their boxes, entrances, walkable and drivable paths, places to sit. Things that move follow plans (a route, when to leave, a speed); the server finds encounters and resolves them in Kalem.

Environment effects

• An effect has a unit (points per game minute), a condition, a cap and a merge policy (replace, add, max): a lounge gives 5, a private area 8, dancing 12; by default the same socialGain group replaces, not 25.
• Social satisfaction is kept apart from a lasting tendency to be social; being in an empty place is not an interaction.
• Dust is computed lazily from the game time that passed; dirt from use comes from visits. When a threshold is reached is planned on the server; nothing waits for an observer.

Residents

Residents imitate people rather than being needs machines: a lasting personality, a mood of the moment, and memory. The body is the world's Kalem rules (walking, doors, lights); the mind is a small decision model that chooses among the options Kalem offers, with a language model called rarely for plans, judgement and talk.

Checks for Uhren Disko

Done, in Kalem's tests and in Play: it opens at 18:00 and closes at 03:00; it closes when the power goes and opens again when it comes back; the grid publishes a town event from the world's field; visitors are counted only while it is open; in the same minute the closing timer runs before a visitor; a binding over its budget or failing closes and Play stops at that minute; the same inputs give the same result; going on from a save and migrating are defined.

Coming: a living world with no players; a late viewer seeing the current state; the sign loading dark while the power is off; visibility never turning the power on; a locked door refusing and charging once; the socialGain policy, and going in and out not making points; dust in an empty building; speed, skipping ahead, restarting, reloading and recovering from a crash; profiles of 50 to 100 characters.

The editor

• Animations on placements and in Play; facial expressions (morph targets); fitting clips to other skeletons.
• Shadows; physics and navigation.
• Evaluating expressions, watches and conditional breakpoints in Debug.
• Closing the panels taken out of the Debug window when it closes.