Terri Nelson, a professor at California State at San Bernardino and long time ARIS user gave a close look at her ARIS game, Paris Occupy for a COERLL (Center for Open Resources for Educational Language Learning) webinar.
I saw her talk about her game at CALICO last May. I and every one else was on the edge of their seat for the whole hour. It’s a rare and special treat to hear someone talk in depth about their design from both the game maker and pedagogical points of view. You can learn a lot about the potentials of AR games, language learning, and also the triangulation of needs that can happen through the design of game-based learning environments.
It’s great talk and I’m really glad they recorded it and put it out there for us. It’s also a pretty deep game. She is one of very few people who have used the weight feature for example.
ARIS is most often used to author content for players to experience. But it also holds functionality for you to send players out to experience the world and share what they find with each other and you. This can be data collection, photo mapping, etc. The Notebook allows players to record geolocated media (video, audio, photo, text) and together to build a collaborative record of their explorations. This functionality has broad potential and combining data collection features with the other affordances of ARIS (making games, telling stories, etc.) is a truly unique thing. Being able to richly establish a context for those who you are sending out to do the collecting is a fantastic opportunity.
Buuuuut, if you’ve actually used the ARIS Notebook, if you really had people go out there and collect some pictures, etc. then you know that clutter is a problem, especially when there is a good deal of non-Notebook content you need players to see. After a bit, the map just looks like a mess.
In ChronoOps, by the 503 Design Collective, notes left by players obscure the map and authored content.
Clutter exists because every note is marked on the game map for all players. This can be useful for viewing notes later, but it can really get in the way too. ARIS will continue to evolve, so this clutter may eventually be less of a problem. But there are some things that you can do right now as an author to clean things up for your players. Continue reading
If you haven’t made a new game in ARIS in a while, you’ll be happy to know that the long nightmare is finally over: you can now set a default location for your game’s locations!
That’s right! No more moving every single trigger from Madison, WI to your location. Depending on what you allow your browser to know about you too, ARIS will default the above “create game” screen to show your current location, making it even more convenient in most cases.
When you set this location, and make new (location) triggers in the editor, they will start out at this default location. It should save countless frustration.
This feature has been in the beta editor for some time, but today I noticed it in the vanilla editor.
Giving an item to the world and to the player in ARIS
World items are items possessed by the game world, not a player. They can be used to define the state of the game world and have it respond to players. This makes ARIS far more capable as a multiplayer engine.
This post is an intro to world items: how they might be useful, how to use them, and the ARISjs you need along the way to get the most out of them. We will do this by looking at the design of a concrete example, The Button, an experimental game Jim Mathews put together for the recent ARIS Global Game Jam.
Strap in, let’s go for a ride!
Screenshot from the article. Looks like ARIS, no?
Today, the NYT has a web article about a scientific mission to Greenland. This is very fancy web design, something only the most headlined of articles receives. About halfway through reading it, I thought, “What if this was an ARIS game?”
Many of the visual techniques and visual sources are a good match to what ARIS can do (overhead satellite maps, on-site videos and images) and the techniques try to pull the audience into the story by giving them some feeling of control (zooming the satellite shot into the basecamp as the viewer scrolls the page). The bulk of the article itself puts you inside the trials and tribulations faced by the team trying to conduct research in such a far-off, extreme place—again a good match to the strengths of ARIS and a bit different approach than communicating the underlying scientific ideas or the consequences of ice melt on this scale. There was even a portion of the article where the image of the ice from the top looked just about exactly the way it would if you had done it in ARIS, faded and transparent blue circles around points of interest.
So how about it? Would anyone take me up soon the challenge of producing a version of this story in the medium of ARIS?
I think such an undertaking, and other similar translation style activities, could teach the author a few things about how storytelling in this medium might work and how it can be similar to and different from the fancy web format. I also wonder:
- Is vicarious travel, tapping points on a map as opposed to more typical AR game design, worth undertaking? Is it compelling? Can it improve over handing someone Google maps as a set of points of interest and bring someone into the story?
- What are the possible effects of placing someone in the story as opposed to telling them about someone else’s?
- What choices do we make about what to tell and what to show? What do we hope someone gets out of being in the audience?
- If a few people do this, how different are the results? To what extent do either the software or our perceptions of it determine how we try to tell stories with it?
- What other game or game-like formats would be a good or different match for this task? e.g. how does ARIS compare to RPG Maker as a possible vehicle?
I’d be happy to hear from you if you try this design challenge or if this idea brings up any other questions.
Alyssa Concha at the 2011 ARIS GGJ
With the ARIS Global Game Jam approaching, I’ve been thinking a fair amount about how I can be helpful for those participating. We’ve done a lot of jams over the years, and gotten a lot out of them. Lately, I’ve been hunting bugs, making tutorial videos, and updating documentation. As I get myself ready to jam, it also might be a good time to share a few hints and pro-tips with would-be AR game designers. The lists below have beginners in mind but also have tips for those with some AR design experiences under their belts. These ideas aren’t comprehensive, but are just a few of the things I have been thinking about regarding making cool things with ARIS. I’d be happy to hear back from readers what tips they have, which of these ended up being helpful or not, and what else they’d want to know along the way.
ARIS 2015 GGJ Poster – Burque Basecamp
Hints and Walkthrough for the ARIS Beginner
- Get the basic conceptual model down first: Objects, Triggers, and Scenes
- Make a simple 3 stop tour to solidify this understanding.
- Use locks to make that tour unfold as you take it.
- Actually try this out in person, not just by tapping the map (unless that’s the actual format you intend).
- Make something of your own. Something really small but that carries some interest for you. It does not and probably should not have some real purpose in mind. You don’t need all that pressure the first time you make something.
- Watch someone else try your tour or first game out; notice the things that are obvious to you but totally opaque for them.
- When it comes time to make something a bit more in-depth, steal liberally.
Some More ARIS Pro-Tips
- Every once in a while, the editor freezes. Simply reload the browser tab to fix.
- Have different tabs of the editor open at the same time in separate browser tabs. Really useful for adding in media and getting links while doing other work.
- Make a new conversation for each interaction with the player. If you layer all of the interactions into a single conversation, it is confusing when you come back to it later and want to see the flow.
- Allow for your player to acclimate to the UI of ARIS
- Plaques scroll, but not everyone notices this.
- Navigation of a map is something many people have to learn when they first play ARIS games.
- Map titles can be used for instructions to the player rather than literally identifying what’s at a location.
- There are many ways to hand out items, not just putting items on a map.
- Plaques hand out items really efficiently.
- So do conversation lines
- Plaques, conversations, items, these are all metaphors. You can bend or break them to make new things possible.
- The Decoder (A UI tab in the Client) is an alternate way to use QR codes, and can make creative use of the environment. A player finds and enters information instead of scanning an image. The author writes that information where the random number is above the QR code trigger in the Editor.
- Multiple Scenes and using Quests are not novice tasks in ARIS. They will break your game if you do not have a strong grasp of how Locks work.
- Once an 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.
- A teeny, tiny bit of html can greatly increase the presence and fluidity of media in your games. Of course this is useful for text formatting, but there’s more too. With just a bit of code you can have autoplay video and audio in plaques, conversation lines, and even the description of your game. The code below works for audio, but there are other options, and a very similar version works for video. More info here.
<audio autoplay loop>
General Design Tips
- You are creating an experience for your players. This is the end goal, not successful assimilation of content into an AR container.
- Make sure you are clear on the type of experience you are creating: tour, scavenger hunt, data collection activity, interactive story, simulation, etc. Reflect on genre conventions and hits in that format.
- Use the device and the players’ surroundings in a complementary fashion. If there’s a building in your game it is sort of pointless to show them a basic image of the outside of that building when they are looking at the building from the outside themselves in real world (TM) detail.
- If your game involves walking, be conscious that this takes time and effort. There is only so much walking that players will consent to, and a small jump on a screen takes time to cover in real life. As with imagery, the act of going from place to place should play a meaningful role in your design.
- Focus on the quality of experience, especially what the player sees within 1, 5, and 15 minutes, rather than on covering a certain amount of content.
- Give your player a role to play. “What is it that is exactly the same about every single vacation you have ever taken? You.”
- At a minimum, a story has a beginning, middle, and end. There are lots of ways to add or describe the structure of a story. Following some is better than a list of undifferentiated information.
- Look to produce a Minimum Viable Product, the teeniest part of your design that could be put in front of another human in working form. Get feedback on this before going down the rabbit hole.
- Consider using a design board to help guide and track your teamwork.