Earlier this year Facebook announced their new Facebook Platform that allows developers to add applications that users can add to their profile and share with their friends. All these networks let you embed flash into your page, but in Facebook’s case applications can take advantage of all the features of the network itself: news feeds, friend lists, profile details, etc. And Facebook happily allows you to run advertising or charge the users of your application, so you can monetize your users. Developers have created 7782 applications as of this writing.

Not to be outdone, Google announce a new API last week that is sort of the open-standard equivalent to the Facebook Platform. It’s called Open Social and a bunch of non-Facebook social networks and application providers (including MySpace… remember them?) signed on to support it. Network effects work like crazy on this kind of site, so it remains to be seen if Open Social can boost these other social networks, but to the application providers it doesn’t really matter. As long as both APIs support some of the same basic functionality, a developer might as well port their app to both standards.

Of course games are a common application that people write for the Facebook platform. The application tagging on Facebook is pretty crappy, but “gaming” accounts for 879 of those applications. The most common games are trivia games (which seem to exist for every NFL team), games where you “attack” other players and get a news item with the results, simple arcade games with leaderboards, and turn-based board games. Many games give you benefits in the game for inviting people to play, which helps to spread the games through the network very quickly.

The one thing that all these games have in common is that they’re incredibly shallow. That lets people get into them easily but it also keeps them from being particularly sticky. I haven’t seen any metrics on the subject, but it seems like most people tire of any given game within a few days or weeks and remove it from their profiles. The Vampires/Zombies/Werewolves/Slayers game is incredibly popular with more than 900,000 daily active users total, but even more people have moved on from the game to other things. An October 28 article on Free to Play reported that Food Fight had 36k active daily users. It now has less than 23k.

The way people use Facebook puts some serious restrictions on the type of game that can be integrated with Facebook. While millions of people use Facebook every day they don’t spend a huge amount of time there each day. Games that require all players to be online at the same time have a serious disadvantage over games that work asynchronously. You might see FPS and RTS games on Facebook at some point, but they will never be as popular as “throw stuff at your friends” games simply because they have to be real-time to work.

One type of game seems to be entirely non-existent in the current crop of Facebook games: turn-base strategy games. There has always been a community of people playing these games flying under the radar. Back before the web these were called Play By Mail, and Flying Buffalo sold many of them. These days they are more likely to be web-based daily turn or action-point based games. These games are perfectly suited to a platform like Facebook:

1. They are asynchronous
2. You can play them in minutes a day
3. They are deep enough to retain players for months or years

The big question is whether or not someone can design a Play By Facebook game that is easy enough to get into to succeed. Most of the PBM and turn-based strategy games have been pretty intricate simulations of something or other and are generally not for the feint of heart. To succeed on Facebook a game needs to be something that a total novice can learn to play in minutes, because that’s all the time somebody’s friend is going to give the game before they move on to something else. Very few games can manage that while staying deep enough to keep players engaged long-term. There is an opportunity here for someone that can pull it off, though.

I started a kerfuffle on the subject of designers writing scripts. Since my original post was more about our experience with Lua than about scripting for designers I thought I would collect what I’ve already written in everyone else’s comment thread in one place.

Raph believes that designers should know how to write scripts. I agree completely. Games are more about algorithms than they are about art, sound, or databases, and knowing how to code at some level is going to help any system designer immensely. It will allow them to communicate with programmers more effectively, it will make their designs fit better within existing game or technical systems, and it will improve the quality of their designs overall.

Where I draw the line, however, is at actually shipping those designer-written scripts with the game. They are a fine prototyping mechanism, incredibly useful at creating gobs of data, and a brilliant simulation mechanism. Designer scripts are also often slower, more obtuse, and less maintainable than the equivalent script (or code) written by a professional programmer.

Does that mean I think designers have some mental deficiency that makes them write crappy code? Of course not. While there are some basic concepts of programming that require a certain talent to grok (pointers, branches, order of algorithms) by and large most scripting designers have that talent. What they lack is the experience required to write code that you can keep running for years on end. Programmers spend all day, every day on the subject of how to quickly write maintainable code that runs well. For designers, it’s at best a sideline. We put our programmers though a hard-core technical interview to try to determine if we want to put up with their code. Any designer who can pass that interview is welcome to write production code in my book.

A much better approach is to provide a rich mechanism for driving game logic with data and give designers reasonable tools to manipulate that data. That doesn’t mean designers are reduced to inputting tables of numbers. The data-driven systems we use in Pirates allow designers to add entire new game systems by combining existing building blocks. We also work closely with the designers to implement new blocks for them on a regular basis.

Damion mentioned that schedule constraints often lead to programmers changing their tune when it comes to designers writing scripts. Tight schedules are why we integrated Lua in the first place. I thought it would let us take advantage of the people in the office who were less overloaded to write some of the game. My current position on designer scripting is a direct result of that Lua integration.

One thing I discounted in the “let’s get some designers to write some scripts” approach was how valuable the designer’s time is. In most cases it’s easier to build a new system using our data-driven system than it would have been to implement the same system in Lua. When using data isn’t easier, a day or two of a programmer’s time can usually make it so. Our system design team is even more critically understaffed than our programming team, and by using data instead of code we can save them time.

Just about everyone has said, “It depends on your situation.” It certainly does. If you have a team of 5 and your lead designer is also your junior programmer, you would probably be well served to have that designer writing production code. In a more general case with more specialization among your staff, it’s a bad idea to plan on all your design hires having that level of programming ability. And if you reject all designers who don’t meet some minimum programming skill level you may find it hard to hire designers.

All in all, the Great Designer Script Debate of ‘07 has been great. It’s nice to take a break from whining about how many users Second Life doesn’t have or how raid content in WoW is the best/worst thing to ever happen to MMOs. Who’s going to kick off the next kerfuffle?

Watch this first.

So let me get this straight.  This is a game (or mocked up video of a game) that encourages its players to run around an actual city while staring at a little 4 inch handheld screen.  Even better, there are virtual dangers in the game, so if you don’t watch the screen at all times you might get squashed by a boulder.  To me, that sounds like a great way to get players run over by actual dangers like cars and buses.

Of course being able to run around the city and play such a game would be sweet.  It would give me a chance to get some exercise I might enjoy, instead of enduring boring workouts just because they’re good for me. Outside of “footrace to the castle” games there are even lots of opportunities for social interaction with such a device.

I wonder how the games would be be mapped onto different cities.  I suspect Seattle wouldn’t be too far down the list, but does that mean I couldn’t play at all when I’m visiting my family in small-town Colorado? Obviously the “actual actress shows up and smooches you” mechanic is never going to happen in the real world, but it looked like the game world was being mapped over very specific buildings, which wouldn’t exist in another city, let alone in a small town.  Maybe the software has to be smart enough to look your location up in satellite images and pick some nearby buildings as the key points in the game.  The client in your handheld them could then “fancify” whatever its camera sees without developer involvement.

In any case, it’s all very cool, and I look forward to a time when this kind of thing isn’t just vaporware.

9:30am Thursday - Fostering Open-Ended Play: Unleashing the Creative Community

Sulka Haro - Sulake

Sulka is the lead design behind Habbo Hotel, a casual non-game world popular among teens 13-16 all over the world. They get 11 million unique visitors per month and collect money with virtual item sales. By some measures (those that don’t involve revenue, but do involve users) they are “bigger than WoW.” That was a big theme at the conference. Everyone was talking about things that were bigger than WoW or as big as WoW, or whatever.

This keynote was excellent. Sulka talked about how Habbo Hotel came about and their experience expanding the game to add new hotels all over the world. He talked about the many features of Habbo Hotel; this is one seriously complex game. And, of course he talked a lot about the environments and forms of play that the users put together on their own. For someone, like me, who didn’t know anything about Habbo Hotel, this was a very educational talk.

11:00am Thursday - Web Client Development Issues - Best Practices

Michael Bayne - Three Rings
Michael Grundvig - ElectroTank

Three Rings is doing web development with their new game, Whirled. ElectroTank makes flash games and middleware. These two talked about the pitfalls of Flash, Java, and AJAX development for games that run in the browser. It was a pretty technical, but had a bunch of helpful tips on this sort of development.

1:30 Thursday - The Zen of Online Game Design

Damion Schubert - Bioware

Another talk that it’s worth buying the audio to. The slides are here, and Raph was live-blogging it. Lunch was a big rush to get to this one early so I could actually get in the door.

4:30pm Thursday - Startup Lessons from Recent Online Games

Raph Koster - Areae
Anthony Castoro - Heatwave Interactive
Joe Ybarra - Cheyenne Mountain Entertainment
Nabeel Hyatt - Conduit Labs
Daniel James - Three Things (Moderator)

This panel covered a wide variety of startup issues. To me the most interesting was funding: Each panelist had their own approach. Cheyenne Mountain is entirely funded by angel investors. They have more than a hundred of them. Heatwave is funded by a publisher in the traditional game studio route. In Areae’s case, Raph was approached with offers of funding from the day he announced he was leaving Sony and eventually settled on two different VCs to share the first round. Conduit is also VC funded and secured $5.5 million in funding over 6 weeks. Three Rings was self funded/bootstrapped, and launched Puzzle Pirates on relatively little funding, at least compared to the other panelists.

Gamasutra has a fairly complete writeup of the entire panel.

Sara discovered our secret competitive advantage. Starting a few months ago we’ve been running usability tests to try to smooth out as many rough edges in the game as possible before launch. Even though our testing is extremely low budget, we have been getting fantastic feedback on the game. The usability person we hired came on board after the first round of tests and has introduced a more scientific process to the testing. That has definately increased the value of the tests.
If you don’t have access to an expert of your own, you can still do this kind of testing. The basic approach this:

1. Invite some local gamers to the office
2. Order some pizza
3. Let them loose on the game
4. Observe

We have an FLSer with a notepad watch what they’re doing, prompt them to describe what they’re doing, and take notes on what they say and do. That’s it. No fancy cameras and no real science, but plenty of gigantic pointers at things to fix in the game. The usability person we hired has been helping out with those test, and we’re bringing her aboard to increase the pace of testing. The lab itself is just a dedicated space to do more or less the same level of testing.

I’m sure that spending tons of money on equipment and a bunch of trained professionals to use it would get us better results. Maybe those results would be twice as good, even. The cost would probably be ten times what we’re paying for our simple tests with a single trained professional. If we had all the money in the world, it would be something to look at, but for now the pizza testing is working just fine.

I wish we had started doing this years ago. There’s nothing like observing a real user to tell you where your UI sucks.

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?