Global elements are all elements in your experience that are shared across the entire experience and all scenes.
The "Roles" section of the project creation tool is dedicated to defining the participants in your experience and how they communicate and interact with your experience.
A Role is a specific part for a character in your experience. These could be participants: players or teams, actors, crew, or staff members. Or these could be automated characters like NPCs or chatbots.
State in your experiences is tracked by role, not by individual participant. So, for instance, if you want a team of several players to all progress in your experience in lockstep, then they should share a single role. If, however, you want different players to progress independently within a single run of your experience, there should be a different role for each type of player.
Some example experience designs that will have different role setups:
- A single-player experience might have one role for the player.
- A competitive experience with two teams might have two roles, "Team A" and "Team B". You can increase the "Max users" of each role to allow multiple participants on each team -- but those participants will progress in lockstep.
- An immersive theater type experience will have one role for each actor participant, and one or many roles for the audience.
- A digital remote game might have one role for the player, and a role for each automated simulated character.
If you want a role to be able to interact with your experience using a webpage, you need to add an Interface. An Interface creates the frame for viewing a web UI for your participants, and all aspects of this interface that will stay consistent over the entire experience, including color and styling.
Over the course of your experience, you'll navigate participants between their various pages, each with different content. All of the pages that a participant can possibly see will be created within the interface associated with that participant's role.
The simple default interface just shows a role's current page. If you want, you can make a more complex interface by adding tabs, and then your participant will be able to switch between the tabs at-will. For instance, you might have one tab that is the current page, one for browsing messages, and another that's simple help text.
You can also set an interface as an "Entryway" if you like. If checked, Charter will make a web form available where new participants can join your experience.
An interface can be shared across multiple roles. For instance, if you have four subgroups of participants that are in different places in the story, you can let them share the same Interface. Then each subgroup or role will be viewing a different slide in the deck, but they will share the deck, so you won't need to duplicate your work.
Once you've created a role, if you want users with that role to text message or have phone calls with another participant, you'll need to add a Phone line. Roles can have multiple phone lines with different other roles: in this case a different phone number will be assigned to each counterpart.
Each phone line belongs to a certain role: that is the role who will be sending and receiving texts over SMS, or making or receiving phone calls.
Each phone line also has a "Counterpart": that is the role who messages and phone calls will be exchanged with.
Say, for instance, if there is a phone line for the "Player" role with a "Guide" role as its counterpart. If the Guide sends a message to the Player, it will be sent to the user in the Player role's phone number if present. And if that user responds, the incoming message will be sent back to the "Guide" role, and a Text received event will occur.
Optionally, a phone line can have an "Impersonating" value. For instance, you could have a phone line for your "StageManager" role, with a counterpart of the "Player", and impersonating an "Actor" role. In that case, if the stage manager user texts that phone line, the message will be sent to the player as if the actor user had texted it.
Normally, phone lines are allocated dynamically and may be different for each participant. If you want a public phone number for your experience that will always be the same, you may configure a phone as an "Entryway" by checking that option. Entryway phone lines will always be the same, and can be used to start new runs of your experience. Any user who texts or calls the number of an entryway phone line will start a new run of your experience, and will be added as a new player.
If you want a role to be able to send and receive emails, you can add an Email account. The specific email address cannot be customized at the moment, but that ability is on our roadmap.
The Places section of the interface is where you define locations for real-world, site specific experiences, if those are used by your experience.
You'll define a Place for each part of your experience that can happen on a specific site. Most places will have only one "Location", or physical address.
Some experiences may want to have multiple locations for a single place. For instance, if you want to send your players to different restaurants for a snack break, you would define one Place, called "Snack" (the name of what happens in this place), and several Locations, one for each restaurant. You can then specify the specific location for the "Snack" place uniquely for each run of your experience.
You can define Routes between Places. These routes are used to provide walking or driving directions between those places. These directions will be calculated for every possible location for both of those places.
When creating your projects, you'll create behaviors matching the abstract definition of many variables in your experience: Moments instead of clock times, Places instead of physical locations, and variables instead of specific values.
The Defaults section of the project creation tool is where you attach specific values to those abstract identifiers.
A Moment indicates that there is a certain time that will happen in each the runs of your experience. For instance, "Dinner time" might be a moment, or "Start of experience", or "Ferry departure".
You do not define the clock time of the moment when creating the moment, because that clock time might be different for different schedules of your experience. Clock times are defined in Variants, defined below.
A Variant is a set of default values for your project for its Moments, Places, and variables. Each project has an initial variant called "Defaults", and if you are only running one version of your experience, this single default variant should be enough.
Each variant has a few sections.
- Variable defaults define initial values for variables, which can then be read using conditionals like Variable contains, inserted into displays or messages using Text insertions, and updated using actions like Set variable.
- Customization defaults allow you to define default values for customizations. Customizations are for text values that you want to be able to set and edit as experience administrators in the Operations view. For instance, you could use a customization to enter the food preferences of a guest, or their license plate number. Customizations can be inserted into displays or messages using Text insertions, but cannot be updated within the experience itself.
- Moment schedule defines clock times for each Moment in your experience, relative to the start date and time zone of each run. So you would specify
12:45am, which would be interpreted as that time on the day of the experience. You can specify clock times in subsequent days by using a value such as
+1d 3:00pm, or