Game Plot

The term game plot refers to the rules and mechanisms used to structure, design, and build the whole game scenario that you have in mind.

Game execution fundamentals

In Rollick the game plot unfolds using an event-driven approach according to which, events that happen in the game or in the real world (caused by the player or not) are handled by the rollick app which in response executes some actions.

With appropriate event handling rules, you can achieve the script-writing of the entire game. When designing your game, you can consider yourself as a director who defines what happens to your actors (players, characters, game world) or what your actors will do when some event occurs.

Not all events are useful in order to build your game plot. Moreover, some events may be useful only in a given context (.e.g. when the player is at the “archaeological museum”), or under specific conditions (e.g. the player has not correctly answered question X).

Rollick provides a very flexible script-writing mechanism that supports appropriate event handling for all the above scenarios. The core tools used to design your game’s plot are scenes and their script, event-handling or script rules, milestones, and missions.

Before discussing these tools, it is important to understand how events are propagated and handled in a rollick game. As explained, the entire game world is structured into game scenes which are not only a spatial fragmentation of the game world but also a scoping mechanism. For consistency reasons, the entire game world is also considered a single universal scene.

At a given moment, a player who is playing the game may or may not be inside a spatial scene but they will always be in the universal scene. In the following figure for instance

• Players 1 & 2 are inside scenes A and *Universe*
• Player 3 is only inside the Universe scene
• Player 4 is inside scenes C and Universe

  Possible player positions while playing a Rollick Game

The same is true regarding event occurrence. That is, an event may happen when the player is inside or outside a spatial scene. An event is first caught in the context (scene) it occurred. If there is a rule that can handle this event, then this rule is executed, and its handling completes. If there is no rule, then the event is propagated to the outer scope if it exists.

All possible cases are depicted in the figure below

Event propagation and handling scenarios in a Rollick Game

• Event 1 occurs while the player is inside scene A. Scene A has no rule to handle it, so it propagates the event to the universe scene, which has no rule to handle it too. Thus, event 1 is ignored!
• Event 2 occurs while the player is not inside some scene, and since the universe has no rule to handle it, the event is ignored.
• Event 3 occurs while the player is inside scene B which has no rule to handle it. Thus it propagates the event to the universe which can handle it since the designer has defined some handling rule for this event. Thus, the event is caught and handled there.
• Event 4 occurs while the player is not inside some scene, but the universe has a rule to handle it. Thus, event 4 is handled directly at the universal scene.
• Finally, event 5 occurs while the player is inside scene C which indeed has a rule to handle it. Thus, the event is caught and handled in scene C. No further propagation is done.

With the aforementioned principles in mind, it becomes clear that game script-writing is to define the correct event handling rules or just script rules for those events that are important to develop the game plot and to assign them carefully to the appropriate scenes.

Scene Scripts

When trying to script-write a rollick game, you have to identify the appropriate events and define script rules for their handling. Rollick allows each scene to have its own set of script rules; that is, each scene has its own script.

By carefully studying the above figure, you may think that you can define all the event-handling rules in the universe scene. This is true since all events are finally propagated in this scene.

However, this is not a good approach. Not only will you end up with a quite big set of event-handling rules, but also you will very soon realize that some of the events should be handled only when the player is currently within a specific scene. To do that, the easiest way is to define their handling rules within the desired scene.

On the other hand, it is safer to define some rules at the universe scene to prevent event handling misses.

Script Rules

A script rule or event-handling rule has the following simple form:

• When an event occurs
• Then, the Actors Do a set of actions
• [But only if some preconditions are satisfied]
• [Else, the Actors Do another set of actions]

By default, an event-handling rule is executed once. If the same event occurs again in the same context, it is ignored. If you uncheck this option in a rule, then every time the event occurs, the handling rule will be executed.

To understand the difference, consider the following scenario:

You want the first time a player enters the “Museum” scene, to show them a welcome message, and inform them that they can scan the QR code in front of each exhibit to get more details about it. In this case, you don’t want to show them again the same welcome message if they leave the museum area for a while and return back (i.e. exit and enter again the same scene); so you need the scene-enter event to be handled once.

On the contrary, while in the museum, you may want your player to be able to scan the same QR code many times to see the details about an exhibit; so you need to disable the “fire once” option in the corresponding script rule.

Events

Triggering events are the game events that may occur by a player's action in the real world, by a player's action in the game world, or by the achievement of a milestone in the player’s and game’s state.

Real World Generated Events

Game World Generated Events

Apart from these triggering events, there are also events generated by the interaction of players with objects and offers. However, these events cannot be used in general event handling. Instead, their handling is defined when you describe the behavior of those objects and offers (when contacted, when acted, while owned).

Actions

A script action is always executed by the game engine (rollick), however, as a designer, you can define that the actor of some action is a non-playing character. This is a powerful feature of rollick, that allows your characters to look like real actors in your game.

When you define that an action is performed by a character, the player is informed about it making the gaming experience more natural and vivid. If you define, for instance, that the character “Gandalf” is asking a question (to the player), then the Gandalf’s avatar will be floating over the question screen in the player’s app.

Accordingly, if you define that “Gandalf” gives 10 points to the player, then the player will see a notification saying “Gandalf: +10 points”. This happens for any action that directly affects the player or interacts with them.

Character Acmon giving 20 points to the player

The general pattern for action configuration is:

• The subject is the "who" part in a script action and refers to the actor who performs the action. Examples: “Gandalf” or “Rollick” (i.e you)
• The verb and direct object constitute the "what" part in a script action. Examples: “gives [10] [points] ”, “shows info [welcome to art museum]”, etc.
• The indirect object answers the question "to whom" in a script action and it refers to the entity receiving the action effects.

Examples: “to Player”, “to World”, etc. Sometimes the indirect object is implied so it is not needed to be explicitly specified. For the sake of usability in defining script actions, rollick has, in many cases, combined the verb and the indirect object into a single action name (e.g. “Give to Player”, “Attach to Player”, “Remove from World”, etc.). However, behind the curtain, the above action syntax pattern is applied.

The following cards present all the script actions that you can use in defining script rules in your game.

Actions to Communicate with the Player

You use these actions to communicate (directly or through a game character) with the player.

• Subject: Rollick (you) or a Character
  
• Verb: Action
• Direct Object: the communication element (info, question, quiz,etc.)
• Indirect Object: Player

Actions to Modify Player’s Assets

(Make it Assets in studio)

These actions are used by you (the designer) to modify (directly or through a game character) the player’s assets in terms of attached attributes and owned items & objects.

• Subject: Rollick (you) or a Character
• Verb: Action
• Direct Object: attribute / item / object
• Indirect Object: Player

Actions to Modify World’s Assets

(Make it Assets in studio)

These actions are used by you (the designer) to modify (directly or through a game character) the world assets in terms of attributes and items.

• Subject: Rollick (you) or a Character
• Verb: Action
• Direct Object: attribute / item
• Indirect Object: World

Actions to Evolve Game

These actions are used by you (the designer) to modify (directly or through a game character) the world assets in terms of attributes and items.

• Subject: Rollick (you)
• Verb: Action
• Direct Object: scene / game

Actions for Object interactions

These actions are used to define the interaction between the player and an object or offer. When using these actions, the object is not known at design time. You can think that this action reres to the object with which the player interacts.

• Subject: Player | Rollick (you)
• Verb: Action
• Direct Object: interacting object instance.

A script rule may have one or two action sets (if-then-else). All actions in an action set are executed at once by the game engine. In each such set, you can define ONLY ONE communication action. This restriction prevents quick (and missed) communications with the player.

Consider for example, that you define that rollick will ask question x to the player, and in the same action set you define that rollick will show them the info “welcome”. The player experience in such a scenario would be to see only the “welcome” message! Although question x will be asked to the player, the show info communication action will be immediately executed after it (and actually before the player sees the question!) leading to the info screen. This behavior could introduce significant inconsistencies in the player’s state preventing the player from progressing further in the game.

Conditions

A condition (or logical expression) is a statement about a game entity (player, world, object, offer, ) that can either be true, or false. Examples of such statements that you can make in a rollick game are:

1. The player has seen the info “Welcome”.
2. The player owns at least 5 “Diamonds”
3. The player has succeeded in the 4th question of the quiz “Museum Visit Review”.
4. The game world has the attribute “Inspector”
5. The game world has no “Diamonds”
6. The offer is for adults only
7. .....

Furthermore, such expressions can be combined with logical operators (AND | OR) to formulate more complex expressions. For instance, the statement «the player has seen info “Welcome”» AND «the player owns at least 5 “Diamonds”», has two operands (statements 1 & 2) joined with the logical operator AND and is itself a (complex) logical expression that can be either true or false.

Such logical expressions are called conditions in rollick and are very useful to allow conditional event handling or feature accessing. To simplify the syntax of complex conditions, rollick introduces the notion of Condition Block. A condition block contains one or more conditions joined implicitly with the AND operator. If you define more than one condition block, then these are joined with the OR operator.

To easily define and configure actions, rollick provides a templating mechanism that you can use to define logical expressions. With this mechanism, you just select the expression syntax template (from a rich set of templates) and then just fill in the blanks to build a simple condition in a user-friendly way. Conditions are mainly used as preconditions in event handling rules.

The following image shows how a complex condition is defined in the context of a script rule. The entire condition contains two condition blocks (joined with OR). The first contains only one simple condition, while the second contains two simple conditions implicitly joined with AND. In this image, you can also see examples of condition templates and how they are used. In general, a condition template is a predefined configurable statement about an entity. Once you choose it, you only have to provide the correct parameters ((typically select from a list of valid options).

Creating a complex script rule precondition

Milestones

Most triggering events occur just after a script rule is executed (its set of actions) or a player action completes. For instance, when the player answers a question, the player-completed-question event occurs. So if there’s a script rule defined for this event, it will be executed. Accordingly, when the player scans a QR code, or when the player enters a scene area, the corresponding code-read and scene-entered events occur.

In defining your game plot, however, there may be scenarios in that you want a script rule to be executed not as a result of an action, but as a result of a state condition; either player’s state, or the world’s state, or both.

Consider for instance that you would like to show a congratulations message to your player once they have collected 100 Diamonds. How would you define such a rule? What is the triggering event? As a second scenario, assume that you want to reward your players with 10 points when they have answered all questions and have destroyed all bombs. Again, what is the triggering event for such a rule?

To cope with such scenarios, you can define milestones. A milestone is a complex condition that is evaluated upon every state change while playing the game until it will evaluate as true. Once milestone X is reached (i.e. its condition evaluates to true) a milestone-x-reached event occurs. If you define a script rule to handle this event, then it will be executed.

To define a milestone, just define its state conditions (as described earlier) and name it. Then you can define script rules that will be executed once this milestone will be reached.

Missions

A mission is a goal or challenge that you set for your players. For instance, a mission could ask your players to pick up three diamonds, to meet character X, to walk 2 km, or to visit a museum and then answer some questions.

The same behavior (asking the players to do something, and checking whether they did it) could be achieved without missions, e.g. with info elements and conditions. Missions, however, serve important purposes in both playing and designing a game:

• For the players, they communicate the challenge and give a context: players always know what they are trying to achieve, and they can follow their progress, which is a strong incentive to keep playing.
• For you, they structure the game plot. Accomplishing a mission is an event you can react to with script rules, and a state you can check in conditions, so you can write simpler scripts and see at a glance how the plot is organised.

Defining a Mission

You define missions under Game Plot → Missions in the design environment. A mission has:

• a title and a description, which the players see. Make them descriptive enough for your players to understand what they are asked to achieve;
• an accomplishment: how the mission is accomplished (see below);
• Notify player: when checked, the players are notified when the mission is assigned to them and when they accomplish it;
• for top-level missions, an optional Repeat section (see Repeating Missions).

Assigning Missions

A mission does nothing until it is assigned to a player. You assign missions with the assigns mission action of a script rule, a conversation option or any other element that runs actions, e.g. when the player enters a scene or talks to a character. The archives mission action removes a mission from the player's active missions.

Accomplishment Types

Rollick supports four ways for a mission to be accomplished:

• Missions accomplished by player action

  The player has to perform a data collection action. There are two actions: Capture, where the player captures and posts information on the Rollick platform, and Share, where the player captures some information and shares it on social media. In both cases, you can see what each player has posted.

  You configure what the posted information has to include (media, text, or both; for media, whether image, video or audio), and whether the player has to capture it right now with their camera or microphone (capture now), or may choose a file from their device's library.

• Missions accomplished by condition

  The mission is accomplished as soon as the player's and/or the game world's state meets a condition: e.g. the player has answered a question correctly, has completed a quiz, or owns a number of some objects. Conditions can also refer to the world: e.g. a mission can be accomplished when all bombs have been destroyed (the world has no more bombs).

• Missions accomplished by sub missions

  You can structure a mission into sub-missions, breaking a larger goal into smaller ones to better guide and motivate your players. The parent (composite) mission is accomplished when all its sub-missions are accomplished. Each sub-mission has its own title, description and accomplishment (by player action, by condition or by physical task).

  By default, all sub-missions are assigned at once with their parent, so players can achieve them in any order. With Assign sub missions in order, the first sub-mission is assigned with its parent, and each of the others once the previous one is accomplished: you set your players one goal at a time.

• Missions accomplished by physical task

  The mission is a physical activity goal: you set the activity type (walk, run or bike), the metric (distance or duration) and the target (e.g. 2000 meters, or 20 minutes), plus optional advanced settings (minimum confidence of activity recognition, and a timeout). When the mission is assigned, its physical task starts automatically, using the mission's title and description; as soon as the player reaches the goal, the mission is accomplished. If a timeout is set and runs out, the mission remains unaccomplished. See Physical Tasks for how activity is tracked and what the player sees.

Missions accomplished by player action or by physical task can also repeat, e.g. every day.

Missions in the Player App

While playing, players get notified when they are assigned or accomplish a mission (if Notify player is checked). In their Action Center, the Missions tab lists their active missions, with their progress toward accomplishing them, and the missions they have accomplished. The progress of missions accomplished by physical task is also shown in the Physical Activity tab and in the progress widget.

Missions and mission progress as shown to the player

Player State Data

With respect to the player's missions, the following information can be exploited:

• Player has been assigned mission
• Player has completed mission

The completion of a mission (Player completes Mission) can also be used as a trigger event to resume your game plot.

Repeating Missions

Some goals are worth setting again and again: walk 2 km every day, visit the museum once a week, check in at the market every morning. Instead of creating one mission per day, you can make a mission repeat. The player then works on it in rounds: every day (or every week) a new round starts, the mission's progress is reset, and the player can accomplish it again. Rollick keeps a record of every round, so you can reward players for how often, and how consistently, they accomplish it.

Which missions can repeat

Only top-level missions accomplished by player action or by a physical task can repeat. For these missions, the goal naturally starts over with every round: a new post to capture, a new distance to walk.

Missions accomplished by condition and missions made of sub-missions cannot repeat. A condition reads the player's accumulated state (e.g. "has visited place X"), which stays true after the first round, so every new round would be accomplished the moment it started. Sub-missions follow the round of their parent mission.

Setting up the repetition

When you edit a mission that can repeat, the mission form shows a Repeat section:

Repetition starts when the mission is first assigned to the player; you still assign it with an Assign mission action in a script rule, as with any other mission. From then on, at every round boundary the mission, and its physical task if it has one, is reset and assigned again. If you set neither an end date nor a maximum number of rounds, the mission repeats until the game ends.

What the player sees

A repeating mission appears in the player's missions like any other. When a new round starts, the player gets a "New round" notification listing the missions that started over, even if the app is closed; tapping it opens the missions list. Progress bars restart from zero with every round.

Conditions on repeating missions

For a mission that repeats, "has the player completed mission X?" is ambiguous: completed it today? ever? five times? So, as soon as you pick a repeating mission in a Player [Verb] Mission [Mission] condition, the condition asks which round it is about:

The round scope is required. If you make an existing mission repeat and some rules, milestones, places, objects, offers or conversation options already have conditions on it without a round scope, the Studio lists them when you save the mission (Conditions without a round). You can still save, but the game cannot be published until each of those conditions says which round it is about.

Some examples:

• Reward a 7-day streak: a milestone with the condition Player has completed Mission "Daily walk" 7 rounds in a row, and a rule on that milestone that gives the reward.
• Unlock a scene for regulars: a precondition Player has completed Mission "Weekly visit" at least 4 times.
• A reminder: a rule that shows an info if Player has not completed Mission "Daily walk" in the previous round.

Round figures are also available as values wherever you read numbers from the player's state (e.g. in leaderboard variables or external task parameters): Number of times the Player completed Mission X, Number of times the Player has been assigned Mission X (its rounds), Current streak of completed rounds, Best streak of completed rounds, Outcome of the last round and When the Player first completed Mission X.

Player State Data

For repeating missions, the following information is kept per mission:

• The current round: when it was assigned and, if it is accomplished, when
• The history of the last 30 rounds, each with its outcome (completed, failed or skipped) and, for physical tasks, the progress reached
• A summary: the number of rounds and completions, the current and the best streak, and the outcome of the last round

You (or a game master) can follow each player's rounds in the Game Master Console, and the completion of rounds across all players in Game Analytics.