WorkAdventure offers several options for storing data. In WorkAdventure as in many programming languages, data is stored in variables.
There are 2 kind of variables:
- Room variables: they are associated with a room and shared by all the players
- Player variables: they are attached to a given player
In the rest of this documentation, when we speak of "variables" without specifying the type, we refer to "room variables".
Rooms can contain variables. Variables are piece of information that store some data. In computer science, we like to say variables are storing the "state" of the room.
- Variables are shared amongst all players in a given room. When the value of a variable changes for one player, it changes for everyone.
- Variables are invisible. There are plenty of ways they can act on the room, but by default, you don't see them.
Declaring a room variable
In order to declare allowed variables in a room, you need to add objects in an "object layer" of the map.
Each object will represent a variable.
The name of the variable is the name of the object. The object class MUST be variable.
You can set a default value for the object in the
Persisting room variables state
persist property to save the state of the variable in database. If
persist is false, the variable will stay
in the memory of the WorkAdventure servers but will be wiped out of the memory as soon as the room is empty (or if the
Do not use
persist for highly dynamic values that have a short life spawn.
Managing access rights to room variables
writableBy, you control who can read of write in this variable. The property accepts a string
representing a "tag". Anyone having this "tag" can read/write in the variable.
writableBy are specific to the "online" version of WorkAdventure because the notion of tags
is not available unless you have an "admin" server (that is not part of the self-hosted version of WorkAdventure).
In a future release, the
jsonSchema property will contain a complete JSON schema to validate the content of the variable.
Trying to set a variable to a value that is not compatible with the schema will fail.
Using room variables
There are plenty of ways to use variables in WorkAdventure:
- Using the scripting API, you can read, edit or track the content of variables.
- Using the Action zones, you can set the value of a variable when someone is entering or leaving a zone
- By binding variable values to properties in the map
- By using automatically generated configuration screens to create forms to edit the value of variables
In general, variables can be used by third party libraries that you can embed in your map to add extra features. A good example of such a library is the "Scripting API Extra" library
Player variables are attached to players. Those variables are created using the scripting API.
Here are a few examples of things that could be stored as player variables:
- The score of a mini-game
- A list of inventory items (you can use the scripting API to build a custom inventory item in your map and use player variables to store this inventory
- A vote in a live voting system
They can be "public" or "private".
- Public variables are visible to nearby players in the same room (using the scripting API)
- Private variables are only visible to the player itself
Player variables can be read only when the player is connected. WorkAdventure does not offer a way to fetch the list of all players, only of current players. This means player variables are not well suited for systems such as a "leader board" where the best score should be persisted even when the best player left the game.