Items are a basic object type in ARIS. They are different from plaques in that players can pick up, drop (on the map), and destroy them, not merely visit them. They are similar in that they have media (image, video, or sound) and text (detail), an icon, and a title. Images in items can pinched and zoomed.
Items also have quantity. For example, a player can have 5 dollars if you have an item called dollars. Other object triggers, conversation choices, and other parts of an ARIS game can require that a player have a certain quantity of an item.
There are 4 types of items:
- Normal - shows up in Inventory, has an icon, media, and description;
- Attributes - shows up in Player, has an icon, media, and description;
- Web Items - shows up in Inventory, has an icon, description, and links players to web pages via a URL; and
- Hidden - is not visible in Player or Inventory, and has a description.
Attributes cannot be dropped or destroyed, think of them as aspects of the player rather than things the player is carrying.
Hidden items do show up in some circumstances:
- When you make a trigger for them and place them on the map,
- When a player receives or loses them (if the author has checked "Notify on Change")
Many aspects of items are set by the game’s author. In particular,
- Whether the player is notified of changes in an item's quantity,
- Whether a player can drop, destroy, or trade items (not for attributes),
- the max quantity of an item a player can carry,
- the weight of an item (players can be assigned a maximum inventory weight, not for attributes), and
- how many of an item are at a given location, given or taken by another game object.
Once your item is given or taken by other parts of your ARIS game (plaques, conversation lines, quest notifications, etc.) a summary of where your item is in use (small icons) will show at the bottom of the "Edit Item" interface. This can help you keep track of your game.
World and Group Items
With World and Group items, you can create collaboration (or competition) across players within ARIS. To help make sense of this, you first need to understand the concept of "State".
"State" can be considered simply as the bundle of adjectives that describe something. In the case of the player, an example "state" he or she might be in is as follows: "Player Has 5 Bananas. Player Has talked to Bill. Player is in scene 4. Player Has not yet talked to Amy.".
Every time the player does something (gets an item, sees a plaque, etc...), that player's state changes (from "having 5 Bananas" to "having 6 Bananas" or from "not having seen Plaque 'Intro'" to "having seen Plaque 'intro'").
You might notice that this "state" sounds a lot like the words used to describe locks within ARIS. That's because "state" is precisely what the locks use to determine whether or not they are to be currently active!
We can use this state through locks to create a kind of flow through the game. "Player needs to be in this state to see the first part of the game, which puts them in that state so they can see the second part of the game, etc...".
One interesting thing you may have noticed is that so far, we've only considered the state of the Player in constructing our game's flow. What are we to do if we instead want some state external to one single player to dictate how the game plays out?
You can think of World Items as an inventory owned by "The Game". Any player can give items to the game, or take them away. The purpose for this, is that it gives the "world" its own "state" (World has 5 Bananas, etc...). You can use this state to orchestrate locks in the same way you would for a Player- the only difference is that this state effects everyone playing at once.
For example- you could have a character that commands all players to "stomp 100 goombas". Without world items, you might accomplish this by giving the player 1 "goomba stomped" item every time they interact with the "goomba" plaque. The next part of the game would be gated by a lock stating "Player Has At Least 100 goomba stomped items".
Unfortunately, this would require every single player to stomp 100 goombas themselves. What if instead you just wanted to make sure at least 100 goombas were stomped in total?
The only changes you'd have to make are these: instead of giving the player 1 "stomped goomba" item every time a goomba is stomped, you can instead give the world 1 "stomped goomba". Then, set the lock for the next part of the game to "World Has At Least 100 goomba stomped items".
That means that if 5 people are playing, each player only needs to stomp 20 goombas, and the next part of the game will be unlocked for all of them!
It is a bit bizarre that we're "giving the world 100 stomped goombas items"- the metaphor of "inventory" and "world" breaks down a little bit here. But if you're willing to break down that abstraction into what it's actually doing (setting/changing the "state" of an object accessible to all players), you can really accomplish some creative things!
If world items are so great, why do we need group items?
Well, when you have big, globally accessible objects ("The World's Inventory"), you have to be careful about some things.
For example- in the "stomping goombas" scenario listed above, there's a problem. The game can only be played once!
Once the world has over 100 "stomped goombas", for any new person that plays (even months later), the world will still have over 100 "stomped goombas", and the player will immediately have access to the later parts of the game!
There are a couple ways you could handle this. One would be to create some secret plaque that "resets" the game (by taking away all of the "stomped goombas" from "The World"). But maybe you have 10 different groups coming in and don't want to have to do that 10 times.
This can be accomplished by creating 10 "Groups". Each group you make creates another "inventory" (or "state"), but this time, only accessible to those within that group.
For example, let's say you create group A, B, and C (creating only 3 instead of 10 for simplicity). The first thing in the game can ask what group the players are in, and can then assign each player to the appropriate group (you might simply tell everyone in your first group to join group A). Now instead of each goomba giving 1 goomba stomp to the world, you give 1 goomba stomp to "the group". The lock on the latter part of the game would require that "the group has > 100 goomba stomps".
This way, everyone within group A gets to work on and reference the same external state, without muddying up anything used by group B or C (when group B begins, if they join the appropriate group, they will be able to start from scratch).
But this is just one instance of using separate group states. You might assign half of the players to group A and half to group B, and then have them race to grab 100 goomba stomps!
Some quick technical details
All of this is managed through events and locks. From within an event, you can give, take, or set items for the Player, the Player's Group, or The World. You can set the player's group to any group you've created from within an event, as well.
Any lock has the ability to reference the quantity of any item held by the Player, the Player's group, or The World.
Good luck! And get creative with what this kind of global state can offer!