GDC 2012

I have returned from GDC in San Francisco. As always it was a stimulating, busy week. I linked up with Alex and we spent a lot of time meeting with people, discussing the future of Realm of the Mad God.

Realm was nominated for an IGF award in technical excellence. We didn't win, but we did get to sit up front at the awards ceremony. We shared a table with the QWOP team. Blackberry gave out a free Playbook to every nominee. I wonder what I'll do with it.


A big factor in my willingness to play a game is how easy it is to quit. Not permanently -- I'll play more later. But NOW. I'm not a kid anymore, and real life is important. People rely on me. Phones ring, babies cry, and when I need to quit I don't want to ask permission from the game. I want to click one button -- the X at the top right corner of the window -- and walk away.

For some reason, just about every MMO in history has decided to penalize people that need to quit quickly. If you don't log out in town, the game assumes you are trying to get away with something. Your toon stays active in the world for a minute or so, vulnerable to any passing monster or PKer. Leaving in the middle of a fight is hardest of all -- some games actually make it impossible to quit in combat. In my head I can picture the design meeting that led to this.

That'll show those cheating noobs who try to leave the game when they're losing a fight! They should have planned more carefully and not gotten into hot water like that! Die noobs!

But even if you're not fighting, you're still penalized for quick-quitting because if you don't leave at an inn, you don't accumulate rest state for the next play session.

In Realm of the Mad God, players can quit any time just by closing their browser. Or they can escape to the safety of the Nexus with just a keypress. Combined with the game's tiny load time and instant grouping features, the result is something that hasn't really been seen before: an MMO that works well even for tiny play sessions of less than a minute. People play RotMG while waiting for other games to load up.

I love the idea of an MMO that supports short bites of gaming, anytime, and quick quitting will definitely be a feature of Jetbolt's new MMO.

Separated from my friends

I really hate it when I try to play an MMO with my friends, but the game won't let me:

  • We are on different servers
  • We are on different factions
  • We are too far apart in level
  • We are not at the same places on our quest chains
  • It takes too long to walk or fly across the world to find each other
  • One of us doesn't have good enough gear
  • One of us doesn't have enough reputation status

We addressed all of these in Realm of the Mad God, with great success. In Realm, you can log in to any server with your character, and switch servers any time, instantly, for free. Tells work across servers, so you can talk to your friends no matter where they are. Realm has no horde/alliance split, and there are no level gates for content. If a player is skilled enough, he or she can take a level 1 character into the toughest situations, and with a group of friends, a newbie can advance quickly. Powerleveling is built into the game.

Realm doesn't have traditional quest chains and doesn't require quests for efficient leveling. Realm has no "gear check" dungeons or rep grind. The game lets players teleport to any other player on the map, with no level restrictions or permission required -- the ultimate in instagrouping.

We eliminated all of these pain points with a little rule-breaking and creative thinking. Things don't always have to be the way they have always been.

Sandwich compatibility

A lot of games require two hands, one on the keyboard and one on the mouse. First-person shooters are the prime example of this, where the left hand is on WASD and the right hand aims and shoots. Real-time strategy games such as Starcraft require keyboard use for all but beginner play. Likewise with World of Warcraft and its many clones. Even my previous Flash MMO project Realm of the Mad God needs both keyboard and mouse.

I'm interested in exploring the idea of "sandwich compatibility." A sandwich-compatible game can be played with one hand, while eating lunch. One could argue that the sandwich compatible game was invented by the Earl of Sandwich. Actually, he invented the sandwich itself, but the point is that he wanted to play games and eat at the same time.


There are plenty of Flash games that need only a mouse, and that's one reason these casual games work so well -- you can play them on your lunch or coffee break. Tower defense, match-3, physics puzzlers -- none of them require a keyboard.

Related to the sandwich compatible game is the "bus stop compatible" game -- something you can play with one thumb on a smartphone while standing at a bus stop and holding a bag of groceries in your other hand. Angry Birds is a great example.

I'm working on a sandwich compatible MMO. I want to step back from the complexity of games like WoW and the hectic frenzy of Realm of the Mad God, into a more relaxing place. Dialing down the pandemonium and leaving one hand free lets people play more often, for longer at a time. And maybe someday the game can find a spot at the bus stop too.

Writing code

In school I was taught to plan out my code before writing it. They told me code reuse was important, and only high-quality, well-designed code was reusable. Slapdash, ad-hoc programming was a sign of incompetence and laziness.

So I always tried hard to write good code. After graduate school, I worked at Google, where no one was allowed to write any code until a design doc had been written, checked by a committee, revised, and approved. This was important, because Google's code was to be high-quality reusable stuff, and they didn't want anyone wasting time writing code that might have to be rewritten later.

When I left Google and starting building games in small teams, I kept all those old habits, assuming that they'd help my projects. Planning, writing up design docs, carefully building reusable code...these were the marks of a true professional. My code would be a thing of beauty, a testament to my engineering skills and long years of training.

But I discovered that this type of process is not appropriate when building a game in a small team. The problem is that a fun game can't be planned out in advance. It is impossible to design a game on paper, then build it, and have that game be a success. Only by iteration and testing can a game be made fun, and you can't iterate when the design of the code is set in stone at the design doc phase.

These days I write all of my code quickly without planning much at all. The idea is to get something, anything, working, as fast as possible. If the code becomes a problem (slow, unreadable, buggy, inflexible...), I can clean it up or rewrite it later. More likely, the code will be just fine, or get thrown away in a later iteration. So why try for perfect code up front? Why face the paralysis of an empty editor window and pressure to write the BEST CODE EVAR? Just write code. Write it! And fix it up later. Or not.


There is no "right way" to build software. There are no "best practices" for coding. If it looks like a haphazard collection of bolted-on pieces, it's because you moved quickly, iterated fearlessly, and shipped. Awesome!


Non-player characters are the computer controlled guys that you don't fight against. They buy and sell weapons, give out quests, and fill you in on the game's lore. Sometimes they join you in battle; sometimes they flee or cower. They guard town areas against enemy attacks. Sometimes NPCs have to be safely escorted from one place to another. They identify your items, repair your equipment, and teach you new skills. Sometimes they just wander through town chit-chatting idly. But they always shatter immersion with their badly-written dialogue, robotic demeanor and farcical incompetence.

A typical town merchant NPC has the personality of a vending machine. A typical combat retainer has the tactical sense of an eight-year-old playing laser tag for the first time. Escort quest NPCs are the worst of all, doggedly walking forward against all common sense, determined to die in the most inept way possible.

I have a special dislike for quest givers.  The hovering punctuation, the underwhelming mission text, the golem-like 24/7 presence...a quest-giver's existence resembles a punishment handed out in a myth: to stand forever in one spot, begging strangers for help with a problem that can never be solved.

I've pretty much given up on NPCs, and if at all possible I won't be including them in my projects.


It is rare to find a fully co-op MMO -- almost every game of this type supports some form of PvP. However, Alex Carobus and I designed Realm of the Mad God to be fully co-op, and I intend for Jetbolt's MMO project to do the same.  This is because supporting PvP entails significant costs, and I don't think they're worth paying.

If players are to fight each other, the game's viability teeters on the knife's edge of exact PvP balance. As with the Protoss, Terran and Zerg, any difference in PvP effectiveness between classes spoils the fun. Traditionally, PvP MMO designers have balanced the PvE and PvP games separately. Certain abilities, such as roots, snares and mezzes, have to get nerfed specifically for PvP. Other abilities, such as mind control or charm, make little sense in a PvP context. The result is two different games in one (PvE and PvP), and a serious commitment for thorough, exacting PvP class balance.

Another problem with PvP is griefing. A certain segment of the game-playing population enjoys random ganking, but many are turned off by it. Various games try to control griefing by limiting PvP to certain areas or times.  Others rely on reputation systems or NPC guards to keep peace, or they use human gamemasters to adjudicate disputes. In any event, precious developer resources are consumed by the systems that must be built to contain PvP-related griefing.

Supporting PvP also makes the game engine more complicated. Unavoidable Internet lag means that each player sees a slightly different picture of the world. What happens when two players both think they've killed the other? The answer is complicated, and generally unsatisfying to one party or the other.

For all of these reasons, I'm avoiding PvP and building a fully co-op MMO. In addition to simplifying big parts of the game, this decision allows me to focus on deeper co-op gameplay. For example, how can MMO players collaborate to build a city in a way that's satisfying for everyone?


Flash is great for stuff that runs in the browser, but for server-side heavy lifting, C++ is my go-to tool.

C++'s many flaws and disadvantages have been carefully documented over the years. The language is too big; the compilers produce lousy error messages; the standard template library is too hard to understand; there is no need for a low-level language in this day and age.  My biggest gripe with C++ is the sheer number of ways to introduce near-impossible-to-find bugs: using uninitialized memory, freeing memory twice, using a dangling pointer, mixing malloc/free with new/delete, leaks, overruns, dereferencing NULL ... the list goes on and on.

However, C++ has one advantage that makes it all worthwhile: predictable, screaming fast performance. The compiler generates real machine code, not bytecode, and the old school manual memory management means that the server will never take a time out to garbage collect. For MMOs, better server performance saves money by reducing the number of machines needed, and it increases the number of people that can play together on the same server. As for the excruciating task of preventing pointer bugs ... I guess I'll just have to live with that.


I've been using Flash, specifically its programming language Actionscript 3, for about four years now.

I started writing Actionscript code with Alex Carobus back when we founded Wild Shadow Studios. We chose Flash because it was already everywhere -- just about anyone could play a Flash game without having to install a plugin. We believed strongly in eliminating barriers that prevented people from trying our games, and Flash offered one-click, no-hassle access. Surfing to our website would fire up the game automatically.

What a pleasant surprise it was to discover that Actionscript 3 (which was new at the time) was a modern object-oriented language, with compile-time type checking, classes, inheritance, encapsulation, and other language features that engineers look for. It had extensive facilities for moving pictures around the screen in various ways, which is pretty much the main goal in video game development. But what really sealed the deal was Actionscript's support for sockets -- a game written in Actionscript could open a direct connection to a server, which meant we could use Flash to make an MMO client.

I have a few complaints about Actionscript. Its garbage collector has some frustrating quirks. It's not nearly fast enough for computationally intensive code. There are a few syntactic oddities. But on the whole I've been extremely pleased with Flash, and I plan to keep using it.