Behaviors - e-ucm/ead GitHub Wiki

Each scene element has a set of associated behaviors, that define how the scene element behaves (duh) in the scene, including how it reacts to user interaction.

A trigger is something that can happen to a scene element. Something can be a click, some time passed, a variable changed, etc.

Behaviors associate triggers with effects (when something happens over a scene element, execute this effect). Each scene element has a list of behaviors. Behaviors are represented like this:

...
behaviors: [
    {
        trigger: ...,
        effect: ...
    },
    ...
]
...

Example:

...
behaviors: [
{
    trigger: {
        class: time,
        repeat: -1,
        time: 1
    },
    effect: {
        class: transform,
        relative: true,
        duration: 0.5,
        transformation: {
            rotation: 360,
            scaleX: 0,
            scaleY: 0
        }
    }
}
],
...

There is list of available effects in the wiki.

In eAdventure, we define, by default, the following types of triggers:

Touch

class: touch
JSON Schema

Triggered when an user interacts with an scene element using a mouse/touch. The trigger can be configured to listen for press, release, enter or exit events.

Time

class: time
JSON Schema

Triggered after the configured time passes. It's possible to set how many times the event repeats (a number of times or infinite times).

Issues: concurrency and sequencing

We have not addressed "event collisions" yet. Right now, behaviour triggering is imposed by event type (say, clicks are processed before timing by LibGDX). When multiple behaviours can be triggered at the same time, triggering of one event may cause the 'later' event not to be triggered (because its conditions no longer hold, being changed as a consequence of the first event being triggered).

Example:

When space is typed, if the puzzle is complete, ring a bell and remove the puzzle
When space is typed, if the puzzle is complete, blink a light and remove the puzzle

currently, only one of these two effects will be triggered (and it is complicated to tell which one it will be, although for a single game whichever is triggered will be triggered consistently). The indetermination can be solved by changing these rules to

When space is typed, if the puzzle is complete, ring a bell and set "time_to_remove_puzzle" to "true"
When space is typed, if the puzzle is complete, blink a light and set "time_to_remove_puzzle" to "true"
When "time_to_remove_puzzle" is true, remove the puzzle

At a later stage, we might want to implement a mark/sweep kind of event handling, where event trigger evaluation is separate from the actual behaviour taking place. This would allow the first example to execute exactly the same as the second example.