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?

I saw Jonathan Coulton in concert tonight at the Tractor Tavern here in Seattle. I went to the show more familiar with the fan-made World of Warcraft machinima music videos than with his actual music, but it was the best concert I’ve been to in years, and I came away a fan. Even ran into a fellow game dev (well not anymore, actually, but I bet he will be again) in the Merch line. If you live in any of these cities, go buy yourself a ticket. You won’t regret it.

I just came across an article on Data-Driven Design for game engines. We have found it to be very useful to data-drive as much of the game as possible. Though we haven’t managed to be as complete in our purging of hard-coded game-specific features, we have gone pretty far down the data-driven road. The biggest thing that we still have hard-coded (and I wish we didn’t) are the global enums… things like the nations, careers, control types, and outfitting slots that appear in the game. The stuff that actually USES these things all comes from XML files, but the constants themselves are all defined in the code. Unfortunately that means that every time we need to add something to one of those lists we have to make a code change and make the poor designer wait for a build, a sin that breaks one of my own rules.

Look at me reblogging 5 year old posts.

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!

From Total Gaming:

Q: Obviously crafting has become a major part of MMOs. Tell us what the Invention system will offer players?

A: Since the “City of” games never had a crafting system or hard “loot” of any kind, we are kind of easing our playerbase into the concept. What you won’t find is a hard core crafting system that you must min-max numbers in for weeks to make the best “product”. What you will find is a fun new way to gain Enhancements, and Enhancements you actually desire. In addition, you can collect various “sets” of Enhancements which slot into specific powers. When you collect multiple pieces of the same set and slot them into the same power, you start to unlock new bonuses for your character that they didn’t have previously. This includes stuff like overall Damage bonuses or Defense bonuses versus specific attacks. Number crunchers will love the challenge of stacking these set bonuses, whereas more casual players will simply be happier that their character gets more powerful with each set they collect.

It sounds like they’re making Enhancements more like equipment is in other games.

Flying Lab is looking to hire an operations lead and a PHP developer. Click the link for details!

Yesterday, Costik posted about the dark side of digital distribution. Pointing out that Xbox Live Arcade and Nintendo Virtual Console are the first steps toward a world where Game Stop and Wal-Mart lose most of their power in the game industry. Microsoft and Nintendo could use their new power in an all-download world to maintain tight control over the games that are available for their respective consoles. This is the world he fears might come:

If the manufacturers control distribution to their devices, they don’t have to be satisfied with $7. They can take basically whatever cut they like. Oh, they still have to ensure that publishers can make money, sometimes–but they can ensure that they themselves earn the lion’s share of whatever profits a title generates.

In other words, it’s possible that digital distribution, rather than freeing us from the problems of retail, will instead concentrate power even more heavily in the industry–concentrating it into the hands of the manufacturers. While this would be good for them, its a prospect that both developers and publishers should be scared about–and an outcome that could only serve to continue the field’s descent into mediocrity and imitation.

While this is a possibility it’s not the only one. Microsoft beat the crap out of Apple (and NeXT, Commodore, and countless other companies) by embracing the Windows development community. Microsoft makes the best development tools in the world, and gives a version of them away for free. If you don’t want to use their tools, they distribute the platform SDK for free and put all their API documentation on the web for anyone to use. They do the same thing for Windows CE and their other embedded operating systems.

Notably, Xbox development tools are absent from this list. Like all the other consoles, these are only available to registered developers who sign lengthy legal agreements and pony up big money for Dev kits. With XNA Studio they have opened up the Xbox 360 to developers who are willing to limited to C#. It also has no real mechanism for Xbox distribution short of distributing all your source code and assets to another member of the XNA Creators Club. They can then compile and run it locally.

These are obviously pretty severe restrictions, but I think the point the direction that Microsoft is headed with hobbyist 360 development. I expect them to announce a service that will enable XNA Creators Club members to share Xbox 360 executables with each other via XBLA within the year. By the end of 2008 I expect there to be a mechanism that allows club members to distribute games (and non-game Xbox applications) to non-members. Chances are that this system will let people sell their games on XBLA (with Microsoft taking a fairly hefty cut, of course.)

Microsoft isn’t doing all of this out of the goodness of their hearts, of course. They have decided that they want to own the living room, and the Xbox is their ticket into that market. However, unless they’ve forgotten the last 25 years of their own history, they aren’t going to shut out independent developers in the process. They rely on independent developers to develop everything between the small and ubiquitous utilities that they roll into the operating system and the massive application suites that they want to develop and market themselves. It’s these mid-sized products that really make the difference between Windows and MacOS as a platform, and it will be this same size of application that Microsoft can use to finish killing off Sony and start in on Nintendo.

That’s pretty good news if you can be one of those mid-sized products. And most games are firmly in that category.

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.

The Austin Game Conference is now the Austin Game Developer’s Conference:

http://www.austingame.com/

It’s been reduced to four tracks:

• Online games
• Audio
• Game writing
• People’s Choice

I think I remember about twice that many tracks last year, but that doesn’t really mean much. They will probably run more than one session at a time in some tracks.

People’s Choice sounds interesting. I wonder if it will prevent the “you have to have been a speaker to be allowed to speak” catch-22 that GDC suffers from.

More comments on that Playdough report… My copy of Winning at New Products hasn’t arrived yet, though, so nothing specific about Stage-Gate.
While I agree that in an ideal world developers would be able to take multiple projects part of the way through development process and pick the best of them to survive at each phase, I’m not sure it’s practical. While the first few phases (like concept art and vision-level designs) are dirt cheap compared to the later phases (like cranking out thousands of models and a million lines of code), they aren’t free. Smaller companies (like the one I work for) may not even have the right personnel to develop multiple concepts at the same time.

Trying to keep track of this number of potential concepts is going to have a fair amount of overhead. In the case of an MMO, you have probably recently launched a game when you’re going through this process, and most of your team is still on the live team for the previous title. Running through exactly the same winnowing process, only in serial instead of parallel.

In this scenario, you would go through the same brainstorming session, but pick a much smaller number of ideas to develop into full blown game concepts. You might even concept out one at a time. You still run all the ideas and game concepts through exactly the same filters. You still need the same level of discipline to kill off weak ideas, you just don’t have to develop multiple concepts simultaneously.

In terms of actual dollars spent, the cost of these two methods is probably pretty similar. Assuming that your first concept doesn’t make it all the way through to release, you probably still build the same number of total concepts. You have to apply the tests the same number of times. The biggest difference in cost is the smaller overhead from trying to manage multiple concepts at once.

Of course the obvious disadvantage of serial concept development is that you don’t have multiple concepts going through the filters at the same time. When you can see all the concepts at the same time you can just rank them all from best to worst and, assuming they pass whatever requirements you have in your filter, let just the top few through to the next phase. When you are testing concepts one at a time days or weeks apart, you definitely aren’t going to be able to compare a given to the next one on the list, and you may not remember enough of the previous one to compare against THAT concept. You have to rely on absolute measurements of value, which are likely to be awfully subjective.

The best approach is probably to bite the bullet and develop many concepts in parallel in the early stages, and then cut back to a single project at the point where you dedicate significant staff to the project. The first phase is probably a single designer with a word processor spending a day on a few pages of design doc. The second phase is probably a week’s worth of expansion on that same design, a programmer spending a couple days taking a SWAG at what tech might be required (defining, not building), and a few days of a concept artist’s time to come up with some initial visuals. Not a big price to pay to be able to pick the cream of the crop.

How did the last game concept selection process you went through go? Were competing game ideas allowed to progress beyond the one-page-description level, or did you pretty much pick the next game idea in the initial brainstorming and run with it?