Pitching a Game At MDC

Today I am a professor at Miami Dade College in a new program called MAGIC (Miami Animation & Gaming International Complex). This spring will mark the first time our students will pitch capstone projects and I recently gave a lecture on creating game design documentation as part of their pitch. If a student had me for Intro to Game Development then this was all redundant and woefully truncated, but there were many students that needed this primer. For those that were unable to attend I’ve made my deck open to view online: tinyurl.com/mittnerworkshop

While this is certainly not the end all be all I think it is a good place to start if you are thinking about pitching a game. Check it out, I welcome feedback.

Another Blog

Until recently I was not allowed to post to my blog by a very strict contract with Shiver Entertainment. However that has all changed recently.

I am going to pick up writing here again, however I have been asked to write for another blog called I’m a Social Gamer. The content will primarily be about newly released or geolocked mobile games. You can checkout my first post about Smashland.

My Favorite iPad Game: Crimson Steam Pirates

I didn’t grow up playing D&D, and while I am familiar with all the concepts and a huge fan of RPGs I only recently got into it. My roommate Ross loves Paizo Pathfinder and I am now participating in two campaigns. One is being DMed by Ross every couple weeks at our place, and the other I am playing online with his friends using a site called Roll20. The online game is set in a semi steam punk universe where we are privateers (basically pirates). The problem is the interface for navigating ships in this game is just terrible as it is governed by the world interface that Roll20 provides. For example: you can’t turn 10 degrees to starboard in a turn, you have to turn increments of 45 degrees or nothing, and all areas within the attack envelope of your cannons are equally effective. Roll20 has a lot to offer but it sadly lacks in naval strategy. After last Thursday’s Game I decided to show Ross my favorite game on iPad so he could see what I would love to have available to us in our D&D game (not that this will ever happen). I meant for him to play it for a few minutes, he stole my iPad for three hours.


Crimson Steam Pirates (CSP) is set in a steam punk universe and is full of over the top characters, campy dialog and a fun story line which you can sink your teeth into or totally ignore as you will. There are no cut-scenes forced on you, and it’s always easy to figure out your objectives without having to read a lot. Still, it has a rich story and universe established so don’t think any of this description is meant as a put down. What I’m saying is that the game is a lot of fun, if story and characters are your thing they are there, if not then there is still a lot to love.

CSP is a turn based naval strategy game (though there are some dirigibles as well). As you may have guessed, one thing that makes the game so strong is the interface. Checkout this screen cap from my iPad:


The guest can see how far their ship will move along a path by dragging the ghost image around with their finger. By moving it further or closer to the ship’s current position the guest can adjust their momentum, one can use different abilities as well to accelerate the ship. When selecting the ship the guest can see the area of effectiveness of the attack envelopes, the range of the weapons and the effectiveness of overlapping envelopes. There are also a variety of abilities that can be selected each turn by touching the wheel. The best part is that these abilities are afforded by the crew members manning the ship. It adds a layer of complexity to the strategy. The guest has to think not only about what abilities they want aboard their ship, but how that crew will work together when they get into a boarding action, and how expendable certain crew members are.


For example: one can’t go loosing Tesla, he’s crucial, so they don’t put him aboard their weak little scout vessel, or maybe they do, with two engineers so they can constantly repair it and this gives them the ability to quickly strike all over the place with their Tesla gun. But, you wouldn’t want to run that vessel up along a large command ship and board her since the scout’s entire crew is going to have too weak a combat rating to let you take the other boat or win much treasure.


It’s awesome design and the levels are also well thought out and scale beautifully. As the game scales up it becomes quite challenging, so you are often getting a great sense of fiero (epic win satisfaction), there is certainly the fun you get from the story they put out there and the wonderful sense of adventure it creates, and (whether or not it’s true) it makes you feel like you are becoming an awesome strategist and sea captain. It’s not really a social game, but then I’m not a huge socializer (though I hang with my CSS crew and play some Civ with my friends, and hey I’m really getting into this D&D thin). I could go on for some time about this, but don’t take my word for it, check it out for yourself on the app store, the first third of the game is free, I’ll wager you buy the rest.

Moving Forward with Web

After paper prototype testing I’ve decided to move forward with Web (I’m going to come up with a better working title soon). Given the complexity of testing with paper prototypes it has become apparent to me that this is a game best suited for digital. This revelation isn’t really anything of the sort, but one must make sure about these things. The problem is the complexity of the web. If the player is encoding nodes with hidden pieces (see previous post) early game there has to be a way to reference these nodes. Numbering systems get super complex, and using a card with a check-box for every node makes it so the board cannot be dynamically generated with each game. However, making the game digital affords the power to not only create a more dynamic board generation system (which scales complexity and size based on the number of guests), but also allows for a simple interface where a node only offers a selection when it is scrolled over.

In fact the digital version will solve many problems including: game experience time for multiple players (by posting to a server players can play over days rather than sitting at a table for hours), the visualization of large amounts of units (you can see units represented by symbols with numbers at a macro level or as individuals when zoomed in), providing a history of play, and maintaining the integrity of the rules. I’m sure all sorts of problems will arise of course, but that  mean more things we can solve, it’s the nature of the beast and how we learn.

For the next iteration I want to experiment with simultaneous turns versus alternating turns, and orders of operations to unit actions. I’m also working on theming (we are talking about constructing the web with ropes, maybe theming the units as pirates, but also exploring other possibilities like a futuristic universe). I’m developing with my good friend and past co-worker Emmanuel Eytan, and we will be making the first version for mobile (iOS and possibly Android). I’ll let you know when we are ready for Alpha testing.

Teaching Video Game Design

I spent the last nine weeks teaching video game design for Galileo Learning. It’s a summer camp in the bay area; sort of like summer school in that there are classes and kids have a major they attend. Each week I taught a class of around 16 kids either an introduction to video game design and development or an advanced course where we built on what was learned in the first class.

Given that I had five days each week I had to focus on rapid prototyping. I taught the kids the basics of designing a game, how every game has some sort of a story, and tried to instill the important of visual and auditory elements when establishing a themes and styles. The hardest things to teach were scope and the importance of testing. Really, all I could do was get them to prioritize features, and develop until they ran out of time. Isn’t that what tends to happen in the professional world as well, at least to a certain extent? As for testing, they would usually test, but whether they would make changes was another matter. An eleven year old told by ten different people that his level is too hard will sometimes say defensively, “I like it this way.”

I broke my class up into strike teams of three to four, and after the tutorials on the use of the Multimedia Fusion 2, Gimp, and Audacity, plus all our talks about gamed design; they had about two days to develop their games. I often got generic platformers, with a bunch of enemies on paths set to the default speed, these launch objects at the player when they are in a zone and there were generally a number of pits where one could fall to one’s death. However this was not always the case. The most interesting games tried to push the boundaries of what they knew they could do with the program. They would try to learn new things while developing, or focus very heavily of elegant design and good art. Sometimes they were buggy, or just unfinished. But, it always impressed me what my kids could prototype in such a short time. I wanted to share a few of these here.


Gingerbread Runaway

Gingerbread Runaway is a really awesome game. One of the students on this team got sick after the first day and this ended up being created by a team of only two. However, Austin was one of the best collaborators I had in all my classes, the kids did some truly awesome original art, and they really tried to experiment with programming in MMF2.

Controls: Arrow Keys and Shift to Jump



Sewer Escape

The team that created Sewer Escape really seemed to understand scaling difficulty. The explanatory text is funny in a way that only kids can be.

Controls: Arrow Keys




Katfish is a fun little maze game that makes good use of balancing life and hazards. Kids often felt the need to make their games punishing, but this team understood that their game could be enjoyable if it was simply well designed and themed.

Controls: Arrow Keys



Monkey Runnner

Monkey Runner uses a cross hair to control where the player can launch bananas toward. They also created moving, crumbling, and tar platforms. This team was the first to use parallax. While there are some bugs in this game I am fond of it because it really pushed the limits.

Controls: WASD, Mouse to Aim, Left Click to throw Bananas, Space Bar to Jump



Cat Kingdom Wars

Cat Kingdom Wars is a tower defense game that never quite came entirely together. The first level is closest to the finished experience they intended. You can place towers by clicking the buttons and then drag them around with the mouse. The last level has waves of invading mice. The art was all original. To spite over-scoping heavily I have included the game here because it is again another example of a team going above and beyond in their efforts.



Food Fight

Food Fight is a game much like angry birds. Physics is hard to do in MMF2 and I was super proud of this team for even trying. They never quite got the obstacles to interact right but they created a basic game template that would have allowed them to make a bunch of new levels if they had had time.

Controls: Drag with the Mouse, Spacebar to Launch



Future Jump

It was awesome watching the Future Jump team come together. Originally they couldn’t agree on anything and the team was divided into two camps. However, after I explained both groups’ ideas were way over-scoped, and we had a talk about how ideas are much like disposable cups, they came together whole heartedly over a third idea. It’s not completely finished but the core experience is and they really understood the concept of explaining the underlying concept of a game in a short cut scene (even if theirs is extremely short).

Controls: Up arrow key to jump forward, Left and Right arrow keys to jump between walls.

New Interfaces in Radiology

I’ve said before that I consider myself a generalist. I don’t limit my design ideas to games. So, today I would like to talk about Radiology.

During my last semester at Carnegie Mellon I was fortunate enough to get my hands on a zSpace. I ended up attending zCon 2013 and seeing all the cool things people are doing with the zSpace technology. One company, echopixel, is using it to create an interface for viewing 3D representations of Radiological scans like CTs. This may surprise you, but this is an area I happen to know a great deal about.

Now don’t get me wrong, I like zSpace, and if you are reading this David (or anyone else from zSpace) please don’t take offense, but I’m not convinced it is the way to go with this technology. I’ve read the articles, like: Virtual Holography, The Next Step in Radiology Imaging?, and A tipping point for visualization-driven knowledge. I’m just not convinced this interface is going to be the right fit or provide the usability that doctors need for the industry. And neither are doctors I’ve talked to, it will take a lot of peer reviewed papers before this tech will get adopted. The papers aside, there are a few issues I see right off the bat:

  1. As far as I know zSpace is not an FDA approved monitor. FDA approved monitors cost a lot of money (like $10,000 a pop) and I don’t know how they will convert it over to that.
  2. Using that wand all the time is going to be a problem since doctors need to have that hand free to a certain extent to dictate cases while they are reading them.
  3. This is the big one. You can only wear those glasses for so long. I found that after about two hours of use I was done for the day. Your eyes get tired and it can cause headaches.

I propose another, perhaps cheaper and simpler way to use similar software technology the echopixel has created (which I do think is awesome), but with different less invasive and labor-intensive hardware. Couple a FDA approved monitor with a Soft Kinetic.

The soft kinetic is a really awesome machine like the Kinect and has the ability to do gesture recognition as well, if not better than, the Leap Motion. One could track the position of the head to create the 3D perception, and then use gestural control to manipulate the position of the 3D imaging being observed.

Don’t believe that good perceptual 3D can be achieved without stereo glasses or a 3D screen? Well, I know it can. But don’t take my word for it, you can start by looking at the work of Johnny Lee if you like. But I worked on a project with Brad Buchanan at Carnegie Mellon where we made this very technology work with a Kinect. That was before Kinect had near mode, and the Soft Kinetic has better technology on-board than the Kinect.

This is obviously just a concept, not a perfect solution yet, there are problems to be solved. A big one would be, how to make sure the head tracking stayed with the primary physician if someone else dropped by. But, it seems like a more user friendly solution to me. I envision a future where doctors lean back in front of their screens casually waving their hands at 3D representations of breast MRs, no glasses required.

Trimming Down the One Page Design Doc

I have been working on trying to cut down the design of Web. Obviously features will need to be cut, but as a first step I really wanted to see if I could streamline the overview design doc into something significantly more digestible. It is clear from the amount of text of the previous docs that this design is simply too complex, and while the obvious solution is to break it down to its component parts, there had to be some way, at the highest level, that I could summarize it more nicely. In doing this simplification I realized that this game really isn’t right for table top. It will probably make a good browser based board game (ironically), but there are five components which I left out of/solved with the new design summary which were cluttering up the original board or making things too complicated. However, some of these components are still in the game, they just don’t need to be addressed in the design doc as they become back end systems (or too specific for the overview).

  1. There is no longer a need for board pieces. The web is generated randomly. This also gives an opportunity to have way cooler theming more easily.
  2. There is no longer a need to have numbered nodes as players should just be able to select the location of the nodes they want to hide their special pieces on.
  3. Score cup and keeping score: this can all be managed by the program.
  4. Making it a video game solves the problem of piece clutter. With so many little pieces at different locations things can get cramped. But, with a video game a single icon with a multiplier on it can indicate the number of units of a type at a location.
  5. I removed negotiation. It was a nice idea but it would have made games way too long, and while negotiation might be fun in a table top environment it would be hard to implement and limited in a video game. I would like to return to the idea of negotiation as a main mechanic at a later date in another game.

I’m still not too happy with the amount of text I have for the hidden pieces but overall it is looking much better and more digestible. I don’t look at it anymore and think, ‘Man, that’s overwhelming.’ Now I can make supplemental docs that explain the finer points of play to go along with this general overview:


I will continue to do paper testing, work on the documentation, and see where this goes.

Initial Designs for Web

I was walking home with my roommate Ross a few days ago and he asked me, “If you were going to put a project on Kickstarter, what would you do?” My first thought was that I would get a team together and start making an RPG. I have some outlines, and  art for one I’ve been thinking about for several years now. But, then I thought, ‘Don’t be dense, start small.’ By the time we got home I had the beginnings of a board game in my head. I don’t know if this would be what I would put on Kickstarter, but it certainly is a good exercise for me right now.

I have been interested in a number of concepts that I think would make interesting elements in a strategy board game:

  1. A game with almost no random chance, but which had a fun way of randomly introducing an element one per game in the middle of play that could conceivably change the way the game was headed or being played (perhaps giving a player who was in a weak position an opportunity to get back to a position of strength).
  2. Dynamic terrain that gives opportunities to play with a variety of styles and still achieve victory. Maybe a player uses large formations of units, maybe small groups they spread out like a net. However played if they are creative and cunning there is an opportunity for a player to succeed.
  3. I really like the idea of hidden pieces that players can reveal at any time.
  4. Finally, I wanted to explore the possibilities for negotiations in game and wanted to keep it as open ended as possible.

I started in on designing this game, which I have given the working title of Web, by deciding to try to do one page design docs. Because Ross works at Maxis and socializes with that group I have had some recent opportunities to meet and speak with Stone Librande. After being impressed by a board game we played at a party and some documentation I saw from Sim City, I started familiarizing myself with his work on one page design docs. I also attended his GDC talk, where he talked about many of the lessons he learned from trying to design a game with all the complexities of Sim City using one page design docs throughout the process. I have been really impressed with this process and have been trying to work this way with my recent design projects. Getting things onto one page and presenting them in an aesthetically pleasing way forces you to organize your ideas well. You get a real clear indication that your documentation might be too dense by just looking at the layout of your doc. I have found myself doing way more iterations of my one page docs than I have ever done on a written doc. And, to be honest I’m still not happy with them. But either I need to start using a bigger page (right now I’m using 8.5 x 11), or (more likely) I have a long way to go. I feel I’m getting better but I am nowhere near where I want to be yet. It is clear that this is a skill that takes time to cultivate and Stone has said this numerous times. I am posting my docs for Web (which might be better named Net, but I really need to find something that doesn’t actually remind me of the internet) below and you can click on the images to see them enlarged. I think though that I will be breaking at least two of these down even further and trying to make better use of the negative space across all of them. But, this is the first draft of the Web documentation (no theming yet really). Feedback is welcome:

Edit: There is too much text, the text has too go which means this system is too complex for the medium, which is obvious just from initial paper playtesting, and from the fact the text exists.





I have built a board and ordered pieces. Once I get a chance to playtest I’ll post some results and we’ll see how the game changes. Right now, untested, I’m thinking I will have to choose 2 of my core design goals to focus on and cut the rest, but we’ll see how it goes.

As an added bonus for getting this far in the post I am linking you directly to Stone’s printable Garbage Flow Stickers. I think it would make him happy to know people were out there sticking them in random places, it would sure make me happy.



Identifying Player Types using Dead Space 3

I have been working on a research project at EA this semester. The goal of this project has been to see if we can predict what types of games people will like based on their in-game behavior. Yes, the goal was that general. As the designer on the project it was pretty much up to me to come up with a plan of action as to how we might accomplish this. I thought a lot about the way people play together, and looked into everything from the work of Chris Bell to this huge Gamasutra article on player types. I’m not going to go into player types too much as you can read the article, which reviews them extensively, if you are super interested. However, what I am going to touch on is our process, the models we choose, and how we have been using them thus far.

Many people may be familiar with Bartle types. These were originally adapted for analyzing players of MUDs, but have since been adapted for multiple uses. GamerDNA.com uses a pretty good Bartle Test to analyze what type of player you are based on your behavior in MMORPGS. But, basically Bartle breaks down players into four categories (sometimes eight, but for our most commonly and for our purposes four): Killers, Achievers, Socializers, and Explorers. But, Bartle doesn’t apply to everything and we needed something a little more complex.

If you know Richard Bartle, you may also be familiar with Nicole Lazzaro. She breaks players down by why they play. Again, she puts players into four categories by the type of fun they are pursuing: Serious, Hard (Fiero), People, and Easy.

These two models of types correlate with each other very well. For example, an achiever who prefers to pursue leveling, achievements, equipment, and customization; these players are are drawn to fiero. I mean by this statement that they gain pleasure from overcoming difficult situations, like puzzles, acting on difficult problem in the world (whether these are combat challenges or perhaps building challenges) and will gain a sense of satisfaction from the achievements of a mentee or partner in game. Below is a map of how these groups correlate.

So we have developed a structured way of observing players. First, we created a Dead Space 3 level which serves as a microcosm for the whole game. What do I mean by that? Well, we only have about an hour with each player to see if we can predict their player type, and see if our prediction about their player type will accurately allow us to predict whether they will like another game. In this case we are trying to predict if they will like Army of Two: The 40th Day. So we get 40 minutes with Dead Space and 15 minutes with Army of Two. In order to observe as much as possible in 40 minutes we needed to have a lot of the normal game’s possible activities shoved into a shorter experience. For example, we needed to have more opportunities for customization, exploration, frustrating combat, and puzzles. This way, we could see what a player would do quickly. We are trying to automate this process, so in the future a system will have the whole game over which to collect data, but again, we only have 40 minutes.

At the end of the test, after we have made our prediction about what their type is, and whether they will like Army of Two, we give them a Bartle test to get a boolean on whether we are hitting close to the mark with our predictions. We also ask them some questions, amongst these is whether they like Army of Two or not.

First off, we have determined there are a few things we thought would be good predictors that aren’t. For example: time spent in EVA (floating around in outer space) is not a good determiner of whether someone is an Explorer since some people can’t orient themselves well in a zero-g environment. Also, the way people play is highly influenced by player types they are with. Explorers tend to have a negative experience when playing with Killers, as Killers will try to drive the experience quickly through a level. Socializers on the other hand will go with the flow and can interact well with either of those types (usually, we did have a gross exception).

On the whole we have found that our process gives us good results. We can predict a player’s type over 65% of the time so that it correlates with the first Bartel type returned on a Bartle test administered at the end of the testing session. Also, we had hypothesized that Achiever and Socializer player types would like Army of Two the most and this has proven to be true for the most part. We can predict whether a player will like Army of two with about 68% accuracy going by this hard and fast rule. Socializers almost always like Army of Two once they play it, because they are attracted to the co-op aspects, and especially like the camaraderie system. Achievers on the other hand like Army of Two only about half of the time. This may be because they sometimes do not have enough time to get into the customization systems available to them, and don’t play enough to experience any fiero. Trust me, having played the game, there are definitely opportunities to experience fiero. However, our predictions about who will not like the game are spot on. We have only had one explorer who liked the game at all, and they said, “It was okay, I might play it if my friend had it.” Our killers like it less than 20% of the time, this is probably because they can’t complete the game all by themselves or force the experience to move forward without their partner.

We have a lot more testing to do, and it remains to be seen whether we can get our automated system working to make these predictions. But, if nothing else results from this project, I am happy that we came up with a way to predict this much. I feel that the way we predict player types in Dead Space 3 can easily be transferred to a wide variety of games from platformers to open world RPGs.

More to come as we wrap up this project.

Update Post Project May 2013:

I just wanted to say that we were able to reassess our criteria (looking for Socializers, Achiever Socializers, and Killer Socializers specifically) for predicting who would like certain games, specifically Army of Two based on the results of our testing. We found that we can now predict with 75% accuracy whether or not a player will like AO2 based on how they played a 40 minute session of our DS3 testing level. Most of the numbers I have given in this blog are rounded off, that one is not. Amazingly when we crunched the numbers it actually came out to a flat 75% (where as before our accuracy rate was actually 68.4% ). I will link our postmortem documentation when I get back to San Francisco.


Nature Quest: A Postmortem

Prior to working on my current project at EA I did a project for Oglebay’s Shrader Environmental Education Center in Wheeling West Virginia. We called this project SEECQUEL, because it was the second project done by a CMU team for Oglebay (the first project having been called SEEC). SEECQUEL was a location based entertainment project which challenged us to teach kids about Nature in the environment while using technology. It might sound simple, but getting kids to put the focus on Nature while out bumming around with a piece of interesting tech is difficult. Turn that around and upside down too: asking kids to use a piece of tech that is boring and bland, to learn something, while they could be playing in the mud is equally difficult. We had to find that nice middle ground where kids were engaged by our experience without being “taken out” of nature by it. We did this by providing the children an augmented reality device which scaled back to a tool as they progressed through the experience. At the beginning kids could use an Android tablet to “see like a bug” but by the end the tablet was being used to get kids to answer questions or take a picture. It worked out really well, and while I could go in to all the specifics of the design decisions that resulted in our success on this front I’m not going to. I’d rather talk about a few of our serious problems (because let’s face it that is where we learned the most) and how we addressed them.

What follows are some important lessons learned that I think anyone designing for kids can learn from. Some may seem obvious, and maybe I should have realized these things right off.

Lesson 1: Children will naturally help each other (well, sometimes girls won’t).

We had this activity where we were trying to teach kids how to determine whether a tree in the forest was older than the ones around it. To do this a child had to hold up the tablet and point it at the tree, and then touch the screen in several places. If done alone, this meant holding a tablet steady one handed while doing the main part of the activity, a difficult task for anyone let alone a 8 to 12 year old. The experience was designed primarily for groups of 4 to 6 kids from schools visiting the Schrader Center, and we wanted to give the children instructions to have their peers help them hold up the tablet. However, we were already having trouble delivering instructions to the kids that they would consistently pay attention to (more on that later), so the less instructions we had to give the better. We had a number of ideas on how to solve this problem but were not able to implement any of them before our first mechanics playtest. In retrospect we saved ourselves some time by not prioritizing this UI change higher. It turned out that our testers saw the problem and immediately started helping each other with this activity. Partly because the one holding the tablet would say it was a little hard, and partly because all the children wanted to be involved and in this case it mean being close to the shiny object. With these positive results from our first playtest we patted ourselves on the back for being such geniuses and not over designing.

Of course it couldn’t last; toward the end of the project as everything was nice and refined we tested with a number of groups of kids towards the older end of our age range made up of exclusively girls. I bet you can guess what happened. That’s right, they didn’t even consider helping each other and this was almost completely consistent across all the groups. I talked to the teachers of some of these girls and they told me that this behavior stemmed from a fear of doing something wrong. I won’t pretend to understand child psychology at that level; however we had already instituted a “try again” button. We did this because we had learned that, even with the help of peers, kids of course didn’t perform the task correctly 100% of the time. Sometimes kids even trolled each other, imagine that. So, it was a simple matter to add a suggestion, after they had tried a couple times, that they might collaborate. This got some of the girls to collaborate, and some groups just ignored it. So, there is another lesson there, you can’t get everyone.

Lesson 2: Kids do pay attention, to themselves.

We had this virtual avatar named A.B. Brooks who guided the whole experience. He was based on this early naturalist who helped to found Oglebay. He tells the kids at the beginning that he will be taking them on a quest and teaching them to be “Junior Naturalists” through the completion of a number of tasks. We originally had planned to not only have him give lessons at each activity location but also provide all instructions. We quickly learned that if we wanted the kids to actually know what they were supposed to do at the activity locations that we could not do this. At first we thought it was Brooks’ voice. We thought maybe that his deep tones (which we had to pitch up a bit just to play better out of the tablet speakers) were not grabbing their attention well. Or, maybe they couldn’t hear him. But, neither of these things were the case. The kids seemed to like him, said they liked him in the testing surveys, and would listen to him every time he started talking, so they would get part of the general lesson they were supposed to learn at each location. However, I say “part of the general lesson” because our lessons were too long by far at that point. The problem was that the younger the child was the shorter the amount of time they would spend focused on Brooks each time he started speaking. It’s like Saturday morning cartoons. As an adult if you ever watch children’s cartoons for our target age range you might think they are super spastic, but the truth is that makers of cartoons have really figured out how to peg a kid’s average attention span and fit as much action into scenes that fit that amount of time. Even the commercials are shorter. Some people might say that kids’ attention spans are conditioned by cartoons and other media to be like this. Maybe that is the case, but we were working with children who HAD to play outside and had strict rules about watching cartoons. Wheeling is supposed to be one of the best places in the US to raise active children. So, maybe not, all I know is the behavior was consistent. We found that if we kept whatever Brooks said to 30 seconds or less then all the children would pay attention. Anything longer was pushing it, but sometimes we had to, however we never exceeded 45 seconds. Do you have any idea how hard it is to teach about the Mohs Hardness Scale in less than 45 seconds?

Well, maybe we could teach children something significant about tree leaves or rock hardness in 30 seconds but we certainly couldn’t do that and give them instructions on how to use the tablet in different ways at each location. Since at each podium the kids visited the use of the tablet changed and they needed an introduction to how the tablet would be used there we had to figure out how to solve this problem. We struggled WAY too long with this when the solution was so elegant and simple when it finally occurred to me I tried to kick myself in my own butt. From the very beginning we had the kids read the instructions to each other. When they got to a new location they were told to pass the tablet to a certain child (identified by a totem animal we assigned them at the beginning of the game, that thankfully was something we got right from the get go), and this child would be asked to read out loud to the others. It was perfect, it helped build teams, kids would pay attention to each other as they saw it as a duty each had to take on, and if someone wasn’t a particularly good reader others would help them.

Lesson 3: Theming can get you into trouble. But, without the theming things would be less interesting.

I wanted to theme nature quest in two ways both of which caused some problems for us. First off I wanted Nature Quest to play much like a MMORPG Quest chain you might do with a group. I wanted it to have a lot of game like elements: an achievement system, an interactive map, a quest finder arrow in the HUD, and side quests. This made it way too scopey, partly it was just too many elements to put into the experience in the time allotted for development. But, on top of this, it was not elegant enough. Location based entertainment isn’t like a video game. People aren’t totally immersing themselves in a virtual world; we didn’t have a tutorial period at the beginning we can run them through to teach them the ins and outs of how to “be” in our experience. Giving them a complex HUD would have just given them something to focus a lot of energy and attention on, and worked counter to our goal of getting them involved with nature. No one cares about virtual achievements they never see again. Side quests were just a way to split up the team, some children would be interested and others wouldn’t  And what happens when a side quest wants them to take pictures of flora and fauna, and they simply couldn’t because these things happened to not be around at the time? The point of the experience was to make kids feel like they were learning and succeeding every step of the way, failing a side quest would just discourage them. So we cut it down to the essentials, it was still a quest, they were still on a journey, and there were still some perceived stakes. They even got a singular achievement at the end (a Junior Naturalist Badge) that they could take away. But, every task was repeatable so even if there was a knowledge test they could succeed provided they were willing to learn and keep trying. It worked out much better, and the most satisfying moment for me was when one of the children of an employee at the center told me, “ I’ve been down these trails millions of times! But, I never noticed these rocks, you know, because I wasn’t thinking about it like I am now.” It meant we had done our job and he had become more involved with the environment as a result.

The other theming I wanted was to have a consistent aesthetic to the whole experience. I wanted everything to look like it came from within the life time of A.B. Brooks. I wanted the podium signs to look like they came out of a naturalist’s notebook with drawings of plants and animals rather than photos. I wanted the UI to use icons that were period specific and all the text to be on parchment that looked like it might have been torn from a naturalist’s notebook. Overall this worked out really well, and a lot of credit has to go to Daniel Aum for just being an amazing person to work with and making that vision come together with his illustrations. However, we had one issue which turned out to be a bit of a problem. When adults think of a camera we still remember single-lens reflex cameras as being the only thing around. So an old plate camera which has very much the same look to the lens in front doesn’t throw us for a loop. However, when the modern child thinks of a camera they think of an iphone. We had three buttons you could use almost all the time in our interface: a magnifying glass for zooming in on things, a map for bringing up the map of the trail, and a plate camera to activate the on-board camera. Sadly, only about a third of kids were able to identify it as a camera when prompted to use the camera during certain activities. Even when told outright by Brooks that it was a camera they didn’t seem to process this information. We ended up having to put each button against a notebook background and labels under each before the children would process that it was indeed a camera. We could have removed the images but that looked too bland. Or, we could have used a more modern looking image, but that would have broken with the theming. So we settled for this and I think it was the least elegant part of the whole interface. But, it worked in the end so I guess I shouldn’t knock it.

I could talk about other things we messed up and fixed along the way. Like using Unity at all, and hitting the uncanny valley too hard early on with our avatar. But, this is already might be the longest blog I have ever written so I will refrain. If you want to know more you can always ask questions in the comments. I would like to take a moment to thank one of the best teams I have ever worked with: Garret Kimball, Daniel Aum, Prateek Gudihal, and Emmanuel Eytan.