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 (or a task if you llke). For instance, a mission could ask your players to pick up three diamonds, to meet character X, or to visit a museum and then answer some questions.

The accomplishment or not of missions is something that you can exploit to unfold the game plot (i.e. you can define rules that will be executed when missions are accomplished).

The same behavior (i.e asking the players to do something, and checking if they have done it) could be achieved without missions (e.g. with info elements, and conditions). However, missions serve many important purposes in both playing and designing a game. Not only do they allow you to communicate challenges to your players, but they set a context for the players to know what they are trying to achieve every moment.

Moreover, with missions, you can provide incentives to your players since they can monitor their progress toward the achievement of their goals while playing the game. Finally, missions allow you (the designer) to write simpler scripts and have a clear understanding of how the game plot is structured.

When you define a mission, you must define its title, its description, and how it will be accomplished. The title and the description have to be descriptive enough for your players to understand what they are asked to achieve.

Moreover, if you want your players to be notified when they are assigned and when they accomplish this mission check the “notify player” option. Considering mission accomplishment, rollick supports three different accomplishment types: by player action, by condition, or by accomplishing sub-missions.

• Missions accomplished by player action

  Players can accomplish such a mission by performing some specific data collection action. Currently, there are two actions supported: Capture, and Share data. In the first case, the player has to capture and post information on the rollick platform, while in the latter, the player has to capture some information and share it on social media (Facebook). In both cases, you (as a game designer) will be able to see what each player has posted.

  For both actions, you can configure what the captured information has to include (text? media? both?) as well as whether the player has to capture the uploaded media right now (using their camera or microphone), or they can choose a media file from their device’s library and post it.

• Missions accomplished by condition

  Such missions are accomplished when the player and/or game state has reached a particular condition. Examples of such state conditions could be that the player has answered successfully a question, has completed a quiz, or has collected a number of some objects, etc. Conditions can also refer to the game world state. For instance, a mission could be accomplished when all bombs have been destroyed (ie. the world has no more bombs). You can find more details about conditions and their syntax in the section Conditions.

• Missions accomplished by submissions

  Sometimes, you may want to structure a mission into submissions. This technique gives you the ability to better guide and stimulate your players by breaking a larger goal into smaller ones. In this case, the parent (composite) mission is accomplished when all its submissions are accomplished.

  A question that rises here is: when the player is assigned a composite mission, which one of the submissions has to accomplish first? Rollick supports both assigning all submissions at once (default behavior) and assigning in order. That is, the first submission is assigned along with its parent, and after that, the rest submissions are assigned one after the other.

  In both cases, the parent mission is accomplished only when all submissions are accomplished. So, what’s the difference? The only difference is that in the first case you set your players many parallel goals that they can achieve in what order they want, while in the second, you set your players one goal at a time. You can choose what better serves your design needs.

While playing the game, players get notified when they are assigned or accomplish a mission. At playtime, players can see (under the “Activities” menu) their accomplished missions (if any) as well as their active missions (if any) and their progress toward their accomplishment. The next image shows how missions are presented to the player.

Missions and mission progress as shown to the player

Player State Data

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

• Player has been assigned mission
• Player has completed mission