Programmer Joe

If we want to keep them, we need to make our players passionate about our games. The best way to do that is to have them kick ass as much as possible. In the case of MMOs that means completing tasks that make the player feel heroic or villainous (as appropriate) but always as though they are important and successful. So why do we so often start players out with quests that force them to fill the role of exterminator?

Vanguard: Case Study of Heroes
Take for example, these two starting quests in Vanguard. These are the first quest offered to humans and orcs, respectively:

The human on the left is being asked to kill 8 Leafsaw Crawlers, which are a kind of beetle about two feet in length. The orc on the right is being asked to kill a slaver, release a fellow slave, and make his way across the slaver-infested beach to safety. Which one of these players do you think is going to feel like they’re doing something important?

Just so there’s no confusion, this is what a Leafsaw Crawler looks like next to my human psionicist:

This distinction continues well into the beginning quest chains of both characters. For the human the first several quests go something like this:

1. Kill 8 Leafsaw Crawlers
2. Collect 6 plants and deliver them
3. Kill 10 scorpions (also about 2 feet long)
4. Kill 10 giant scorpions (which turn out to be about 8 feet long, but aren’t any tougher than the little ones)
5. Kill enough rat-men to collect the right number of rat-man parts
6. Kill 15 rat-men of a higher level (who have scorpions working for them)
7. Collect 10 miniature scorpions
8. Deliver the miniature scorpions to the rat-men and see a little in-engine cut-scene
9. Escort a camel to the city (along a perfectly safe path)

Contrast that with what the orc does for the first several missions:

1. Kill a guard and use his key to free a slave
2. Escort the slave to safety across a beach full of hostile orcs
3. Kill 10 or so more of the hostile orcs to help the defenders on the beach
4. kill 10 of a slightly different kind of hostile orc to collect medical supplies for the wounded defenders
5. Use the supplies to heal the wounded
6. Travel inland a bit to a friendly goblin agent
7. Kill enough frogs to get the frog-parts you need to…
8. Mask your scent from the hostile orcs’ guard dogs so you can sneak into their camp and steal their invasion plans
9. Kill a hostile orc boss

These are just the first missions in each of these areas. I gave up on the human at that point, but the orc goes on to muster defenses to push the hostiles back into the sea (and various other interesting and useful things.) This represents the first two hours of game-play in each case.

What about other games?
This problem is not unique to Vanguard. In fact, many MMOs make player spend their first few hours doing shit-work:

• World of Warcraft — For at least Night Elf, Dwarf/Gnome, Orc/Troll, and Tauren, the first few missions are all either simple “carry this over there” missions or involve killing the local fauna for their fauna-parts. Eventually, right at the end of the newbie areas, you usually get to fight some minor humanoid enemies.
• Auto Assault — You spend the first hour or two in this game driving around killing irradiated crabs with your turret-mounted machine gun.
• Star Wars: Galaxies – Pre-NGE you spent a few hours killing local animals until you leveled up enough to start taking on smugglers and bandits. Post-NGE you kill a couple stormtroopers, and then it’s back to animals for another hour.
• Everquest — My human monk killed lots of bugs on his way to level 8 (which is where I quit the game.)
• Guildwars — You actually start running into undead about an hour in, but up to that point it’s all killer plants and local fauna.

We should strive to be more like the games that let you kick ass from the beginning:

• City of Villains — The first thing you do in CoV is break out of jail. And you get to beat up a bunch of fellow prisoners in the ongoing riot on your way out.
• Everquest 2 — After a false start killing a rat or two on the boat your first few quests on the newbie island are about defending the village from invaders.

This isn’t about mechanics

None of the differences here are about the power-curve as you level, fighting multiple opponents, speed of advancement, or any thorny tuning issues. The magic ingredient in an ass-kicking newbie experience is context. The player needs to have their important status in the world established through mission design, character art for opponents, and flavor text. They don’t need to be the most powerful character in the area, but they do need to feel like they are able to excel at their tasks, and that their tasks aren’t just busy-work.

Are there other ways the player can kick ass in their first few hours? What have you tried in your game to give players this sense of success?

The single biggest factor that decides the amount of work you need to do to get your game out the door is the project’s scope. Time is money, so it’s also the single biggest factor determining the budget of your game. If your scope grows halfway through production, your game is going to slip. Making certain decisions early and sticking to them will have a big impact on your ability to ship your game in a predictable amount of time for a predictable amount of money.

Scope in Game Design

The best place to control scope is in your game design. A single paragraph in a design document can represent day or weeks of work for other departments, so it is vital that the game designers keep project scope firmly in mind at all times. To that end, here are some things that designers can determine at the start of the process to keep the scope constant.

1. How many player modes does your game have?

How often does the control scheme change in your game? Does the UI change with it? For many MMOs there is only the “run around and fight stuff” player mode, and the player’s avatar follows that control scheme consistently throughout the game. Some games, like Star Wars Galaxies (with Jump to Lightspeed) and Pirates of the Burning Sea have the standard MMO player mode for avatars and a very different player mode for vehicle combat. If you budget for one player mode but try to cram two in, your players will notice and they won’t be happy about it.

The number of modes will drive how many times you need to fine tune the UI, camera controls, and character controls. Every UI element in the game needs to consider player mode to decide if that UI element can appear in all modes unmodified or if it needs to be customized for one or more modes. If you are trying to build a game on the cheap, find a design that works with only one player mode. A second mode won’t double your budget, but it will increase it substantially.

2. How many players do you want to support in a single world instance?

Much of the budget of your game is driven by shard size. You will need a lot more space in your world to support 1,000 simultaneous players than to support 100. You will need more zones, quests, NPCs, mobs, long distance travel mechanisms, and map systems the bigger your world gets. Figure out how many people you need in the game to make the multi-player systems function and use that to drive the other number-of-players based decisions (like world size.)

3. How many parallel advancement paths do you have?

Many games allow the player to advance along many paths at the same time. WoW has level, two crafting professions, and honor-point based advancement. SWG had three major skill advancement paths (crafting, combat, entertaining) plus faction-base advancement. Each of these paths has unique ways to make and measure progress that are not present in the other paths. That means they each require design of new advancement systems and new code to implement those systems. To keep your costs down, use the same mechanism for advancement in all of your parallel paths. If players earn XP that they use to buy skills off a tree, use that for all your paths and differentiate based on how they earn XP. If the players advance down a linear path by using skills but spend currency on buying skills off the line, leave everything the same except the way they take a step down that path.

4. How many branching advancement paths do you have?

Many of your parallel advancement paths will have branching within them, or at least allow the player to select a small number of parallel paths out of a larger set. The number of options has a big impact on how much time you will spend tuning your game. You will also need unique skill icons, animations, particle effects, and equipment for many of these branches, so the number of options will directly affect your art budget. Determine early in the project how many branches you need to let the players feel differentiated, and stick with that number. Adding branches after launch incurs the same tuning cost as adding them before launch, but is something your players will love.

5.How important is replayability to the game?

Do you expect players to play through the entire game with several alts? How many different newbie experiences do you need to provide? Each of these parallel content paths costs scarce content creation time. If you aren’t expecting a lot of replay from the beginning there may be time you can save here.

6. Do you need a seamless world?

Does your game call for a seamless world? For some games the answer is definitely “Yes”, but many games will do just fine with hard zone boundaries. Some players will make noise about the loading screens, but that’s true of any design decision you make. Having zones didn’t hurt EverQuest or Dark Age of Camelot’s performance, and I don’t think that having a seamless world has really helped World of Warcraft’s.

Seamless worlds are more expensive than zoned worlds. On the art/world building side you have to build the transition areas in a way that lets you have the textures and geometry from both areas loaded at the same time. The world builders also have to deal with editing what’s effectively one continuous ground mesh for the whole world. Engineers get a lot of extra work from seamless worlds because of the server hand-off issues and issues with players acting across server boundaries. The game’s world building tools have to be much more sophisticated to support editing transitions between zones. Operations and customer support costs are going to be higher for a seamless world thanks to all the object-dup and object-lost problems that are inevitably going to crop up with the more-complex server technology required.

If your game requires a seamless world, by all means use one. If not, use zones and save yourself months of development time. Make sure you stick with this decision once you make it, however. Switching from one to the other is going to invalidate a lot of code and art.

Scope in Production

There are many production-level questions to resolve to determine the scope of your project. These factors don’t really affect the game design, but can change the way the game appears to your customers.

7. How big is the gap between your minimum hardware spec and your recommended hardware spec?

Your art and engineering teams are going to have to do the most work to make the game run well on your minimum spec machine. If your recommended spec has to look significantly better than that, you will probably be incurring significant additional art time for second versions of many assets. You will also require additional engineering for the switching between quality levels.

8. How high-end is your minimum hardware spec?

You pay for every pixel and every polygon that an artist produces. Higher poly budgets and bigger textures will increase the time it takes for your artists to develop assets. Because these things are driven by the CPU and GPU horsepower on the min spec machine, picking your minimum hardware spec can have a huge impact on your project’s scope. Higher system requirements will also affect the potential size of your market, particularly in Asia.

9. Can you buy technology, or do you have to build it?

Developing every new piece of technology for your game costs money. You can often constrain the scope of the project with middleware. There are game middleware products for just about everything these days, so even if the “whole game” middleware like Big World or Hero Engine don’t work for you, smaller “just one feature” middleware like Speed Tree, Path Engine, or Ageia’s PHYSX probably will. Of course middleware is never going to do exactly what you need it to do, so evaluating and integrating this middleware as early in the process as possible will allow your designers to deal with middleware limitations in the game design. You don’t want to get into production and then find out that a core element of your design and a core piece of your middleware are incompatible.

Scope your project early

Every single one of the 9 scoping decisions listed above is a decision that needs to be made early in the project. In fact, they are core enough to the process that you probably have answers for many of them in your first round of documentation. Make sure these are things that you talk about up front. Spend enough time prototyping your game that you can be sure that you have the right answer to each question. If you think you need to change the answer to one of them, take a step back and see how that will affect the project’s scope as a whole. Don’t allow your scope to drift gradually upward without ever having made the decision to change it.

Be realistic about your project’s scope. If you can’t build the game you want at a given scope, don’t just charge ahead and try to do it anyway. Either accept that your game is a bigger scope (and higher budget) or start again and come up with a game that you can build at the scope you can afford. There is no shame in building a game with a small scope. Puzzle Pirates, City of Heroes, and World of Warcraft are three games with very different budgets. The thing that they all have in common is that they have solid return on investment and are making plenty of money for their respective companies.

Once you decide on a scope for the project, make sure that everyone knows what it is. Let your team, your community, and your publisher know what your scope is the whole way through the process so that they can set their expectations accordingly. If you change your scope (and slip your target date), make sure you include the scope slip as one of the reasons you’re slipping the date.

Controlling the scope of your project is the first step to controlling the project’s budget and schedule. If you want to avoid slipping repeatedly or being forced to launch before you’re ready, scope creep is something you must watch out for. You will be glad that you did!

When we started on Pirates we tried out two major pieces of procedural content and eventually ditched both of them. What appeared to us to be a panacea of free art was actually a rabbit hole of endless programmer resources. So while I love the idea of procedural content, I’m wary of including it at the core of a game. You have to evaluate your procedural content options very carefully.

We’re making a game that takes place largely on the water. Most of the time the screen is filled with sky and water.These were the two areas where we tried to use procedural content instead of something hand crafted. Neither of them worked out very well.
Procedural skies

Five years ago, or so, Naty Hoffman and Arcot J. Preetham had an article in Game Developer that was based on the work they did on environmental light scattering. The idea was that if you simulated the physical process of light moving through the atmosphere you could achieve the same sort of fantastic lighting conditions that you see in the real world. Read the paper if you want details, but the basic idea was that you could input certain atmospheric constants and the sky would paint itself.

The trouble was that these controls were extremely high level, and it was difficult to control them to get the results we wanted. With massive tweaking we could get results that looked ok in certain circumstances, but once you moved the sun or put in different terrain, it didn’t work so well anymore. And the skies always looked fairly bland because their approach didn’t include clouds, and we never figured out a way to add clouds to it that had the same kind of flexibility. Clouds are a whole other problem that people have tried to solve with procedural content all its own.

When we gave up on the raw formulas, we tried a few other approaches that let us control the lighting more directly with keyframes, but it didn’t really help. The artists still didn’t have as much control as they wanted and nobody was happy with the results.

So we ditched the whole thing and went to three very clear inputs. The artists understand them fully and produce amazing results:

• A hand-painted skydome texture – We start with panoramic shots of the actual sky, and then an artist removes jet contrails and beautifies them.
• The distance fog color at maximum distance – All the non-sky stuff fades to this color when if it gets far enough away. These are tuned to match the skydomes
• A scaling factor on the fog distance – Some environments don’t let you see as far because of “atmospheric haze”, but it’s really just distance fog. This is also matched to the skydomes.

Ocean Waves

We had a similar problem with the ocean waves. Most of the screen is covered with ocean most of the time, so we had to have a wave solution that could extend to the horizon. I can’t seem to find any of them now, but at the time (early 2003) there were several papers floating around that suggested using Fast Fourier Transforms (FFT) to simulate wave motion. We went ahead and implemented such a system that had about ten inputs with such helpful names as ‘a’ and ‘b’. Initially we tried to compute the FFTs at runtime, but even with a small grid it still took tons of CPU, so we started baking them offline and just playing back pre-animated wave sets.

This is another system that didn’t have any kind of reasonable artist control. Maybe they could have worked brilliantly given many more months of development, but we eventually ended up ditching them in favor of something much simpler. Now we’re using Perlin noise in viewspace to render the ocean waves, which is MUCH faster to compute and draw, and has controls that let us get the kind of results we’re looking for.

Make sure your procedural algorithms are ready

In both of these cases we picked algorithms that were not really ready to go into a game. There was no middleware for either one (though some ocean middleware has come on the scene since then), and were really just early academic research papers. These things are difficult to turn into amazing looking screenshots, and are probably just a waste of your time. Tried and true methods (like textured skydomes and distance fog) will get you reliable results in a reliable timeframe, and you would be well served to consider them seriously.

In the end, I’m very happy with the results. The game looks great, and I don’t miss the headaches that these two procedural approaches caused. Take a look at these screenshots and I think you’ll agree.

• Jungle beach
• Ships at sea
• Island jungle

I’m not saying that procedural content is bad. I think it shows great promise as a way out of ever-increasing budgets and spending millions of dollars of artist time on content that any given player is only going to see once. You just have to leave plenty of time to get your algorithms right, and build them with plenty of artist control.

Jason Booth and Danc at Lost Garden both posted on this recently. If you’re interested in procedural content, you should definately read both of their posts. There was also a recent article on Game Career Guide on the subject, but it was pretty light on actual meat.

One of the Project Horseshoe reports includes the question, “How could one build a game that delivers the experience of tasting a peach?” An article at 1Up asks, “Can a game make you cry?” Eric Zimmerman hosts the Game Design Challenge panel at GDC… the first one was “How do you make a game about a love story?”

My answer to each of these questions is, “Who cares?” All of these are interesting topics to BS about in various collections of game developers, but at the end of the day, this is not how these things are actually going to be accomplished. One day some guy we’ve never heard of will decide that what he really wants to do is to make a game about a love story. Let’s call him Betty (because I hope he’s actually a woman. We need more of those in this industry.)

Betty will come up with some game that she’s sure will launch this new genre, but it will not do very well. After all this was Betty’s first game and she didn’t really know what she was doing. Undeterred, she’ll try again, and again, and will eventually reach her goal. Maybe her game will be a huge commercial success, or maybe not, but it will be a game that gives the player the same sort of feeling they get from a romantic book or movie.

The reason that Betty will ultimately succeed is that making a game about love is her passion. She’ll keep plugging away until she gets it right and won’t listen to the people who tell her it’s not possible. She won’t get her ideas by sitting in a BS session at a conference, she’ll incorporate bits of other media, parts of existing games, scraps from books, and portions of her own life, and make game after game until the work, improving each one with the results from the previous try.

This is how it always works. A great (and recent) example of this happening, is the story of Harmonix. According to their website, this is how it started:

Harmonix was founded in 1995 by Alex Rigopulos (CEO) and Eran Egozy (CTO), who met while working in the computer music group at the MIT Media Laboratory. Alex and Eran formed Harmonix initially not to develop videogames, but rather to create new ways for non-musicians to experience the unique joy that comes from making music.

Their first two attempts at doing this with a game did fairly well in the marketplace, but didn’t really reach the goal of showing non-musicians the joy of making music. They didn’t stop there, though, and eventually came out with Guitar Hero. Talk about a game that makes you feel like you’re making music…

As far as I know nobody actually cares enough about putting the taste of peaches, tear-jerking, or love stories into games to actually show this kind of dedication. The people who participate in this sort intellectual exploration aren’t going to bring about these sorts of games. At best they are providing a little entertainment for the rest of us.

So if you really care about these sort of radically different game designs, don’t just talk about them. And if you aren’t, why don’t you talk about something you do care about? I bet those ideas are more interesting anyway, and way more likely to ever be implemented.

It recently came out that City of Heroes is adding crafting to their game. This is something they’ve been talking about doing for years, so it’s not really a surprise. What I wonder is, are they in a position to experiment with game systems in City of Heroes that will eventually find their way into Marvel Universe Online?

I’m going to go out on a limb and say that Marvel is going to have a lot in common with CoH gameplay-wise. I’m sure they will act on lessons learned from CoH, and the code base they started Marvel with will give them a head start on much of that, but I suspect that the two games will have at least these things in common:

• Extensive character customization
• A lot of ambient life in the shared spaces
• Instanced missions
• Zones
• Three dimensional movement and exploration
• Physics (though I’m sure this one will be used much more in Marvel)
• Combat that features one player hero on many NPC opponents
• Total unwillingness to sacrifice PvE fun on the altar of PvP
• Classes, races (or “origins”), and levels
• A steep power curve as you level up

If Cryptic wants to make changes to the formula they had in CoH for Marvel, wouldn’t it be best to make those changes in CoH as an experiment and use what they learn from the results in Marvel Universe Online (MUO?)

There are very few teams I can think of that might have had that ability. Turbine and Sony have the only development teams to release multiple MMOs at this point. Did Turbine use Asheron’s Call as a place to experiment on new features for AC2? The core game systems in that case were so different that I’m not sure they could have. AC2 was obviously designed to address some of the perceived issues in AC, but Turbine couldn’t very well add classes to their skill-based game just to try it out. In SOE’s case there probably wasn’t much to try out in EverQuest when they were working on Star Wars: Galaxies (and Austin is a long way from San Diego anyway.) I’m sure that the EQ and EQ2 teams have a lot of people in common… I bet that EQ’s endless stream of expansion packs provided them with lots of useful data to put to use in EQ2.

Mythic is in a similar position. From a high level the game systems in Warhammer Online and Dark Age of Camelot will probably be pretty similar. Have they made any odd “next-gen” kind of additions to DAoC recently that could indicate such an experiment?

What about you? Have you ever put something in a live game just to see if it would work?