Deathtrap Design and the Invisible Gorilla

It was a viral video going around for a while — the Invisible Gorilla experiment. (If you never saw it, you can watch it here… the rest of this blog-post is a spoiler!) (Although to be fair, just saying the words “invisible gorilla” is a spoiler already… oh well.)

This experiment from 1999 was quite astonishing. Framed as a test, the video asks you to count the number of times some kids pass a basketball back and forth. Partway through, a person wearing a gorilla suit saunters into the video, mugs right in front of the camera, plain as day, and leaves. In the experiment, fully half the people who watched this video did not notice the gorilla. They were too busy counting basketball passes.

None of those people would believe they could miss a friggin’ gorilla. When the gorilla was pointed out to these people, some insisted that the experimenters had switched the tape! They pretty much universally said “of course I would see a gorilla.” But yet, half of them were wrong. The new book by one of the authors of this experiment is engaging and worth a read.

If you didn’t see the gorilla in that video, you aren’t stupid. Even after many experiments, the researchers couldn’t find any way to predict the people who would notice the gorilla (or whatever other random thing they added, in any context). Regardless of the experiment or the person, some people notice the external details sometimes, and sometimes they don’t. But people always think they will notice all major details. Worse, when they see somebody not noticing an important detail, they assume those other people are idiots… even though it’s just dumb luck that they noticed it themselves.

EDIT (bonus paragraph): the first thing commenters say is “well, but the gorilla blends in!” That was the first thing the psychologists assumed, too. I’ll give you that they are psychologists, but in this particular case that doesn’t mean they’re completely stupid. They tried numerous additional experiments, including, for instance, one where you are supposed to count the number of small black digits floating by in a big white empty screen. Then a gigantic red letter E flies by. Half the people still missed the giant letter. It doesn’t matter what the context is, and it’s not about something blending into the noise. Even incredibly distracting interruptions will still get tuned out. That’s why this is an interesting phenomenon.

We have a highly-ingrained belief that we notice everything around us, but the truth is that we have very selective attention. When we’re focused on something else, we often miss very obvious things in our surroundings. But we believe only idiots would do that.

This is the crux of the book, although it unfolds into a lot of other interesting experiments and diversions. The authors are concerned with how this affects our court system, among other things. I am more concerned with how it affects the games we make.

Instant Death

It’s an MMO designer classic: stick some giant horrific monster into an area to keep players on their toes.  If the players refuse to run away from said monster, they get killed. But they always have plenty of warning. “The earth shakes when the giant walks,” says the designer — “they can’t help but notice that! So it’s not unfair. It’s just something to keep them on their toes.” Or how about the old “random firetraps in the middle of a raid dungeon” trick? Spices things up without being unfair, right?

Unfortunately, half the time these sorts of encounters end in unavoidable death. The players are deeply engaged in playing the game — watching the little bars tick down and using the right skills at the right time — and half the time, they miss your deathtrap cues, no matter how obvious you think they are. When they die, they are understandably upset.

The really frustrating part is that other players think they’re morons. Hell, the players themselves often come to think they’re morons. “How did I manage to get ganked by an elite cavalry unit when you can hear the horse steps a mile away?!” The general conclusion seems to be that the average MMO player is really stupid. Right?

"You Automatically Lose" Community Chest Card

Caption: Unpredictable instant death is not a fun game mechanic.

But in actuality, designers are being just as misguided as the players. Most designers would agree that it isn’t fun to die instantly without any warning. But yet half the time, these “easily avoidable” deathtraps go unnoticed. There’s nothing the players could do to pay more attention. It’s not possible to focus on the gameplay and also notice 100% of the other stuff going on all the time.

The result is that half of those kills are insta-kills without any warning. They are the antithesis of fun. Worse, other players often make fun of them for something they couldn’t avoid. What a stupid thing to include in an MMO!

To HUD or Not To HUD

A related study referenced in the book looked at pilots being trained to use new HUD systems. The pilots would get so transfixed managing the HUD data that they would miss things going on out the window — things happening literally underneath the translucent HUD, or just an inch away from it. It’s not about visually missing something, it’s about our brain completely filtering things out as noise.

We’ve all played games where the GUI was more important than everything else going on. Hell, I still have no idea what the 3D characters do in Rock Band — I can never take my eyes off the fretboard GUI long enough to notice anything.

Among designers who have learned about this psychological phenomenon, there is a tendency to try to integrate the gameplay right into the world. (I have often been in this camp, with mixed success.) For instance, in Red Dead Redemption there is no health meter. The screen just gets redder and redder as you are about to die. I find that this does make it easier me to focus on the world around me instead of constantly glancing at that damned health bar… but on the other hand, I am often surprised when I suddenly keel over dead. (I can hear you thinking “But the screen turned bright red! How could you not notice that! Oh… wait, right.” Just because it’s impossible to miss doesn’t mean we won’t miss it anyway, half the damned time. HALF THE TIME!)

How Do We Fix It

The authors of The Invisible Gorilla want to make you aware of the fact that your attention is extremely selective — that you are missing crazy things happening around you all the time. That is a great thing to teach people, but that’s not the role of video games.

Most video games (including the ones I like to make) are escapism, much like books or TV. Here, we want you to feel good about yourself. We don’t want to teach you that your brain can miss important things going on around you — instead, we want to hide this flaw in the human brain. When you’re playing a video game, you shouldn’t be surprised about unfortunate outcomes. You shouldn’t go “How did I die?!” or “Where did that level-80 elite mob come from!?” Those questions indicate that the player is feeling abused. Moreover, they aren’t learning anything, either (except, perhaps, not to play your game): it is not possible to “learn to pay more attention”.

The only band-aid fix is not to have nasty traps like that in your game. That isn’t really a deep “fix”, though, because the problem happens with rewards, too – I mean, you are probably running past tons of ore mines, rare monsters, spontaneous treasure chests, and who knows what else, without ever noticing them. On the one hand, that stuff didn’t kill you, so it doesn’t hurt you. On the other hand, designers didn’t factor in that you would miss half the stuff they stuck in, so the game may feel more sparse and empty than they expect… because if you’re focusing on combat, you are literally missing half of the cool stuff around you.

More Research

Until reading this book, I didn’t realize that psychologists have done quite so much research on selective attention. The book is obviously not too concerned with video game design, but I’m hopeful that there are experiments by human-computer interaction psychologists that may help us understand how to work with this issue when designing games. If I find some, I’ll post about them. (And if you have leads, please share them!)

Indie Games, Prototyping, and Fun Finding

Our indie MMORPG development continues! Together, Sandra and I are able to put about 20 hours a week toward the game, which isn’t much, but makes continuous progress. It’s coming along well, and it’s been very exciting to get past the nuts and bolts and start prototyping gameplay.

I’ve been avoiding talking about it because, well, it’s a little indie project and I normally like to talk about much bigger games. But this experience just has too many interesting bloggable topics — as well as funny moments during prototyping — that I can’t help but talk about some of them!

First of all, the biggest early risk in an indie MMO is having the wrong mindset.

Prototyping and Guerilla Development

When you’re just a couple of people trying to make a big game, every day of development time is precious. You have to choose what to focus on: graphics, technology, or gameplay. But that’s a trick question. You should choose “gameplay” because that’s the only one a small team can compete on. You need to spend most of your effort on making a fun game, and just the barest possible amount of time on the underlying technology. Making an indie MMO means cutting corners — cutting every corner you possibly can — to save time and cost.

Repeat after me: nobody cares how cool my server tech is. Say it! If you don’t believe that mantra, then there’s no sense trying to make an indie MMO. You will get stuck in technology limbo like everybody else does.

I mentioned earlier that we’re using SmartFoxServer as the base of our server, and several people have asked us why. For instance, in a recent blog comment, ‘Jason’ said:

I’ve done commercial work with SFS. I’d say it’s just as I described it as well. if you want to chat, it’s probably fine for that. But it really is junk for anything more.

Everything it does can be replicated by a good server side Java programmer in a couple of weeks and not suck.

Jason is right: there is no magical goodness inside SFS; it’s kind of clunky and mucky inside, and all it really has is a fast messaging-relay system written in Java. But let’s assume Jason’s estimate is right: one engineer needs two weeks to replace it. Eighty hours! TEN FULL DAYS of development time, just to replace a cheap off-the-shelf component! This sort of comment reflects the dangerous technology-limbo scenario I’m talking about (no offense, Jason). It reveals an all-too-common tech-centric mindset that is not going to help you ship a game.

One of the best engineers I know started working on his own MMO when he was out of work. But all he ended up with was some cool streaming technology, because that was the part that was interesting to him. And I too have fallen into this trap myself on several previous attempts — our home SVN repository is littered with the husks of MMO’s that will never be, each with one kick-ass technological feature, and nothing else.

We’ve found that the best mindset to have is very similar to the mindset you would have if you were making a commercial MMO prototype (that would later get rewritten into a full commercial release): focus on making sure the game is fun first. Fun is the most important thing. Only then do you even consider how the technology should be tuned.

Of course, the difference between a commercial prototype and an indie MMO is that when the prototype is done, a team of 12+ engineers rewrites everything from scratch to get the highest performance and the best-looking graphics possible. For an indie MMO, the prototype is the game. You refine the prototype, caulk up the seams as best you can, maybe strap some more motors on here and there, and ship it!

So this is a very tricky balancing act. It means being agile as hell, and it means that 90% of the time you skip worrying about the technological details until you’re sure you need them… but at the same time, you don’t have the luxury of rewriting it from scratch later, so in a few places, you really do need to plan your tech ahead of time to make sure your game can float. No amount of caulk and spit can save an MMO engine that is intrinsically tied to failed underlying components.

Unfortunately, the best advice I can give you is “work on a commercial MMO or two, and then you will know where you can cut corners and where you can’t.” I don’t have a list or corners not to cut (though maybe I will try to make one now that the thought has crossed my mind). For instance, you need to insulate yourself from your serialization solution, and you need to isolate your game code from your networking code. But don’t go overboard! When I tell people to insulate their networking, they inevitably reply with, “Oh I totally did that, check out this wicked six-layer class hierarchy that perfectly encapsulates…” no. Wrong, bad. You need to isolate it JUST ENOUGH that you will be able to replace the subcomponents later. Spend a few hours, then move on. You don’t want to PERFECTLY wrapper anything because that wastes time. You don’t even know what’s going to be important yet!

So making an indie MMO is like prototyping a game, yet mysteriously knowing just how to code your prototype so that it can later be made to work under live loads. I… I need to figure out how to define this better in future blog posts, don’t I?

Of course it’s inevitably going fail in some ways, and you’re going to have to scramble to fix things, painfully. But the alternative is having clean tech but no game. That is what most people end up with.

But you know what? It is incredibly tempting to rewrite SmartFoxServer from scratch. I could do it so much better! But I’m not falling for that trap again. We may very well need to replace it, possibly with ElectroServer or some other similar product, or possibly with a home-brew solution. But that will not happen until we have a fun game prototyped, so that we know precisely WHY we’re replacing it and what the goals are. First, we have to make it fun.

See If It’s Fun First, Stupid!

I just have to keep reminding myself: don’t code infrastructure until you know the basic premise is fun. That seems like common sense, but it’s very hard to do! For instance, when we implemented combat, what’s the first thing I added? I implemented WoW-like combat statistics and all the things that go with it, like armor ratings and stat buffs and so on, because of course that’s where combat starts. Dumb, dumb, dumb!

Only then did we start exploring exactly how combat should work for the game we want to make. The first thing we threw out was WoW-style armor ratings. It’s boring. So all that code went out the door.

Admittedly that’s not a lot of code in this case… but if it was, would we have been willing to throw it all away in the name of fun? I’m not sure. That’s the other danger of writing code that isn’t fun: you get attached to it. You don’t want to throw away hard work!

So try not to write infrastructure until you’re sure you need it. Not always possible, but something to strive for.

Follow The Fun

What's that icon mean? Oh he's vulnerable to fire! Better use the fireball power.

Of course it’s not as simple as “sit down and code something fun”: you need to know who your target audience is and what each game system is trying to achieve. (This is extra important for an indie game!)

I’ll go into our target-audience analysis some other time, but we used that information to decide how combat should be: mostly soloing, no PvP, and as engaging as possible. While combat shouldn’t be necessarily HARD, fighting monsters should require a bit of thinking and reacting; there shouldn’t be a perfect order of abilities that works the same for every fight. So we’re exploring ways to achieve this.

But we want the goals to be a guide, not a straight jacket. Follow the fun — if you accidentally stumble upon something interesting, explore it and see where it takes you.

For example, right now monsters have “spontaneous vulnerabilities.” When an icon suddenly starts flashing over a monster’s head, that means he’s vulnerable to some type of attack. Better use that attack type quickly to kill him fast! This has proven to be a fun mechanic because it keeps you on your toes. So far so good — a basic mechanic that meets our goals.

I discovered this skeleton's weakness! It's... oh... that's not too useful. Also, TMI, skeleton dude. But that is kinda funny... Let's explore this idea...

I wanted to expand on this mechanic, so I added an ability you can use to make a monster become vulnerable immediately, so you can take advantage of it when you want to. That was interesting, but not quite right: it needed to only work sometimes. But having it “miss” is boring. (Missing is always boring, unless you’re the one doing the dodging!)

So now the skill always finds a vulnerability… but sometimes that vulnerability isn’t something you can use in combat. I rebranded the ability as “Psychoanalyze”, and now monsters have phobias and quirks that you might discover. For instance, sometimes a monster is afraid of spiders, or heights, or success. I just tried it out on a whim, and it was fun and funny. Now I’m exploring how an entire Combat Psychology subsystem might work.

Will any of this be in the final game? I don’t know yet. But I suspect some element of it will, because even after many hours of play I still laugh when I fight a giant wasp whose only weakness is a crippling fear of success. Tuned just right, this might be the sort of offbeat, indie, niche fun we’re looking for. (And “Psychology” wouldn’t be too out of place, given our other prototype skills like Mycology, Acupuncture, and Chutzpah. This is going to be an unusual game, I think.)

I don’t want to make it sound like we just sit down and go “let’s code stuff and see if it’s fun!” Our goals for the combat aspect of our game constantly inform our decisions to either explore or abandon an idea… but we still poke in corners to see what we find.

I guess the summary of this blog post is: making an indie MMO is crazily hard, so remember to cut every corner you can, focus on making fun gameplay, and try not to implement things you don’t end up needing.

“No-Reply” is the same as “No-Respect”

Ever had to deal with an asshole customer? Ugh! They can really ruin your day. I’ve had to deal with my fair share, so I should know better than to be one myself. But I was just an asshole customer.

Normally I am pretty darn polite, but it turns out there’s an easy formula to turn polite people into assholes. The formula is easy:

  • customer has problem with your game or product
  • customer submits a ticket
  • customer receives a useless, generic email reply
  • customer emails back more information
  • customer waits impatiently for days
  • customer gets an automated email saying “We didn’t hear back from you, so I guess the case is closed, buh-bye”
  • customer gets irate

My email reply was thrown away (not even bounced back to me) because it was sent to a “noreply@company.com” email address. The email didn’t specifically tell me not to reply via email… apparently I was just supposed to scrutinize the email address before sending a reply. I’m used to modern ticketing systems that let you reply via email, so I didn’t think twice about it. But their ticket system, like far too many, was designed for a previous era.

Back in 2002, ticketing systems were pretty cool. They were like magic! You enter a ticket on the website, and then it gets copied to your email so you know when it’s updated! WOW!

It’s not 2002 anymore. Ticketing systems are not cool, and logging into a website to send a follow-up response is really annoying. I often check my email on my phone, where logging into games or websites is difficult or impossible. Fortunately, the phone’s email program has this neat “Reply” button. So I should be able to use it.

Not Just For Stupid Morons

“But Eric, you’re just a stupid moron!” I hear you say. “Everybody knows you can’t reply to automated emails!” Wrong! But your misconception is quite common.

The FlashGameLicense.com website sends tons of automated emails. Sometimes, we expect a reply from the developer, and we got to wondering how often people were replying to our “no-reply” email address. So we created an actual email account for it, and that account suddenly started getting tons of replies. A large percentage of our HIGHLY-technically-skilled user base replied to our no-reply email address. The emails said not to do that, but they did it anyway. It’s almost as if they’re stupid morons… orrrrr…. mayyyyyybeeeee they don’t have time to read every detail of the email, so they gloss over the pedantic instructions, and use the big shiny Reply button in their email app to dash off a response.

So we made that Reply button work. It wasn’t hard. Now automated emails that expect a reply can get a reply from email. It’s automatically associated with the right ticket and everything. How hard was it? Including the time needed to make sure it was relatively secure, the whole implementation took maybe 16 hours of development time.

When I Make Email Mistakes, I Get Angry… At YOU

The thing is, I do feel stupid after making a mistake like this. Of course I should have read the fine print on your antique, sub-standard ticketing system. But I didn’t, and it cost me time and possibly money. I feel stupid.

But guess what? I don’t respond by apologizing. No no no. I’m taking it out on you. You let me stew in my annoyance for days, and then told me that it was my fault you weren’t talking to me due to a technical hurdle I didn’t notice. My annoyance doesn’t go down. It goes up. That makes me feel bad, and makes your customer service staff feel bad when I yell at them, and nobody wins. Now it’s that much harder to have a happy customer.

Don’t let the customer get irate if you can help it. And you can help it here.