Factories open up a new dimension to creating augmented reality experiences with ARIS. At a basic level, they throw an aspect of the randomized algorithm into the locational aspects of the ARIS platform, making it possible to have AR games that are a bit more gamey in how they activate a space for players. Without factories, you have to plan all your player’s location-based interactions to a “t”. With factories, you can structure the chances of their encounters instead.
So why would you want to do something like this? The truth is that I don’t know all the possibilities, but there seem to be a lot of them. I’m excited about exploring what they are and how this algorithmic element can allow us to further map out what AR is all about. As usual, I’d like some company along the way. This article along with some past and future posts will roll a number of ideas around this topic together into a nice little Katamari. Altogether, we can:
- Introduce Factories and explain how to use them in ARIS (this post),
- Give examples of games based on factories (upcoming),
- Introduce a “learning through design” activity/assignment to help designers deal with the “blank slate” problem of creative endeavor (here), and together
- Begin a conversation about what algorithmic locations can add to what AR is all about (upcoming).
Let’s begin where I did three years ago, with a pulled muscle.
I got off the phone with Dave Gagnon (leader of the ARIS project) one summer day, down in my basement office. He was updating me on some recent changes to ARIS, in particular a little idea Phil Dougherty (lead ARIS developer) threw in for fun, factories (back then it was called spawning). Half an hour later I called Dave back, out of breath, and nursing a sore hamstring. In between I made and tested my first prototype of a game that ended up being called Rupee Collector. The immediate discovery: factories are fun!
Factory Use #1: Get there before it’s gone. Rupee Collector makes use of a simple mechanic, placing rupees around the map at random and for short intervals of time. You run to get them before they disappear or your friend gets there first. It’s almost like turning the normal world into a game of Pac Man (maybe someday I can do Pac Man for reals!).
In the years since that pulled muscle, I’ve found a bunch of great uses for factories, and as we get new features in ARIS today, I’m excited about how to put them together with this simple gem. I hope that by showing more people what I know about factories, we can get a whole lot more experimentation with algorithmic locations.
Aside: Factories are also a good lesson about how to move platform development forward. They are a simple and generalizable feature. They worked perfectly almost from day 1, and directly addresses the relationship between a person and a place (the raison d’etre for AR). I have many times argued for work to be done on complicated or vague features, or those whose development brings something from another game or mobile environment to ARIS. We have tried a lot of these and watched them fail or drag us down. For example, the Notebook, though also very interesting, is super complicated and is essentially Evernote with a map. We still don’t know how it integrates with the other elements of ARIS. The Notebook is interesting and important but a bit of an Albatross.
Example – Rupee Collector
So to see both what we can make with factories and how to actually use them, we can walk through a modern version of that first algorithmically based game.
Give Rupee Collector a try (15 minutes will do, best if you play with at least one other person in an open area such as campus or a field).
Looking Under the Hood
So how does Rupee Collector work? What factories did I make and how are they set? In addition to some other cruft, we have the following constellation of objects:
- Green Rupee
- Blue Rupee
- Red Rupee
- Green Rupee
- Green Rupees
- Blue Rupee
- Red Rupee
Each kind of Rupee on the map (green, blue, red) is worth a set number of rupees (points), a la Zelda. The Green Rupee plaque hands out one rupee (item), 5 for blue and 20 for red respectively.
N.B. Notice the player encounters plaques on the map, not items. One reason is so I can have a commensurable point value as just described, but another is that I almost never put items directly on the map in any game. Instead I have plaques hand out items. The UI for item-interactions is just a bit clunky and there are some formal considerations as well.
The factories generate triggers for the plaques. I have one for each color, but two for green so that there is one green rupee rather near to a player and a few more a bit farther out. These factories tell the ARIS server, under certain circumstances, to add rupee plaques at a certain distance from the player at certain time intervals up to a maximum number. And that brings us to some basic information on factories themselves.
Recall that in ARIS, objects are the actual content one authors and triggers are how players access those objects (if you’re not familiar, start here). Factories are a system for algorithmically creating triggers.
Factories let you decide
- How often, and
- How many
triggers will be in the game for a given object. The screenshot from the editor below is the full panel of options available to authors. It takes a little effort to fully parse this system and its effects.
Factories generate triggers within a ring.
The ring has three important features:
- Center. This can either be a player or a fixed location on the map.
- Minimum distance. Spawned triggers will be at least this far away from the center of the ring.
- Maximum distance. Spawned triggers will be at most this far away from the center of the ring.
If you look at the rings for any of the four factories in Rupee Collector, you can see that they are all generated with the player at the center. One of the green rupees is very close, another is a bit farther, and the blue and red rupees are generally a bit farther out from the player.
Note that you cannot specify the direction in which the rupees fall or any other specifics about their location, for example that triggers spawn on roads (maybe someday). Care must be taken to make games based on factories playable in the actual situations they will be played in. For instance, if the play location includes buildings where the spawned triggers would be inaccessible, the author could create larger radii around the triggers so the player can reach them from farther away, or increase the number or frequency of spawning so that a player simply has more chances to get one of them.
Factories generate triggers based on what the server finds on the map, inside the relevant ring, when it is told to check.
- Timer. This is how often the ARIS server checks the ring. If the number of triggers inside the ring is less than what there should be, one is added.
- Percentage. This is the chance that a new trigger is added. I almost always choose 100 here. Keep it simple.
How Many and Other Details
The factory settings panel (e.g the one pictured above from Rupee Collector) also includes a couple relevant parameters on other lines to complete the picture.
- Maximum number of triggers. This is how many triggers should be in the ring and can be enforced per player or total—a maximum among all players of a game.
- Time to expire. How long a spawned trigger lasts on the map before it disappears.
- Expire when viewed. This is what can make factories feel like games. If this is checked and one player views the object, the trigger disappears (for all players).
- Trigger options. All the options you would normally expect for a locational trigger (availability range, etc.) can all be set in the sub-panel on the right side of the “edit factory” panel.
This isn’t everything about factories, but should be enough to get you started and hopefully start playing around with the different options and the new kinds of gameplay that are made possible. In future posts, I’ll share some further examples of games based on factories and ask some questions about where all of this is heading.