Now that we’ve seen a simple Age in action, it’s time to back up and explain the underpinnings. These are the concepts that make up the Seltani world model.
A self-contained explorable area – “an Age”, in D’ni parlance. You will design the world and everything about it. Worlds may link to each other, but they never overlap.
In Seltani, as in Myst Online, you will sometimes find different worlds which are considered “the same Age” from a storytelling point of view. For example, the Seltani District and Goldspring Island are both in the D’ni cavern. However, from a builder’s point of view, they are different worlds. This keeps life simple, and ensures that authors are free to build more (non-overlapping) parts of D’ni.
A world may have many instances, so that players can choose to explore alone or in groups. Instances are parallel but separate copies of the world. They are initially identical, but they may diverge over time as players act in them.
(Planned feature: a way to make instances of a world vary randomly, like the Bevin neighborhoods in Myst Online.)
We talk about a player exploring a world, but really a player is always in an instance of the world. (There is no way to be in “the world itself.”) Player actions never change the world definition – only the state of a particular instance.
Every instance has a scope, which is just a label for who owns the instance and how public it is. There is one scope for every player (the player’s “personal scope”), plus one more – the single “global scope” which everybody shares.
(Planned feature: “group scopes”, where one player may invite others and explore instances that are shared only among that group.)
It is important to understand the distinction between worlds, scopes, and instances. Fred’s private Leafspin Age and his private Starflake Age are two different instances (because they are two different worlds), but they share the same scope – Fred’s personal scope. There are many global instances, but exactly one global scope, which they all share.
A world and scope define (at most) one instance. The instance may not exist – for example, there is no global Leafspin. But there can never be two different instances of the same world at the same scope.
A world is divided into locations. (So every instance of the world is divided into the same locations.) A location is just a place to stand. It can have any description; it can be large or small.
Indoors, a location is usually a room. Outdoors (or in the Cavern), a location is an area such that you could comfortably look around and see everybody. When you speak, your voice is heard throughout the location, but does not carry to other locations.
(In some worlds, such as Leafspin, a location is more like a situation than a physical place. We will discuss these “situational locations” later. For now, think about rooms and courtyards.)
Nearly everything about a world is defined by its properties. A property is a named piece of data – it might be text, or a number, or some code, or various other types. In the example above, we defined two properties: a piece of text called
desc and another called
Most properties are attached to a location; these are unsurprisingly called location properties. For example, the
grass are attached to the
Dusty Hill location, and will only appear there. In contrast, a realm property is free-floating; it is available in every location of the world.
(If it’s available all over the world, why not call it a “world property”? Good question! I’ll answer it later.)
There are also “player properties”, which are attached to players rather than locations. We’ll get to those later too.
The name of a property must be a short, lower-case string. It may include underscores, but no spaces or other punctuation.
The value of a property, on the other hand, may be any kind of text or data.
The upper pane of the player’s game window always shows the player’s current location. More precisely, it displays the contents of the
desc property of that location. We call this the locale description. It may include hyperlinks for actions available to the player.
(The list of people in the location appears with the locale description, but it is technically a separate block of text.)
The middle, pop-up pane is called the focus description. The “focus” is whatever the player is looking closely at right now. (This too may include hyperlinks.) The focus may be an object in the location, such as the
grass property defined earlier. Or it may be another player, a linking book, or some other special case.
What is the difference between the locale and the focus? Rule of thumb: the locale is what everybody present sees. The focus can be different for each player; it is what that player is paying attention to.
The bottom pane displays a timeline of chat, system messages, and events. Events are lines of text sent to the player at a particular time. Events may not contain hyperlinks. (The event pane retains scrollback for a long period. It would make no sense for an action link to stick around after the player has moved elsewhere.)
Your world has a
copyable flag, which you can set on the world building screen. Normally this is
true, meaning that anybody who finds a linking book for your world can copy it into their personal booklet. If you change this to
false, copying will be prohibited; the link will only be found in worlds where you personally place it.
Most worlds should be copyable. Set this flag
false for “reward” worlds, such as Sotusano. These are worlds which players may find after solving puzzles, but which they should not be able to take home and pass around.
You cannot set this flag on individual linking books; either every linking book for a world is copyable, or none is. However, you can make some links easier to find than others. For example, the link for the Sotusano tower is found right at the beginning of Leafspin, so players can easily reach it even though it’s not copyable.
Your world has an
instancing flag, which you can set on the world building screen. Normally this is
standard. This means that when a player finds a linking book – either in the world or in their booklet – they may choose whether to link to their personal instance or the global instance.
(If the world is
copyable, players may also choose the target instance when copying links into their booklet.)
If you set the
instancing flag to
solo, the world will exist only as personal instances. Moreover, players will not be able to visit each others’ personal instances! The world will only be explorable alone, never in groups. Use this flag for single-player puzzles, and worlds with situational locations. Leafspin is an example of a
If you set the
instancing flag to
shared, the world will only have a global instance, never any personal instances. Seltani District is an example of a
When should you use the
sharedflag? Honestly I’m not sure. I included it for symmetry. Seltani District is
sharedto make the intro experience slightly less confusing; I didn’t want new players to accidentally link to a personal instance and find themselves alone. This probably doesn’t apply to any other worlds.
Remember that both
soloworlds have personal instances. But they don’t behave exactly the same. A
standardpersonal instance can in theory be shared with friends. (This is already possible, but it’s a nuisance to set up.) A
solopersonal instance can never be shared.
(Planned feature: the ability to invite other players to your personal scope. They will then be able to link directly to your instances – but only for
standardworlds, of course.)
Warning: If you make a world uncopyable, that does not affect links that people have already copied. So set that flag
falsebefore you make the world available! Once you make a copyable world public, you must assume that people will keep copies of it forever.
A player has an access level, or permission level, for each instance. The possible access levels are
BANNED, VISITOR, MEMBER, OWNER, FOUNDER. By default you have
FOUNDER access to all your personal instances (regardless of who created the world in question!). For global instances, the world creator has
FOUNDER access. All other players default to
What does this access level do? Usually, nothing! Access levels are only checked when the world is designed to check them. For example, it is possible to make an
EditStr object (a chalkboard) which is only editable by the
FOUNDER. Or the world might feature a door which is only usable by instance members.
(Planned feature: a way to give your friends access to your personal scope.)
(Planned feature: once group scopes are in, you will be able to give people various levels of access to the group.)
You know how in every textbook there’s one chapter that you try to read, decide to skip, come back to later, give up on... and come back to at least three times before you really get what’s going on? This is that chapter.
Whenever you refer to a property, the system checks for it in the player’s location first. If it’s not found, the system checks for a realm property with the same name. We say that each location inherits the realm (world-wide) properties, and then adds its own (location-specific) properties. Or, looking at it from the other side: location-specific properties override realm properties.
But the fun doesn’t stop there!
You define the properties of the world, but properties can also be attached to the instance. A freshly-created instance has no properties of its own; it relies on those inherited from the world. But as players act in the instance, they may cause reactions, and these changes are stored as instance properties. Instance properties override world properties.
So the simple “grass” hyperlink we defined earlier actually checks four different
grass properties, in this order:
- the location property stored in the instance
- the location property defined by the world
- the realm property stored in the instance
- the realm property defined by the world
Right now only the location-world
grass property exists, so that’s the one that’s found. But in theory all four could exist.
This is why we have to make a distinction between “realm properties” and “world properties”. A realm property may be world-level or instance-level; the latter will override the former.
What about properties attached to players? (We’ve mentioned these, although we haven’t yet shown what they’re good for.) Player properties have their own similar, but separate, chain. It’s slightly simpler, because one of the four levels can’t be defined, at least right now.
- the player property stored by the instance
- the player property defined by the world (not currently available)
- the default property (for all players) stored by the instance
- the default property (for all players) defined by the world
World-level location properties are defined on the location screen; that’s what we’ve been doing. Realm properties, and default-for-all-players player properties, are defined on the world screen.
Now don’t worry about any of this for a while.