World Simulation Domain Language

From Skycastle

To implement different systems in the game, some kind of domain specific language or data structures for message driven systems is useful.

[edit] Loose constraints / specs

• The language should consist of small components
• It should be possible to compose components to programs / simulated models in an interactive UI
• It should be possible to edit and upgrade the components in an ongoing simulation
• Components should have some form of access control or similar, to allow different access for different callers
• Data and the program should be expressed in the same kind of components, allowing on the fly generation of programs
• Messages should also consist of the same components
• Components should be quickly serializable and deserializable, and support read only or read/write access
• Procedurally, lazily, and on the fly generated components could be useful, to allow e.g. procedural world geometry
• Components should be possible to compile to bytecode, to run fast
• Looping should be done through message passing, to allow the simulation of a component to be controlled externally - a rogue program should not be able to hang the system
• The basic programming blocks should be high enough level that they are easy to use for creating simulated worlds
• Genetic algorithms and similar should be possible to implement that generate systems from blocks
• There should be some blocks with spatial geometry and storage management, and perception between contained components
• It should be possible to copy / instantiate systems, in a parametrized way
• It should be possible to compose systems from custom libraries of components
• There should also be some textual representation of systems, that could be used to input / import, as well as export systems.
• The scheduler should allow some systems / components to get run at a higher priority than others, or with different fractions of available computing power
• Specialized components such as neural networks could also be considered
• It should be possible to get notified of component changes
• One set of primitive components could be used to build user interfaces to visualize and control other components

[edit] Concepts

[edit] Entity / Component

The basic unit of a system.

Different abilities / subtypes:

[edit] Constant primitive value

Represents a fixed value of some primitive type.

Supported primitive types could be for example:

• boolean
• int
• float
• long
• double
• string

Maybe we could also just combine int,long and float,double, although for some purposes a higher precision value may be useful.

[edit] Reference value

Refers to some other component.

Some kind of type information might be included with the reference? - The interface maybe. Although the remote value could be queried about them too.

[edit] Variable value

Contains some component which can change.

Supports changing it with the correct access rights, as well as listening to its changes. When it changes, a message about the change gets sent to the registered listeners.

[edit] Message

A message contains a message data component, as well as a reference to the sender and receiver, and possibly other information like timestamps.

It might also contain some access key related information, such as in what role the message is sent or such, if it makes sense to include them.

The message is handled by a scheduler, which forwards it at a specified time (and maybe repeatedly) to the target procedure.

Messages could have some policy for what to do when they can't be delivered on time: drop, wait until it can be delivered. Messages could also specify whether they can be merged with previous messages from the same sender to the same receiver, with the same message content type (useful e.g. for position updates and variable change listeners).

[edit] Procedure

A procedure is something that handles incoming messages, and can make changes directly to variables and component structures that it has suitable access rights and references to. It can also send messages (possibly repeating) to itself or other components (some maximums might be defined). It can also create new components (that it has access rights to create?), and add them to components that it has access rights to. It can also call functions to get values, and read variables and constant values

A procedure does not return any value.

[edit] Scheduler

Stores messages with timestamps, and when time is advanced, sends stored messages to recipients.

Also handles message dropping or delaying on congestion, and merging of similar merge-enabled messages.

Scheduler could be contained hierarchically, so that one could run a simulation in a simulation in a simulation, etc.

[edit] Functional value

Returns a value when requested. Can take a parameter. Should not change the state of the model.

Can be used for collections or containers, where the parameters could be the name or index of an object, or a spatial query for objects.

Some variant could calculate its value based on other functions, and cache the result, changing only when the functions change. No recursion should be allowed though, to avoid lock-ups.

Can generate the component on the fly also.

Can be asked about the interface for the parameter.

[edit] Collection

A sequence of components, that implement some interface.

Can be iterated sequentially, as well as having a message sent to all members, and similar.

[edit] Dictionary (or Entity?)

A mapping from unique string identifiers to components.

Can have interfaces that describe the role of the components.

Can be used as a kind of class.

[edit] Interface

It should probably be possible to define different interfaces, that describe a component (its type, its subcomponents, default values, value ranges, etc), as well as having user readable / internationalizable descriptions and names for component parts.

A component could then be marked as implementing zero or more interfaces. If it implements an interface, it could have all the required components, or the interface could provide defaults for missing values.

An interface could maybe change? (needed to allow extending interfaces during runtime), or at least support versioning? Although immutable interfaces would be easier to deal with..

An interface is more like a hint of what values are expected, and some defaults if values are missing, but mostly code should provide its own values if the incoming data is nonsensical (to allow for AI / genetic algorithms, old or new clients, and to not break on malicious clients).

If a message or function request doesn't have the right permission, it could be just ignored (for messages (although a return error message might help debugging, but maybe just allow querying the access levels)), or an error value returned (for functions).

[edit] Copying Components

Any component can be copied. The copy should probably be a deep copy (reference values would still be just references though).

If components were immutable this would be trivial, but several are stateful, or have some state (e.g. listeners).

[edit] Access rights

Checked on value / function access, structure modification, and message invocation.

A role based access model could be used.