Archive for January, 2007

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?

Identicons

Identicons are so cool. (And so are Monster IDs)

There’s got to be a way to work these into our game. :)

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.

Ten Ways to Improve Developer Efficiency

As I see it, improving developer efficiency is the most important thing you can do to increase your game’s chance of being a success. Game development is a very iterative process, where each iteration results in a game that is better than it was in the previous iteration. Every second that you can pull out of the iteration time of each of the members of your team is going to buy you many additional iteration cycles over the course of the project and have a big impact.

Here are ten things you can do to improve productivity for your developers:

  1. Never, ever require anybody to wait for a build to see their changes working in-game – I can scarcely believe it when I hear it, but over and over I hear tales of artists and mission designers waiting for a build to test their new art or missions in the game. Even if your builds happen every day, this is still ridiculous. Iteration times should be measured in seconds or minutes, not hours or days.
  2. Drive as much of your game as you possibly can from data files – Data-driven development has plenty of its own virtues (not the least of which is that it helps a lot with number 1.) The biggest thing it does is remove the need to talk to a programmer when you need to make a change.
  3. Allow everyone in the company to run their own copy of the server cluster – This will vary in difficulty based on your server architecture, but it’s crucial. If there are any data files loaded by the server, (and your game is data-driven so of course there are) many people will need to be able to restart a cluster when they make a change. And as part of making it easy to bring up a new cluster for Random Artist A, you’ve also made the job easier for Random Operations Guy K.
  4. Use text files for your data files – Text files can be read by a human (or at least a human of the “programmer” sub-species.) They can also go into source control tools and show diffs. Depending on the format, they can probably also be merged in source control tools. Most game data (textures, meshes, and animations being huge exceptions) is small enough to begin with that the extra bloat from a text-based file format isn’t that big a deal. If you’re worried about the performance of text files, feel free to have a binary version that you compile from the text files as part of the build process.
  5. Run builds often – I was on the Middle-Earth project at Sierra for 9 months (up until it was cancelled) and I think we ran exactly two builds. On Rails Across America we ran builds once a week. On PotBS we run them (at least) once a day. If builds are running constantly, and build breakers are hassled appropriately, you can never get very far from having a playable game. At least not as long as you also do #6. When your build finishes, it should notify several people automatically and let them either fix it (if it failed) or start the manual part #6.
  6. Run Build Verification Tests daily – BVTs are intended to tell you if a given build is worth the electrons it’s written on. If you run them every day you will have a much greater chance to detect integration problems and build breakers as close to the source as possible and get them fixed just as quickly. There is likely to be some kind of human component to these tests, but much of them can be automated. We automatically test to make sure that every environment can be loaded, and every ship type can be created at the end of every official build. These tests fail in some significant way about once every three weeks and usually the fix is made and a new build is underway by noon the next day. (We run our builds at night, so nobody is around when the tests fail. Fixing the build is )
  7. Write unit tests religiously – I think the central tenet of Test Driven Development (that you should write your unit tests before the code and then run them to watch them fail) is a bunch of hooey. Testing your code with unit tests, however, is much faster in many cases than testing it by bringing up the server cluster and client and testing it in-system. And once you have them in the build you have a perfect way to test that your basic assumptions about the code aren’t being violated when you make future code changes.
  8. Review all checkins – Programmers will get the most benefit from this one, but other developers will also benefit. Thanks to #4 you have all your source data in text files, so a quick diff will show you what the developer changed. If the changes don’t look quite right the developer can fix it before it breaks the build. The reviewer is also granted some knowledge of the checkin so they are better able to fill in for the developer in a pinch. Everyone on the team should act as reviewer for other developers so that leads don’t become a bottleneck. This is also a great place to enforce coding standards and naming conventions.
  9. Keep your startup time as low as possible – Normally your whole-system optimization happens toward the end of the project. If you can spend some time optimizing startup times as you go, you will save many hours of developer’s time over the course of the project. Don’t forget to pay attention to the startup times in your tools and servers too. Chances are that developers will be launching those just as often as they launch the client.
  10. Prevent developers from having to restart – For programmers, this might mean using a scripting language and setting things up so you can reload scripts on the fly. If programmers can shut down pieces of the server cluster, recompile them, and then relaunch them without ever closing the client, they can get some benefit there too. For other developers, this means being able to re-read data and configuration files instead of requiring a restart of the client, server, or tool in order to see your change. Anything you can do to make this reload of data faster is a big help, possibly including doing it automatically by scanning file times.

These are all ways that you can improve developer efficiency (and therefore productivity.) There are only ten on this list, though, and I’m sure there are many others out there. What are some ways you have improved the efficiency of your teams?

Why can’t I play with my friends?

Brandon Reinhart recently posted an excellent article in support of splitting your game world up in to shards. He didn’t mention the biggest complaint I have about shards, so I thought I would.

Sharding fragments the player base

I know a lot of people who play World of Warcraft. Unfortunately they all play on many different shards:

  • The Classic Flying Lab WoW Gang – When WoW came out several of us started playing on Suramar. Two of those people are still playing there (and I have a level 23 druid there that I haven’t played in two years.)
  • My Colorado College Buddies – I’m not sure how many of these guys are playing, or which shard they’re actually on, but it’s not any of the other ones on this list.
  • A Couple of Us Flying Lab Programmers – I quit playing WoW after my free month the first time around. About four months ago I re-activated so I could give another class a shot. Some of the programmers were starting up on a new shard around the same time. I now have a level 35 Rogue on Twisted Nether.
  • The Current Flying Lab WoW Gang – About three months ago one of the mission designers made a big push to get people to start new WoW characters on the same shard. Unfortunately I was already 20 or so levels into my Rogue and didn’t feel like spending another month playing all those missions again. I might have used character transfer, but was growing attached to the folks I was playing with on Twisted Nether, so I didn’t. Because Twisted Nether is a PvP shard these new folks didn’t want to play over there and picked yet another shard.
  • Safe Haven – My old SWG guild plays WoW, and I would love to play with those guys again. Unfortunately they’re on Uther.

When you add them all up, that represents about 30 people I could be playing WoW with (or about 200 if you include Safe Haven.) As it is, I’m in a guild on Twisted Nether with about ten people in it, and nobody else I know is on the server. Even if the PvE vs. PvP distinction weren’t a problem there is basically no chance that I’m going to get 30 people to pay $25 to transfer their characters to the same shard. Suramar (and probably Uther) isn’t even an eligible destination for characters.

Best of Both Worlds?

Maybe the singleton and sharded approaches could be blended together to let me play with my friends and still allow the extra glory you get from a sharded world. What if server and character selection were independent choices? On login you would be presented with your entire character list and default to the same shard you used the last time you logged in, but could pick any shard you liked to play for the evening. Some game systems would be sharded and some would be singletons.
Singleton features include:

  • Direct chat (/tell, etc.)
  • Guilds (and guild chat)
  • Friend lists
  • Character database (including whatever uniqueness you enforce on names)

Sharded features include:

  • Grouping
  • RvR world state
  • Guild world state (guild halls, guild storehouses)
  • Player housing (and player economic presence)
  • Travel around the game world
  • Combat
  • NPC state

Additional technical and design challenges

This approach means building a singleton game and using instances for your game world. That’s easy enough to do for a buotique game, but any game with 100,000 or more subscribers is going to run into some serious problems.

Overcrowding

Even if your servers can handle any number of players standing in the same space, your client certainly can’t. When moving from shard to shard is trivial, you might be able to get away with hard concurrency caps on shards. You could also limit the number of shards that an account has access to at any given time and limit the number of accounts per shard.

Massive name collisions

Imagine if you were competing with for your character’s name with each of WoW’s 2 million accounts in North America. I have enough trouble getting a name through with one 200th of that on a shard. (Any why on earth do they have a random name generator that seems to only give you names that are already taken?)

I can see addressing this in a few ways:

  • Do nothing – Make it very hard to get a unique name and you’ll end up with a lot of non-unique names that are modified in silly ways like you do on AIM.
  • Don’t require uniqueness – Most IM packages have a login name that must be unique, but don’t require uniqueness on the screen names themselves. This means a billion characters named Gandalf or Raistlin, but you’re not going to run into most of them, so it doesn’t really matter. This approach introduces a host of new problems… it might be workable, though.
  • Require uniqueness on a smaller scale – Maybe you only have to be unique within your class and race. If you identify yourself to your real world friends as “Raistlin the Goblin Warlock” and the UI to add friends handles the dups gracefully, this would give you 30-40 namespaces in many games.

Loss of identity due to increased community size

This one is tough. A game that was laid out this way would, almost by definition, be one big community instead of several (or several hundred) smaller ones. There are a few things you can do to offset that, however:

  • Make switching shards something that most people do rarely – You could do this by hiding the button a few levels deep in the UI. You could probably even make the ability to play on any shard a bonus feature that a player would have to pay extra for.
  • If you track and display any stats for the game, show them per-shard – If you’re going publish the top ten MacGuffin collectors in the game, publish the top MacGuffin collector for each shard, and only count MacGuffins collected on that shard, regardless of how many shards that character has collected MacGuffins on.
  • Include an in-game cost to switch shards – Make switching shards cost the same amount a long in-world journey would cost to discourage low-level characters from moving and introduce a little friction.
  • Include in-game requirements before you can switch shards – Maybe you have to be level 10. Maybe you have to complete a certain quest with the character before you can switch.

Mega-guild dominance

If your guilds can have characters active on every shard, the biggest of them could conceivably dominate on EVERY shard. You could discourage this somewhat by requiring guilds to choose a “Home” shard and restricting some of their activities to just that shard. If guilds can only invite players who are in their guild hall and the guild hall only exists on one shard, it’s going to tend to keep their membership more localized.

Where are you? I’m right by the big statue!

All of the people on your friends list could be standing in exactly the same place and yet in completely different places. Including the shard name in the same places you show location would help this. So would color coding or otherwise tagging communication that is coming in from another shard.

Co-mingling of the game economies of the shards

So what? This just means you’ll have one big economy instead of a bunch of little ones, but it doesn’t really introduce any problems you weren’t already dealing with on the smaller scale.

Is it already going this way?

Guild Wars and EVE: Online are already singletons. City of Heroes has cross-shard (and cross character on the same shard) friend lists and direct chat. Many of the SOE games have “universal chat” which lets you send tells from one game to another or one shard to another in the same game. These are all steps toward singletons, albeit in a much more constrained way. Probably more importantly, Xbox Live lets you use one identity and set of stats in any game on the service. If the first of the Xbox MMOs is going to use Live, it may not have any choice but to adopt something like this.

Conclusion

I think that sharing the character database between shards is a promising solution to the big walls that sharding puts between my friends and I. I hope it is something we can try out with the next game (whatever that ends up being.) What do you think? Are you going to build your next game as singleton or sharded (or some freakish hybrid not intended by nature?) What major problem is this going to cause that I’m not anticipating?