At its core a process is a way of structuring your players interactions with the game. You can create a simple linear sequence of activities for a player to do or complex choice driven quests.
Processes are the most powerful component available to you in a game. They make it possible to create complex and flexible player journeys. The way you use processes depends on the type of gamified system you wish to make.
There are several benefits you can reap from well defined processes within a game:
- Sketching out the player journey as a process forces us to think through the actual player experience. We can put ourselves in the player's shoes, and that helps us design better experiences.
- Processes enable you to change the player experience and see the impact immediately in the game.
- Breaking down an activity into many short steps enables the player to receive feedback on each step. This increases the probability of a player making it through the entire process especially if its long.
- Processes make it easy for us to find out which step of a activity causes people to get stuck or give up. We can then use that insight to improve the player experience.
- Finally processes enable you to create external games much faster. Playlyfe takes care of all the complex state transitions and player progress tracking.
Processes are great when you need to create things like skill trees. In the context of an online education platform, good skill trees encourage players to learn and allow them to build their own skill set as per their interests. The process of guidance can be very easily tweaked and tested with Playlyfe.
With features such as Lanes and Escalations, processes work well for role based activities too. In an organization, processes are generally well defined and often involve people with different roles, which makes processes in playlyfe a natrual fit.
Building a Process
A process consists of a set of nodes connected together with a set of flows. There are 4 types of nodes that you can create in a process:
These are the bread and butter of a process. A task can be any activity that you wish your players to perform. All the other nodes are just helpers to control the order in which tasks can be performed. A task can have only 1 incoming flow (in-flow) and 1 outgoing flow (out-flow).
Basic Task Properties Property Description ID A unique ID for the task within the process/sub-process Name A name for the task Loop Count The number of times a player can loop over the task. [default: 0] Lane The lane to which this task belongs
A sub-process is almost the same as a process. You can use sub-processes to model complex processes which are big and difficult to visualize. You can also use it to break down the player journey into different modules.
Basic Sub-Process Properties Property Description ID A unique ID for the sub-process within the process/sub-process Name A name for the sub-process Instance Key A unique key which identifies this sub-process from all other sub-processes within the process. You can use this to access a particular sub-process within a complex process from the API. Loop Count The number of times a player can loop over the sub-process. [default: 0] Lane The lane to which this sub-process belongs
Diverging parallel gateways allow a player to perform many different task in any order they wish (i.e., in parallel).
A diverging parallel gateway has more out-flows than in-flows.
Converging parallel gateways allow a player to proceed along the out-going flow only after they complete all in-flows. It provides a way of synchronizing different paths of progress before moving forward.
A converging parallel gateway has less out-flows than in-flows.
Basic Parallel Gateway Properties Property Description ID A unique ID for the gateway within the process/sub-process Name A name for the gateway Lane The lane to which this sub-process belongs
Diverging exclusive gateways allow a player to perform exactly one task from among the many available alternatives.
A diverging exclusive gateway has more out-flows than in-flows.
Converging exclusive gateways allow you to merge progress along different paths together.
A converging exclusive gateway has less out-flows than in-flows.
Unlike converging Parallel gateways, converging Exclusive gateways allow players to proceed along it's out-going flows before they complete all in-flows.
Basic Exclusive Gateway Properties Property Description ID A unique ID for the gateway within the process/sub-process Name A name for the gateway Lane The lane to which this sub-process belongs
Building processes using nodes and flows is fairly straight forward, however, there are some restrictions:
- Tasks/Sub-Processes can only have 1 out-flow and 1 in-flow
- Gateways can be either converging or diverging.
- Diverging gateways have atmost 1 in-flows and atleast 1 out-flows
- Converging gateways have atmost 1 out-flows and atleast 1 in-flows
All nodes without any in-flows in a process are called Start Nodes. When a player starts a process, the very first tasks available to him are the Start Nodes in a process.
Common Flow Patterns
There are a lot of things you can achieve with processes, from designing approval systems, to parallel quests and more! We illustrate some of the most common flow patterns below:
You can use this flow to model a linear sequence of activities which the player must perform.
You can use this flow to model a simple approval mechanism. In the diagram, only candidates of the admin lane can perform the approve task. When a player finishes the approve task it resolves the scoring actions on the work task.
Parallel Split Flow
You can use this flow to model many choices available to a player which the player can perform in any order.
Exclusive Choice Flow
You can use this flow to model many choices available to a player out of which exactly they can perform exactly one choice.
You can use this flow to synchronize several paths that a player could take at a common point before moving forward.
You can use this flow to merge several paths a player could take at a common point. It allows the player to move forward without finishing all incoming paths.
Cancelling Merge Flow
You can use this flow to merge several paths a player could take at a common point. As soon as the player reaches the common point, all tasks on incoming paths are cancelled. Players cannot complete a cancelled task.
Sub-Processes are an effective way to manage arbitrary complexity within your processes. Sub-Processes are like small processes within a larger one. There are a few things you need to know to work with sub-processes.
Task IDs in Sub-Processes
Sub-Processes add a new context for your tasks. This means that two different sub-processes can have tasks with the same IDs within them. This can be useful for repeated tasks across many sub-processes.
- Hover your mouse over the sub-process.
- Click the expand icon which pops up (1).
You will now see the internal details of the sub-process. You can see a breadcrumb which appears at the bottom of the showing the root process at the leftmost end and the sub-process to its right. You can click on any part of the breadcrumb (2) to navigate to that sub-process.
Lanes are a restricting mechanism used to divide the tasks within a process among different types of players. This allows you to co-ordinate complex activities between many different teams of players.
Candidates of a lane are eligible to perform tasks/sub-processes/gateways belonging to that lane. Players can be a part of multiple lanes and cannot perform tasks in lanes they are not a part of.
Playlyfe allows you to control the rate at which any task or sub-process within a process can performed. You can use this to create an effective an anti-gaming mechanic which prevents players from abusing your system. You can also use it to effect scheduled daily, weekly or monthly tasks.
There are 3 different types of rate limits that can be applied, they are:
Rolling Window - A moving window type rate limit essentially means that at any given point in time, the activity can only be done a specified number of times in the last interval. Let us say your rate limit is 5 times per day, this would translate to a limit of 5 times in the last 24 hours (more precisely, in the last 24x60x60x1000 milliseconds) at any given point in time. Since we need to store timestamps for each event, there is a limit of 50 events in an interval. This is the default algorithm.
Fixed Window - In a fixed window rate limit, the windows are fixed at particular time intervals - minutes, hours, days, weeks, months and years. What this means is that if your rate limit is 5 per day, the activity can be performed 5 times in a calendar day. In this alogirthm, the game's timezone is used to figure out calendar limits. The interval unit has been restricted only to 1 (i.e. 5 times in 1 day, in 1 minute, etc) as some other values can lead to unexpected results.
Leaky Bucket - The leaky bucket algorithm, though generally used in the world of networking, might also find use in games. You can read more about it here.
Rate Limiting a Task/Sub-Process
- Select the task/sub-process you wish to rate limit.
Click the Timed tab in the property window of the node.
Click the Limit Rate button and specify the rate you want to cap the task/sub-process at.
Triggers emails enable players to interact with a process through their email.
Setting up a trigger email
- Select a task/gateway and go to the
Click the Set Trigger Email button
Write the trigger email template and notification message.
You can customize the email itself with simple tags to provide contextual information.
|[[user]]||Complete user name|
|[[user:first_name]]||User's first Name|
|[[user:last_name]]||User's last name|
|[[actions]]||Available actions that the player can take. If the trigger email is set on a task/sub-process the successive node is the only possible action. If it is set on a gateway all available out-flows are possible actions that the player can take.|
|[[global_logs]]||Recent game logs (level + achievement logs) from the last trigger|
|[[local_logs]]||Recent activity logs in this process from the last trigger|
|[[date]]||The date when the mail is sent|
Playlyfe sends an email whenever a node with an trigger email is completed. The recipient of the email can be set by using the following options:
Target The Target can be set to either one of these options.
Option Description Myself Sends an email notification to the player who completes the task. Teammates Sends an email notification to the teammates of the player who completes this task. Members of this process Sends an email notification to all members of this process. Teammates of all members of this process. Sends an email notification to all the team members of all the performers of this process.
Target Requirements In addition to the above, additional conditions can be specified in target requirements.
If the email had triggers and the recipient was not a performer in the process, he can be added into the process. The lanes and roles he joins with can be defined in target roles. He can then act on a trigger email by replying with the number specifying the action they wish to take on the trigger.
A task/sub-process can have multiple rewards which take place when they are completed. Rewards change the scores of the player who performed the task/sub-process.
Advanced Scoring Mechanics
Besides the normal simple scoring mechanism, Playlyfe provides you a number of advanced scoring mechanics which can be used to make complex gamified experiences.
When a player completes a task the scoring actions associated with it are always applied to the player. Using the chance mechanic you can specify the probability of Playlyfe applying a reward.
There are 2 types of chance mechanics currently:
- Activity Reward Chance - This is the probability of Playlyfe trying
to apply the rewards of an activity. If the activity has no rewards this
does not have any effect. You can do this if you have many rewards on an
activity and wish to have Playlyfe always apply them together.
- Individual Reward Chance - This is the probability of Playlyfe
applying an individual rewards to a player. You can do this if you want to
set a different chance for applying each reward on the completion of an
You can combine both Activity Reward Chance and Individual Reward Chance together on a single activity.
You can use scoring resolutions to delay the application of rewards on a player. Instead of applying the rewards on completion of a task you can specify a second task as the resolution task for the reward.
Playlyfe resolves the reward and applies it to the performer of the first task once a player completes the resolution task .
The resolution mechanic can be combined with lanes to create an approval flow
Recurrence is a mechanic which only works with looped tasks. Usually, Playlyfe applies the reward on a looped task only once the task has been completed. A looped task is considered to be complete only after all it's loops are complete. Sometimes this is not the desired behavior. You may wish to apply the reward on every loop of the task. This can be done by marking the reward as a recurring reward.
Scopes let you create leaderboards for an arbitrary group of players. These are particularly useful when you want to create groups based on the source of an event.
Scopes are available only from Playlyfe API v2.0
Consider a class in which students are being offered various optional courses. Each course has quizzes which on completion grant rewards to the students. To maintain a leaderboard for any given course, instead of creating teams for each course, you can simply pass the course's name or any other unique identifier as the scope and a leaderboard for that course will be created on the fly. This leaderboard will only track actions/rules/processes that have been performed with the given scope.
Scopes are currently available only via API and are not available in the
simulator and would need a custom leaderboard in the design of the game.
When executing an action, rule or task, you need to pass the scopes an array
of objects with a keys id and entity_id. The id is the actual scope ID
entity_id is the ID of the player who is being scored.
Joining channel basically lets you manage how other players can join a process. There are 3 choices:
- Free To Join - The process is visible and anyone can join it with any role and lane.
- Request Based - The process is visible but players need to request access to join the process.
- Invite Only - The process is not visible to players who are not a part of the process. Players can only join via invitations.
Conditions that the player must satisfy in order to be able to create a process instance.
Restrictions can be set on the process creation itself. These restrictions can be either per player restrictions or global restrictions.
- Process Limit - Limit the maximum number of process instances created. Default: Infinity
- Active Process Limit - Limit the number of maximum active processes that can exist at any given point. Default: Infinity
There are two parts to a process:
- the design, which we call the definition of the process, and
- the instance, which is created by the players when they are in the game
Both the definition and the instance have very separate structures. The definition structure is as follows:
Process Definition Structure
The design structure is what is used when you are making the process.
|id||A unique ID for the process.|
|name||A name for the process.|
|description||A brief description of the process.|
|image||An image which represents the process. You need to send a multipart form POST request to upload the image data.|
|settings||Settings for the whole process. See the Settings section for details.|
|lanes||Lanes can be used to retrict players to a particular task/tasks. Each lane has a structure described in the Lane Structure section below|
|id||A unique ID for the process.|
|access||The access settings with which the process instance can be created. It is an array which can contain any or all of these PUBLIC, PROTECTED, PRIVATE. When players create an instance of this process, they get the chance to choosing only one of the access settings you set in the array.|
|max_global_instances||The maximun number of process instances that can be created from this process.|
|max_active_global_instances||The maximun number of active process instances that can be created from this process|
|max_player_instances||The maximum number of process instances that a player can create from this process|
|max_active_player_instances||The maximum number of active process instances that a player can create from this process.|
A set of conditions, which will determine if the player can see this definition in the game or not.Click here to see the creation requirements structure.
Creation Requirements Structure
This allows certain checks to be performed to make sure a player can actually see/perform/join the task, action, team.
|type||The type of condition. It can be one of metric, action, team, and, or.|
|not||If true, inverts the condition. So any check which would usually evaluate to true will now evaluate to false.|
|expression||An array of contexts joined with an AND or OR operator. This field is only applicable if the condition type is and or or, and replaces the context field.|
|context||The actual comparison expression.
The structure changes depending on the type of condition selected. The
structure for each condition is defined below:
Metric Based Condition
Condition which depends on a player's score for a particular metric
|id||ID of the metric.|
|type||Type of the metric being used for comparison.
For set metrics, there is an additional item field which denotes the set item
|item||The set item whose value will be compared.
This field is only available if the metric type is set.
Can be one of the relational operators:
|value||The value of the metric that the player should have on his scores.|
Action Based Condition
Condition which depends on how many times an action has been performed.
|id||ID of the action.|
|operator||Can be one of the relational operators: eq, ne, gt, ge, lt, le.|
|value||The number of times the action should be executed by the player.|
Team Based ConditionCondition which depends on how many times an action has been performed.
|definition_id||Definition ID of the team which the player should be a part of.|
|role||The role the player should have within the team of this type. If you don't care about the role, then you can ignore this field.|
All Conditions: andAn and condition, which is shown as All of the following rules can be used to join two or more conditions such that the whole condition will be true only when all of the child conditions are true.
Any Condition: orAn or condition, which is shown as Any of the following rules can be used to join two or more conditions such that the whole condition will be true even if only one of the child conditions become true.
|name||The name of the lane.|
|default||If true, all players who join an instance of this process will automatically join this lane.|
Activities are the tasks or sub-processes within a process. They can have rewards attached to them.
|id||A unique ID for the activity.|
|name||Name of the activity.|
|type||Whether the activity is a task or a sub-process.|
|lane||The lane in which the activity belongs to.|
Number of times a player can perform this task.If loop is not set, the player can perform the task once.
If loop is set to 10, the player can perform the task 11 times.
|rewards||The rewards which the player can earn upon completing this task.|
|requires||The requirements for performing the task.|
|probability||Chance that the player will get any of the rewards on completing the task.|
Gateways are used to restrict access to certain tasks and sub-processes based on the process state. They cannot have rewards on them.
|id||A unique ID for the gateway.|
|name||Name of the gateway.|
|type||The gateway can be either parallel or exclusive.|
|lane||The lane in which the activity belongs to.|
Sequence Flow Structure
Sequence flows are lightweight objects which connect other nodes (activities, gateways) to each other. Each sequence flow has a source node and a target node.
|src||The node from which the sequence flow originates.|
|target||The node to which the sequence flow ends.|
|retry||If set to true, the player can retry a task if he fails. Default is false|
|lane||The lane in which the activity belongs to.|
Process Instance Structure
They represent processes or sub-processes. They must contain a field key which must be unique.
|key||Represents a path to a process or a sub-process. If the key is the process instance ID then it represents the process instance container otherwise it represents sub-processes. The key is used to trigger tasks in sub-processes without acutally specifying the full path to the task.|
|nodes||These represent all available nodes within the process or sub-process. The node can be of 2 types:|
Process Instance Task Structure
|id||The ID of the task or sub-process. This represents the path to the process or sub-process.|
Can be one of three states:
|loop||The number of times the player has perfomed this task.|
The players within this task who have performed this task at least once.
Each performer has the following keys:
Process Instance Gateway Structure
|id||The ID of the gateway.|
It represents all the tasks or sub-process connected to this gateway. It is an array in which each element contains: