SEVEN

Note

SEVEN is the legacy name of the scenario engine and the name of the underlying scenario model

published paper describing SEVEN

SEVEN (Scenarios Engine for Virtual ENvironments) is a scenario engine. It allows you to write and to use scenarios for you application. In a virtual environment, the goal of a scenario is to organize tasks that can and have to be realized. A scenario can be used in three different ways:

Constraint actions by scenario The user is constraint by the scenario, which means that he/she is allowed to only do actions described by the scenario. Especially useful for learning precise procedures, since the scenario makes sure no mistakes can be made. It is also possible to set a virtual human to follow the scenario for demonstrations purposes or collaborations.

Scenario as a support The scenario is used as a support to guide the user without constraints. It could highlight elements in the virtual environment to guide him/her through the experience, proposing possible actions.

Monitoring by scenario The scenario can be used passively, listening to the user’s progression. In this way, user’s actions or changes in the world state will drive the scenario forward showing user’s advancement.

Petri-net

The SEVEN model was created as an extension of Petri nets, working on three concepts: places, transitions and tokens.

Principle: when every place at a transition’s entrance (upstream) got a token, the transition can merge these tokens into one, use this new token and assign new tokens to places at the exit (downstream).

A place, in a n-safe Petri net, can contain several tokens, and a transition can consume more than one token. In Xareus, there can only be one token per place (1-safe petri net).

Transitions use sensors and effectors to communicate with the virtual environment. Sensors can listen to the virtual environment and react to certain conditions.

A sensor can wait for a specific state of the world, like a collision between two objects, to happen, it can also wait for a user action, a constraint on a value to be met, ...

An effector can affect the virtual environment,for example display a message, perform an arithmetic calculation, change the color of an object, write into a file, ...

Both sensors and effectors work independently. A transition can have zero, one or many sensors and effectors.

For more details about how a transition fires, check this page

Note

Xareus comes with a library of sensors and effectors and other functions ready to be used. (see Xareus.Scenarios.Unity and Xareus.Scenarios.Extra for example) You can create custom functions like a custom sensor or a custom effector if the provided library does not meet yourneeds.

SEVEN model Concept

In the picture above, the sensor of the transition is waiting for a collision between the two cubes. When that happens, the effector is triggered and displays the message Well done!.

As soon as the scenario starts, all the Initial places create a token. During the execution of this scenario, the tokens travel through the petri-net it to eventually reach a final places. A scenario reaches its final state when every final place in the scenario has a token, no matter other places. This does not prevent the scenario from updating again in the future and lose its final state.

A scenario can contain multiple sub-sequences, for example in the form of sub-scenarios (diamond form in the figure below) or External-Scenario (square form) A Sequence can be a simple place or a sub-scenarios or an external-scenario. As they contain a sequence, sub-scenarios allow hierarchisation for an better sorting and understanding. Similarly, external-scenarios refer to existing scenario files with sequences, which allows to reuse and factorise parts of scenarios.

State Machine

SEVEN was extended to handle state machines as they can be viewed as petri-nets with more constraints. In a state machine, only one state (equivalent to a place in a petri-net) can have a token. This also prevents a transition to go to more than one place. State machines in SEVEN share the same transitions extensions as the petri-nets (sensors, effectors, ...). While petri-nets are well suited to describe a high-level scenarisation of an application, state machine are usually prefered to describe the evoluation of a single object.

Decision Tree

SEVEN was extended to handle decision trees. Decision trees have a different kind of transition called Decision. Decisions will always trigger but they will provide the token in a different downstream node depending on the sensors results (true/false). Decisions trees can store data in the tokens through effectors or token assign and are meant to be resolved in one run by going from the root/initial node to one of the leaves/final node (meaning sensors/effectors should be atomic and short)