Jetbolt Games

Groups are a pain.

To party up with other people, you have to find a group that is:

• nearby
• of your level
• of your faction
• doing something you want to do, and
• looking for help from a character of your class.

Next you have to risk rejection by asking the group leader if you can join. How often do you approach stangers in real life and ask to hang out with them?

Things don't get a lot better once you're in a group. Members with below average effectiveness generate hate from the pros. There are arguments over loot. Any single member's bio/food break halts progress. Everything tends to slow down: xp gain, quest progress, loot acquisition. To put it in mathematical terms, everyone in an n-person group gets one nth of the rewards, but the group is not n times as effective as a solo player.

In Realm of the Mad God, Alex and I used ad-hoc groups to address these annoyances. There are no group leaders; there is no way to add or kick members. When a monster is killed, the game gives XP to everyone nearby. And instead of dividing the XP by the number of players, it's duplicated for everyone. For any kill, a five-person "group" earns five times the XP a soloer would.

The goal was "the more the merrier:" playing with other people should always be more fun and rewarding than playing alone. Realm has not fully achieved this goal, as players still compete with each other for loot drops. But as Jetbolt's new MMO project begins to take shape, this ideal is looking more and more attainable.

Flash games have developed a great feature: to play, you click "play".

The best ones don't even give you other choices—the big "Play!" button is pretty much the only thing on the screen. When you click it, the game starts up right away. You start having fun immediately.

Most online games don't meet this ideal. Sure, there may be a big fat "Play Now!" button on the game's website, but it doesn't do what it says. Instead, it leads you to a registration page where you enter your email address and choose a password. Whoops, it needs to include a capital letter and at least one number. And by clicking "Submit" you also agree to be bound by an enormous legal document that you haven't read. Then you check your mail and click a link in the message to get to a download screen. You spend several hours downloading, then another 30 minutes installing, and finally you are ready to click "play" again. But this launches an updater which downloads patch after patch, requiring you to click "OK" at odd intervals for another 45 minutes. When this is finished, another "Play" button appears. When you click it, you see a server selection screen. After puzzling over your choices—role-playing pvp?—you eventually choose a server at random and log in with the password you created hours ago on the game website. Next you are told to create a character, which involves choosing a faction, then a race, then a class. You haven't played the game yet, so you have no experience to guide you, and after fruitlessly trying to figure out which of the options would be most fun for a newbie to play, you eventually just guess. Next, you must pick a name that nobody else is already using. You start off trying cool names ("Gandalf") but eventually settle for something containing numbers or punctuation. Then you design your avatar: gender, height, weight, face shape, hairstyle, hair color, eyebrow type and a million other appearance details. You have to be super careful here because you're pretty sure you won't be able to change your mind later. Finally you click "play" one more time only to be confronted with an unskippable cutscene in which credits roll while a mediocre voice actor reads off the game's backstory in a British accent. At long last, you see your character, briefly, standing in a town. But he is immediately obscured by a large assortment of dialog boxes full of notices, instructions and tips.

These frustrations scare off all but the most committed gamers. But ordinary people want to play games too, and we designers should let them click play to play.

I think of "grind" as a not-particularly-fun, not-very-challenging activity that players do anyway in order to advance their characters.

For example: walking into town, getting a quest, walking to the zone with the monsters, fighting the monsters, walking back to town and turning in the quest. I suppose it's fun at first, but soon enough this pattern gets repetitious, then boring, then tedious, and after a while it's more work than game. So why do it? Rewards -- in this case, XP, gold, equipment and levels.

Rewards are powerful incentives. There is something about the "get task, do task, get reward" loop that human brains find irresistible. As long as the task is fun, it's a game. When it's no longer fun, it's grind. But players do it anyway, to get the rewards. Eventually they realize they hate the game and quit, disgusted at how much time they wasted on it.

But there is another way to look at grind. Sometimes, after a long day of work, people want an easy, semi-mindless project to help them relax: quilting, whittling, raking leaves, waxing the car. There's a reward at the end (a new quilt or a shiny car), and it's even better when they do it with friends. Grind can provide this relaxing activity; combined with guilds, grind serves as a virtual knitting circle or fishing hole -- a way to relax with friends while working on a task that isn't particularly hard.

So is grind good or bad? It's bad when the developer uses it as a crutch for phoned-in game design. But it's good when it builds community. As designer my goal is to make the "do task" part as fun as possible, and if I've done that then maybe I don't care if you want to call it grind.

To many the idea of an indie MMO seems daunting or outrageous. Typical MMO games such as World of Warcraft or Star Wars: the Old Republic have budgets of hundreds of millions of dollars and staffs of several hundred people. How can a little indie team possibly compete with that?

But there have been indie MMOs, and some are still going strong after many years. The most famous and successful of these is RuneScape, which began as a bedroom project of two brothers. Others include the granddaddy of them all, Meridian 59, built by a five-person team in the mid 90s, Andrew Tepper and Josh Yelon's A Tale in the Desert, and Gene Enrody's Sherwood Dungeon. In 2010 Alex Carobus and I built Realm of the Mad God and launched it after only one month of work.

When building an MMO in a small team, it's important to avoid competing head on with big-budget games. You will never out-WoW WoW, so don't try. Instead, be different. Meridian 59 was faster; it beat the big games to market. A Tale in the Desert stood apart using innovative co-op gameplay and server-wide cooperative story arcs called "tellings." Sherwood and Runescape ran in the browser, making it easier for people to play while lowering expectations for graphical detail. Realm of the Mad God used all of these techniques: it was one of the first Flash MMOs, it used unexpected mechanics such as permadeath and bullet dodging, and it used low resolution 2D sprites to keep asset costs down.

So yes, it's possible for a small team to have success in a field traditionally dominated by giants. But it requires some nontraditional thinking.

Most of the time, MMO avatars are people: humans, elves, dwarves, taurens, undead, Vulcans, Ferengi, Corellians, Kryptonians, etc. However, there are a few examples of MMOs that use vehicles as avatars.

Auto Assault was (by most accounts) a spectacular disaster of a game in which players drove cars around a post-apocalyptic landscape grinding out WoW-style quests using some very boring hotbar combat abilities. It was put out of its misery in 2007 after a year and a half of operation. 

On the opposite end of the spectrum is EVE Online, a complicated PvP sandbox game set in space. In EVE, players fly spacecraft -- miners, freighters, fighters, battleships. EVE has been up for almost a decade and keeps getting more and more subscribers.

There are pros and cons to using vehicles as avatars. A disadvantage is that it's harder for people to relate to a machine -- players connect better with humanoid avatars. On the other hand, games using vehicular avatars have an easy way to let players change what their "character" looks like -- just jump into another vehicle.

I'm interested in vehicular avatars for a different reason -- they're easy to draw. My current MMO project uses vector art and a top-down camera view. Drawing humanoid avatars from that perspective means that players would only really see the tops of their characters' heads. But vehicles like tanks, helicopters and hoverbikes can look really good from that viewpoint.

Artistically, I would like the game to evoke top-down vehicular vector classics like Asteroids, Space Duel, Star Castle and Geometry Wars. This look is really different from what you'd typically see in an MMO, but I'm excited to try to make it work.

It's pretty clear by now that the old MMO subscription model is not viable for most games. Back in the day (say, 2004), there were only a few games to choose from. They charged about $50 to get started, and $15 or so per month thereafter. That was a lot of money to try out a game you've never played before, but with such limited competition, what choice did you have?

These days, there are bunches of online multiplayer games, and with greatly increased competition, something had to give. Just as before, a few games could get away with the subscription model -- the biggest, most life-consuming, all-things-to-all-people games like World of Warcraft. There is enough to do in WoW that many who pay the subscription don't play any other games. But not every game is as big as WoW, and these smaller games need a different model -- free to play.

Of course "free to play" doesn't mean you can't pay; it just means you can play "some" before paying. And that's about all you can say in terms of a clear definition of free-to-play; there are enormous numbers of variants of the model, and the industry is actively experimenting with new ones all the time. Someday there may be some convergence, but we haven't hit that point yet.

Alex Carobus and I had great success with free to play on Realm of the Mad God. We let everyone play the whole game for free, but we gave our most fervent fans the ability to pay us as much as they wanted for extra storage space, extra character slots, clothing, pets and more. We were not comfortable with selling outright game advantage, but we also wanted to avoid the commonly seen model of making the game painful and annoying until the player ponies up some cash.

Jetbolt's new MMO will use the free-to-play model. I'm not sure yet what types of things players will be able to buy, but my goal is to strike a balance between fun for everyone and the ability of true fans to spend as much as they like on their gaming hobby.

Could leveling up be the most well-worn trope in all of gaming?

Levels began as a shorthand for keeping track of progress in pen-and-paper roleplaying games. When RPGs made the leap into computer form, levels came along, and then they started leaking out into other genres. These days it's tough to find a game that doesn't include levels in some form or another.

One reason the level-up mechanic is so omnipresent is that levels represent a reward that the game can hand out to the player at regular intervals. Human brains absolutely love getting praise, even for trivial accomplishments. It is not a joke -- adding level-ups to a game pretty much always makes it more attractive, at least in the short term.

While levels are an effective (if overused) mechanic in single player games, levels have at least one tremendously negative repercussion in multiplayer games: levels separate you from your friends. The whole point of playing a multiplayer game is to play with others -- your friends, your guildmates, even the random Internet people who'll become your friends later. When the level difference between you and the people you want to play with is too great, you can't play together, and that's terrible.

Jetbolt's new MMO project employs a territory capture mechanic that has all the players working together to secure land from the enemies. Everyone fights on the same battlefront against the same foes. There are no level-appropriate zones -- only a combat front that shifts over time as territory is won or lost.

This mechanic lies in direct opposition to the levelup system. In traditional games, a character increases its power by 10 to 50 percent at each level. A high level character is hundreds of times more effective than a first-level character. Obviously, this sort of progression prevents characters of different levels from working together. One simple way to fix this is to compress the progression scale, so that high-level characters aren't that much more powerful than low-level characters. Another method is "horizontal" progression, in which levelups unlock new weapons, abilities, classes, vehicles, etc, without necessarily increasing character power. Another way is to treat levels as achievements, awarding badges, titles, costumes and other non-combat perks for leveling up.

One mechanic I'm considering is giving out the most powerful level-up rewards server-wide based on progress made by the playerbase as a whole on that server. That is, as the players capture territory on a given server, all players on that server level up together, giving them the ability to take the fight further. This means that everyone on a server can work together at all times.

I'm hoping that a judicious combination of these techniques will allow Jetbolt's MMO to retain some of the benefits of levels while mitigating the drawbacks.

I am hoping to explore territory capture in Jetbolt's new MMO project. Many games use this mechanic, from the ancient game of go to real-time strategy games, first person shooters, and sandbox MMOs.

Territory capture in MMOs is normally a PvP thing. In theme park games, factions typically battle over a designated region, with some type of buff or other reward given to the side that holds the objectives. In more complicated sandbox games, guilds or clans hold regions of the game world against all comers, building infrastructure and defenses while trying to profit from their holdings and gain even more land.

As I'm less interested in PvP, I'm planning to try co-op PvE territory capture. In this idea, the game world starts out completely overrun by enemies, and it is up to the players to take it back. Players work together to defeat the enemies, destroy their structures and decontaminate the land. Then they build structures of their own and exploit resources in the newly-recaptured area to continue the campaign.

There are a lot of question marks in a game like this. Can the players "win"? What happens then? Do players level up? If so, how will they cooperate if they are at vastly different levels? How do zones, stories and quests work? Can newbies or griefers ruin things for others by building inappropriate structures in critical spots? I think I've got answers for a lot of these, but the only true test is to build something and let people play.

Clients and servers communicate with each other by sending messages encoded in a protocol. When we wrote Realm of the Mad God, Alex Carobus and I made up our own protocol. We designed it by hand to be small and fast, and it worked very well. But there was one major drawback: every time we wanted to augment or change the protocol, we had to go in and hand-edit a bunch of code in both the client and the server, and then record what we did in the protocol definition documentation. If we neglected to update one of the three, or if the changes did not match exactly, we were in trouble.

Google has built software called Protocol Buffers to help with exactly this problem. The protobuf system lets you write one file (the proto file), which serves as definition and documentation for the protocol. The system uses a "protocol compiler" to read the proto file and generate the client and server code. When you need to change the protocol, you edit the proto file, run the protocol compiler, and you're done.

Google's protocol compiler generates C++, Java or Python code. Although Jetbolt's MMO uses C++ for the server, its client is written in Actionscript 3 (AS3). To make the protocol compiler emit AS3, I had to track down an open source plugin called protoc-gen-as3 and massage it gently until everything worked. But once that was done, protocol changes were super fast and easy to make. Hooray!

On Friday I gave a talk called "Making an MMO with a Team of Two" for Carnegie Mellon's Game Creation Society. The GCS is an undergraduate club for making games. I met a lot of smart, energetic people and I hope to have even more interaction with them in the future.