How Caria's world works
The server is the world
- The town lives on Caria's server whether or not anyone is watching. The server is the authority over the world's state, its clock, where things are, who may do what, and what it costs.
- Behaviour is written in Kalem, on the server and on screen alike. A script does not take over the authority, and the screen never runs the simulation again.
- The server knows no behaviour. An object's fields are in its own definition (a package's
object.json, the world's.world), its rules are in Kalem; nothing about one model or one business is written into the server.
Three layers of values
- Design: the package, what every copy of a building starts as.
- Instance: a placement in the scene, and how this copy differs.
- Living state: what the running world has made of it, on the server.
None of them is written in place of another. A window is not given a fixed "whole/broken" list: what a part can be is in its own fields.
Fields and events
- A field is an object's public value: whether a business is open, whether the town has power (Fields). One script writes a field; anyone may read it.
- An event tells of a change that was accepted; a command is a request that can be refused. The events of the town are the project's event documents.
- Who receives an event is decided by its kind, its scope and an explicit subscription: a script
subscribes by declaring a handler (
on city.powerChanged). Nothing bubbles to a parent or spreads to children, and there is no loop that runs every object on every tick. - Attaching a script is never required, and the order of components is not a referee: two scripts cannot write the same field.
Names in a running world
In Play, an object's id comes from its definition: the world is world; a package shown on its
own is named by its folder (uhren-disko), a part by <package>/<part id>; in a scene every
placement by its id (uhren-disko), and what it places under it (uhren-disko/sofa-2). Two
bindings of the same script are two instances.