Archive for the ‘Game Design’ Category

Controlling Scope

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!

Procedural content is hard

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. :)

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.

Less Talking, More Doing

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.

Game 1 as a Laboratory for Game 2?

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?

Game guides are evil

My Ultima Online Story

I’ve long been a fan of online virtual worlds, so when I first started to hear about Ultima Online, I was very excited. But terrible word-of-mouth reports from people I knew in the beta, even worse press, and the fact that I spent most of my computer time on HP-UX in those days kept me from actually playing the game until just after The Second Age came out in 1998. Some friends of mine were playing too, so I signed up for the game and picked their shard.

Even though things had settled down considerably (I think the massively powerful teleporting guards were patrolling the towns by then), I knew from the buzz that it was dangerous out there. So the first thing I did, before I ever logged in, was go out on the web and read what I could on how to play UO. There were various opinions on how to level up various skills, but there was one thing that everyone seemed to agree on at the time: In order to adventure in UO you had to have an in-game income, and the only way to get one was to craft. I’ve learned a few things about game design since 1998, and know that this was certainly not the case, but at the time I believed all the guides.

So I logged in to UO, used my starting money to buy a hachet and carving knife, and set out to become a fletcher. I knew from the buzz that it was a 24 hour PvP bloodbath outside of town, so I stuck to the few trees that I could harvest from inside of the city limits. These were pretty well exhausted all the time, but I did get some logs off them, wittle the logs into arrow shafts, and then sell the arrow shafts to an NPC.

I spent a couple of nights doing this before I gave up. I probably spent all of about 6 hours in UO, and in that time I never had a single fight. For that matter, I never even left the starting town. All because of that stupid “how to play” page.

If I had played UO the same way I played, oh, Ultima IV, V, VII, and IX, it would have been a much better experience. Sure, I might have been PKed. Sure I might have been a terribly ineffective character and never had any significant economic impact on the game. But I would have had a little fun in the process, and maybe I would have even stayed a subscriber past my free month.

And that is my sad UO story.

That was then, this is now

These days, it’s exactly the same problem again and again for every single game. The only difference is that people actually make money selling such guides. Players use the guides and miss the whole point of the game. The most boring way you can plan most games these days is to hunt randomly spawning mobs in an area, then move to a new area when you level to far and start the process over again. That’s exactly what all these guides tell you to do: play the game in the most boring possible mode.

I want to scream every time I hear someone say something like, “That game doesn’t really start until level 50″ or “Levelling to 60 is just practice for raiding.” That’s completely backward: The game is levelling up to the level cap. A bunch of games have an elder game tacked onto the end of their advancement curve, but it’s never the same game as the advancement game, and rarely as good. I don’t want to play a PvE game for a year getting to the level cap just to have it switch to a PvP game. I like PvE, and want more of the game I was playing before the level cap.
Even if people manage to avoid the “kill the same 5 orcs over and over, then move up to trolls at level 20″ trap of game guides, there is another trap that awaits them. The guides tell you all about the “best” way to play your class. They cause people to respec endlessly into the latest “killer build” until the game is dominated by Rifleman/Combat Medics, Fire Tankers, or Beast Mastery Hunters. The game isn’t dominated by these classes because they are unbeatable, they’re just more popular because somebody posted how to build them on the internet. Usually these builds are the least fun builds in the game because the authors of these guides are trying to maximize something other than fun. Sure, you can (or could before the mean old devs nerfed them) tank an entire instance full of bad guys with a fire tank that’s specced right, but after you’ve collected all the bad guys to one corner there’s nothing to do but sit there and wait for them to die. If I wanted to “win” without actually playing I would play Progress Quest.

What can we do about it?

I’ve already done something: I no longer read game guides. If I can’t find a quest objective, I’ll sometimes go find an answer to my specific question, but that’s it. I expect that reading the skill descriptions before I buy will result in a build that’s perfectly playable, even though it’s not optimal. I assume that the nerfs are for good reasons, and if they bug me too much I start another character (or another game, since I switch a couple times a year.) And boy has it made me happier with the games I’m playing.

In a more general sense, there’s probably nothing we can do. We don’t want to stop players from talking to each other, since that’s our best form of advertising. Any attempt to censor the sites that publish game guides would result in a lot of bad PR and be doomed to fail anyway. All we can do is try to keep our in-game help and interfaces friendly and helpful. Every player we can keep from feeling like they have to go to some external site in order to play our game is one that won’t be exposed to the horrors of the game guide.