Defining Game Elements

Rollick provides a rich set of game elements that can be used to build your game. In this section, we will talk about each one of them and show how to configure them properly.

Infos

An info is an information message that you want your players to see. It has a title and must contain either a text message, either a media object (image, video, audio) or both. This structure is very common in many other elements as we will see later. Infos are shown to the player (when you define so), in a new app screen which has as header the info’s title, as content the info’s message and media, and as footer, a closing button labeled with the info’s button text. The footer closing button closes the info screen and sets the message as seen in the player’s state.

Info element as presented to the player

Typically, once an info element has been seen (i.e. the player has closed the info screen by tapping on the footer button) there is no way for the player to see it again. If you want your players to be able to see an info element again, check the show in directions option and give it a direction title. This will allow players to see the list of info elements (as well as other elements as we will see later) that they have already seen under the “Directions” menu in the rollick app.

Player State Data

Concerning infos, the following player state information can be exploited:

• Player has seen info

Questions

Questions is one of the input collection mechanisms provided by rollick which you can use to take direct input from your players. Questions have a prompt part (i.e. the actual question you want to ask), and an answer part (the configuration of the question’s answer). The prompt part has the structure of an info element with a title, a media object, and a message (i.e. the question text).

The configuration of the answer part depends on the question type. Rollick supports two types of questions: open-ended questions, and close-ended (i.e. multiple-choice) questions.

In open-ended questions, the player is asked to type his answer. The answer type (i.e. the data type of the provided input) can be one of single-line text, multi-line text, and number.

In multiple-choice questions, the user is actually asked to choose one answer among several provided answers (options). If you want your player to be able to choose more than one answer, then check the allow multiple answers option.

No matter what the question type is, you can declare the correct answer to your question (if one exists). By doing so, you can know if a player has succeeded or failed in a question, and you can exploit this information accordingly in scripting the game plot.

If you want to give your players more than one chance to answer correctly, then you can define the number of attempts to be more than one ( >1 ) and set a hint to give them a clue. This hint will be shown once to the players if they answer wrongly.

Finally, if you want your players to be able to try again a wrongly answered question, then you can check the Keep as pending if answered wrongly option. This will give your players the ability to find the failed question as a pending ToDo task under the “Activities” menu (in the rollick player app), and try it again.

Open Ended Question	Multiple Choice Question

Player State Data

With respect to questions, the following player state information can be exploited:

• Player has been asked question
• Player has completed question
• Player has passed question
• Player has failed question

Quizzes

A Quiz is actually a series of questions asked one after the other. They provide a convenient way to ask more than one question in sequence, without having to write complex script rules. A quiz may have an introduction and an epilogue. Both of them are info elements (they have the same structure) that are used to introduce and conclude the quiz. A quiz is started when its first question is asked and completed when its last question is answered.

Player State Data

With respect to quizzes, the following player state information can be exploited:

• Player has started quiz
• Player has completed quiz
• Player has been asked quiz question
• Player has passed quiz question
• Player has failed quiz question

Confirmations

A confirmation element is actually a closed-ended binary question in which your player has to choose one of two given options (approve or reject). However, rollick defines confirmations as a separate game element in order to give them strong semantics and allow you (as a designer) to ask for clear confirmation or rejection of particular statements that may be important for the game. For instance, you may want to offer some kind of interaction, only to players who confirm that they want it, or they are older than an age threshold, etc. Confirmations, give you a tool to check and control particular declarations of players. Confirmations, like questions, have a prompt part (title and message), while their answer part has only two options (buttons), confirm and reject, the label of which you can refine or change.

Confirmation Element

Player State Data

With respect to confirmations, the following player state information can be exploited:

• Player has approved confirmation
• Player has rejected confirmation

Conversations

A conversation is a complex game element that allows your players to get involved in conversations with non-playing characters of your game. Typically, a conversation is a directed graph of statements (conversation lines) that is traversed according to the player's responses. A conversation is evolving with a simple loop pattern:

1. A character (or the game master if you don’t define one) says a statement
2. The player responds with one of the available options (player statements).
3. Player’s response leads to another character statement (from the same or another character) while different responses lead to different statements

Conversation between player and game characters

The above simple pattern is rich enough to create simple (e.g. monologues) or quite complex conversations between your player and one or more of the game characters. This loop is terminated by the player, either by concluding (completing) the conversation or by exiting it (leaving the conversation and probably resuming it again later).

As explained, response options evolve the conversation (i.e. lead to the next character statement). In practice, apart from that, each response option (when chosen by the player) can have a rich set of actions to execute (e.g. give the player some items, attach an attribute to the player or the world, etc.). It’s up to you to define what will happen when the player chooses a particular response option.

Moreover, response options can be given to the player under specific conditions (preconditions) regarding their state or the state of the world. If these conditions are not satisfied (i.e. they do not evaluate to true), then the option will not be available to the player. A conversation has a title and a set of statements. The title of a conversation is used only to resume pending conversations (i.e. the player can find pending conversations in the “ToDos” tab under the “Activities” menu). if you want to mark a started, but not completed conversation as pending, check the resumable option in the conversation form.

If you want your player to be able to go back to previous statements (and possibly to change their response) in a conversation, then check the allow back option.

Example: Authoring a conversation with 3 Statements

Player State Data

With respect to conversations as a whole, the following player state information can be exploited:

• Player has started conversation
• Player has completed conversation

Conversation Statements

Creating a conversation, actually lies in the creation of its conversation statements and the player response options along with their preconditions and script actions.

A statement is as simple, as a text message combined with a media object. You can also configure a statement to be included in player directions by giving it a title for that.

The next step is to define what response options will be given to the player when this statement will be spoken. For each response option, the minimum that you have to set is the option label and the response actions. The response option label is the label of the corresponding button in the player’s User Interface, while the response actions is a list of script actions that will be executed if the player will respond with this option.

For instance, if you want a statement to lead to another statement, you have to add the action “Says statement” and define the spoken statement. Furthermore, you can define specific constraints (conditions) to show or hide a response option. Later we will discuss thoroughly actions and conditions.

Player State Data

With respect to conversation statements, the following player state information can be exploited:

• Player has seen conversation statement
• Player has talked to character

Characters

Non-Playing Characters (NPC) are non-self-acting actors who act according to the script defined by you. Characters can show info messages to players, can ask questions and quizzes, assign missions, attach or detach attributes to players, etc. only when you define such behavior when you define scripting rules (i.e. what will be done when something happens).

To create a character you must give its name, its age, its gender, and its avatar icon.

Attributes

Attributes are actually tags that you can use to characterize other game entities. This attribution can be later exploited in script rules (through conditions) to allow or prevent access to actions or features. Once you define an attribute, you can attach it to and detach it from the player, the game world, or an object using particular script actions when specific events happen.

For instance, you may define that when your player accomplishes all their assigned missions, you attribute them as “Expert”. This attribution may give them, from that point on, access to several features of the game (i.e. they may be able to see otherwise hidden objects in the playground). Attributes can be attached to or detached from the game world (e.g. tag the game world as “in war”, or “peaceful” to indicate a different status of a game and to adapt the plot to this status).

Finally, attributes can be attached to and detached from objects. For instance, a “terrorist” attributed player set a bomb object to “armed” (when touches it) while a “superhero” attributed player may “disarm” it. From the above examples, it becomes clear that attributes:

• when attached to players can be considered as skills, roles, or budges,
• when attached to objects are just properties of these objects indicating their state, and
• when attached to the game world are characterizing the whole game and modify the game plot for all players

The usage of attributes may be tricky in multiplayer games. There may be scenarios that an attribute should only be attached to one player (e.g. only one player will be the “superhero”). How can we enforce this behavior?

To support such scenarios, attributes can be initially “stored” in the game world (remember that the game world is a shared workspace) and when attached to a player, they are removed from this shared workspace.

If later other players “deserve” this attribute (according to their achievements) they will not be attributed since the attribute was already “taken” by some other player.

To define an attribute, you have to define its title, its description, and media icon.

If you want the player (if this attribute is going to be attached to players) to be notified when they are attributed or de-attributed with it, then check the notify on change option.

If game market is enabled in your game, then player attributes can be sold to other players or can be redeemed by the player in order to gain some money.

Player State Data

With respect to player attribution the following information can be exploited:

• Player is attributed
• Player was attributed

World State Data

With respect to world state the following information can be exploited:

• World is attributed (i.e. the game world is attributed with this attribute)
• World has attribute (i.e. attribute is not attached to any entity)

Object State Data

With respect to object attribution the following information can be exploited:

• Object is attributed

Items

Items are artifacts that have a quantitative dimension and can be given to or taken from the players. With items, you can implement various metaphors for your game such as “points”, “diamonds”, “lives”, “kudos”, etc. Items, while having a quantitative dimension (e.g. 3 lives, 10 points, etc.), are not uniquely identifiable and distinct from each other. It makes no sense, for example, to distinguish one “point” from another. Items are mainly used to implement rewarding or punishment mechanisms in a game. They are significant assets and obtaining or maintaining them is an important motivation for players.

If the game market is enabled in your game, then player-owned items can be sold to other players or can be redeemed in order to gain some “money”.

To create an item you have to define its title, its description, and its media icon.

If you want players to get notified when the number of their owned items of this kind changes, check the notify on change option.

Players can always see their owned items by visiting their backpack under the “Assets” menu in the player app.

Items owned by players are shown in their backpack menu in Rollick App

Player State Data

With respect to player-owned items the following information can be exploited:

• Player owns item

World State Data

With respect to world available items, the following information can be exploited:

• World has item

Objects

Objects are artifacts that you, as a designer, define in order to implement active game entities that may “live” in the game world and be interacting with the players. With objects, you can model different things like “apples”, “swords”, “bombs”, “chests”, “tweets”, etc.

Objects, like items, are countable and can be acquired by players (i.e player X owns 5 apples). However, there are some fundamental differences between items and objects:

• Objects are distinct and identifiable. Each particular object is different from the others. It may have different data and can be manipulated separately from the others.
• Objects can be dropped in the game world at particular locations. Objects can be placed in the game world (into scenes) and be shared among all players, i.e. other players will perceive their existence on the playground and can interact with them.
• Objects have behavior. Each object is an active entity whose behavior is designed (scripted) by you and which is implemented when a player interacts with it. All objects of the same type, have the exact same behavior.
• New objects can be created during playtime. New objects can be created and dropped in the game world at playtime, either by the game master or by the players themselves. The ability for players to create objects, and drop them into the game world can be very useful in creating pervasive games where players can interact with each other through such objects. Consider for example that one player drops a “bomb” object that may harm or kill other players, or one player creates “review” objects that can be seen by other players at the location they have been dropped.

To create an object, you have first to create its Object Type (also called archetype). That is, to create the blueprint that defines the structure and behavior for all the Object Instances (or just objects) that will be created by this blueprint. After that, you at design time, or a player, or the game master at playtime, can “instantiate” this blueprint to create concrete objects that can be dropped in the game world. The creation of an object type apart from basic object info (title, icon, and description) refers to the configuration of four different aspects of the objects of this type

Object Payload

Objects in rollick can be created by players and these objects may carry payload information. That is, at playtime, a player who wants to create such an object has to populate it with specific data (e.g. a message, a photo, etc.).

In payload configuration, you can define what is the structure and the format of this data. This is done by defining payload properties. Rollick supports several types of payload property types: *single-line text, multi-line text, email, number, image, video, *and audio,

For each property you can also define if it will be visible (from other players) and if it is required to be provided at creation time. That is you can define invisible properties that can store object data without players being aware of them.

Object Creation

In object creation you can define if players can create objects of this type and under which conditions. For instance, you may configure that players in order to create an “advise” object must have completed mission X, or they must have at least picked two other “advise” objects by themselves. Furthermore, you can set restrictions in total or per time unit for object creation by players. This is particularly important if you don’t want to have “inflation” phenomena in your game (ie. too many objects created quickly by players), especially if these objects are later sold or redeemed by players to gain “money”.

Object Perception

Objects that are dropped in the game world are perceivable by other players. How exactly this perception will be implemented depends on what metaphor you want to implement with this object. Rollick provides two object perception mechanisms:

1. Making the object visible to the player’s app.

Once the player enters a game scene all objects placed in that scene that are marked as visible are shown on the playground map in the player’s app. When taping on such an object a “contact” between the player and this object is made (whatever that means).

This behavior is useful if you want to let your players see where objects are placed (probably only once they have succeeded in some task) and go there to interact with them. There are, however, scenarios in which you don’t want objects to be visible to players. Consider for example that you want to model a “mine” metaphor.

2. Making the object trackable by the player’s app.

Once players enter a game scene, their distance from all objects configured as trackable is measured and when they get close enough to some of them (within its radius), a “contact” between them and this object is made. In the “mine” scenario, you would like the “mine” object to be exploded only when the player gets close to it (e.g. within 10 meters radius).

In order for an object to be useful in a game scenario, at least one of the above perception mechanisms must be enabled (or both of them). Otherwise, players will never be aware of the object’s existence and they will never interact with it.

Furthermore, whatever perception mechanism you define for your objects, you can configure under which conditions these mechanisms will be applied. That is, you can set conditions under which an object of this type will be perceived by players (whatever perception means), otherwise, they will not feel the object’s existence at all. Something that may be useful if you want to hide and unhide objects based on the player’s state.

In the following picture you can see how objects are shown on the player’s map in the rollick player app.

A visible object that has been dropped in the game world (in a specific location) as shown to the player on the Rollick app Playground

Object Behavior

You may find it difficult or complicated to design the behavior of objects when creating their object type. Here we will discuss how you can do it by explaining all the possible cases regarding the interaction between an object and a player.

1. General Object Behavior

Objects are interactive entities with wich your players can interact in various ways, either when they get close to them in the physical world (i.e. close to their location), or when they just tap on them in their app.

Each object has an acitivity range (defined by a radius) within which it will be sensible and intractive. This range can be exploited to control object's behavior as you wish.

While available in the game world, an object can expose the following behaviors:

• Pickable: If you define that objects of this type are pickable, then you give your players the ability to pick objects of this type when they find them in the game world and interact with them. If you want to restrict the collection of such objects somehow you can define special restrictions either in total or per time unit (minute, hour, day, etc.). This is particularly important if you don’t want one player to pick all available objects in the game world making other players frustrated or bored.
• Destroyable: If you define objects of this type are destroyable, then you give your players the ability to destroy objects of this type when they find them in the game world and interact with them. If you want to restrict the number of objects a player can destroy, then you can set appropriate restrictions either in total or per time unit.

Making an object pickable or destroyable is not enough to give your players the ability perform such an action on them. You have to define when exactly this behaviour will be impemented during the interaction of the player with the object.

While available in the game world, an object can be perceived by the player or not. If not percieved, there is no interaction at all between the object and the player. Actually, the player does not even sense the object's existence. This may happen because the player and the object are in different scenes, or in the same scene but the player does not satisfy the conditions or constraints that you have set.

Even when the object is percievable, there is no interaction between player and object. However, either the player can see the object on his map (if it is visible) or the player’s app tracks the object (if it is trackable), or both.

To start the interaction with the object, a contact between player and object must be made.

2. Objects Behavior When Contacted by the player.

Contact is the first type of interaction that a player can have with an object. It may be fired either because the player tapped on the object in their map (in rollick player app), or because the player approached the object’s location in the real world (at least closer than a defined radius). What this interaction will be, depends on what behavior you will define on the object for its contact with players. You may define that the object will be destroyed, or picked by the player, or even that the object will be shown to the player. This last behavior is meaningful when an object curries payload information that the player needs to see before acting on the object (e.g. picking it). Object behavior is defined as a script rule (a set of script actions that are executed under specific conditions) and is given a human-readable label (e.g. “Take it”, “Open it”, “Lock it”, etc. ).

Moreover, this behavior may be further configured with two options:

• In range only: If checked, the object behavior will only occur if the player is within its active area (within its radius), otherwise, it shows a message to the player that they have to get closer.
• Automatic: If checked, the object’s behavior will occur without confirmation from the player. Otherwise, the player will be prompted to confirm (e.g. You have found a Diamond. Take it!”)

3. Objects behavior When Acted by the player.

If an object when contacted is shown to the player, then during its presentation the player may be able to further act on it. For instance, the player “opens” an “advise” object and if they find it useful they may want to “collect” it. Again the object’s behavior is defined as a script rule with actions, conditions, and label, and can be further configured whether it will occur automatically and only within the object’s range or not. Remember that the interaction between the player and the object may finish upon contact (e.g. the player picks the object). So defining behavior for when the object is acted is optional.

4. Object behavior While Owned by the player. If the player has picked an object (in the context of interaction cases 3 or 4), then the object is not a shared object anymore but is owned by the player. What the player can do with this object? The object’s behavior (or manipulation capabilities), while owned, is configured in the corresponding section and the options are:

• Redropable. The owner can re-drop an owned object in some other location.
• Redeemable. The owner can redeem an owned object to gain “money”. (option available when the game market is enabled).
• Tradable. The owner may sell an owned object to gain “money”. (option available when game market is enabled).

To implement the redemption and trading of objects, you have to define their price in the terms of the game’s currency.

Player State Data

With respect to objects the following player state information can be exploited:

• Player owns [at least|some|at most|extactly] objects of ObjectType
• Player has [picked|created|destroyed|dropped object] [at least|some|at most|extactly] objects of ObjectType

World State Data

With respect to objects the following world state information can be exploited:

• World has| has not [at least|some|at most|extactly] objects of ObjectType

Offers

Rollick can be used to promote businesses, products, or services through pervasive gaming. Promotion can be indirectly achieved by various means using the elements that we described until now (e.g. creating hot spots by placing objects inside shops or organizations, directing players into shops or organizations in the context of the game plot, etc. ).

However, when game market is enabled, rollick allows you to apply a more direct marketing strategy by including into the game world business offers. Offers are special objects that can be used in a game to allow players to win real-world rewards for their in-game achievements. Such rewards have the form of offer cards for discounted or even free products or services.

Technically, offers are like any other object that carries specific payload information. That is, offers are objects that can be placed into a scene, and the players can interact with them according to the behavior and the conditions that you define. However, by default:

• Offers carry payload information (what the offer is about, who is the offeror, etc.)
• Offers are pickable (players should be able to pick an offer if they want)
• Offers are redeemable (players should be able to redeem their offer cards for real-world products or discounts)
• Offers cannot be created by players (offers are only created by the designer and the game master)
• Offer type is predefined. That is, offers do not follow the object type - object instance pattern. Instead, the designer directly creates an offer instance and places clones of this instance into the game world (initial or not). All clones remain synchronized throughout the game period with respect to the offer quantity. Creating an offer is quite similar to creating an object type. You need a title, a description, and a media icon. The main difference is that you can't define your own payload properties. Instead, you have to populate its predefined and required payload properties. These properties are
• Quantity. Defines the number of available offer cards (or coupons/vouchers) available for this offer. If for example, you define a quantity of 100 for the offer “1+1 cinema tickets” this means that when the offer will be added into the game world, only 100 offer cards of this offer can be picked by players. If you don’t define quantity (or define -1), then there is no restriction on the number of offer cards that can be taken by the game players. If more than one clone of this offer are placed into the game world (e.g. one in the city center, and one outside the cinema theater) the offer quantity is an aggregate limit for both of them.
• Offeror Name. The name of the organization or company making the offer.
• Offeror Address. The address of the organization or company making the offer.
• Offeror Logo. The logo of the organization or company making the offer.
• Offeror Url. The website URL of the organization or company making the offer.
• Offer Text. This is the text that describes the offer. Include here a description of what the offer is about, what the player has to do in order to get an offer card, and what else you want
• Offer Terms. The terms under which the offer is given. For instance, the 1+1 cinema tickets can be only used every Thursday night.
• Offer Cover. The media (image or video) that will be used as a cover for the offer. The cover is the main image that the players view when contacting (opening) an offer object. The rest configuration is like any other object you define. With conditions you can control its perception, you can control when the player can pick an offer card, as well as you can impose constraints on how many offer cards a player can pick either in total or per time unit (hour, day, etc). An example offer is shown in the next image (the player has contacted the offer icon on the map and this is the offer preview).

Other important hints for a well-designed offer are:

• When contacted, an offer should be just viewed by the player and if they want to pick it
• Offers can have a price which is actually the amount of currency the player has to spend in order to pick an offer card. If set to 0 then the offer is considered to be given for free in terms of the game market currency.

Player State Data

With respect to offers the following player state information can be exploited:

• Player owns [at least|some|at most|extactly] OfferCards of Offer
• Player has [picked] [at least|some|at most|extactly] OfferCards of Offer