January 31, 2007

p

Gaming in Australia

Filed under: Game Industry — Joe @ 10:39 pm

Gamasutra reports on a study on games from Australia:

The report, which was issued by the IEAA (Interactive Entertainment Association of Australia) game industry association, was based on data compiled by the Bond University Centre for New Media Research from surveys of about 1,606 households and 3,386 individuals. Of those individuals surveyed, 41 percent of the respondents were female (up from 38 percent), while 8 percent were seniors over 60 years old. The oldest gamer surveyed was 84 years old.

Lots of interesting charts and stats in the study itself. The Gamasutra article mostly just digests it.

p

Breaking rules

Filed under: Game Industry — Joe @ 10:27 pm

Kathy Sierra posted a short entry titled “Let them do the thing everyone else tells them not to”. Here’s the relevant bit:

This sign at the Royal Botanic Gardens in Syndey, Australia took me by surprise. So many signs tell us what we can’t do, and it’s delightful to see the opposite. We need more of this. And I love the, “Entry is free — but if you would like to help preserve this wonderful place…” How can you refuse?

It’s the shortest entry I’ve read on her site, but it did get me thinking. MMOs are chock full of rules about what you can and can’t do. The World of Warcraft terms of use, for instance, are 13 screens of text, most of which are the things you can’t do.

At least three games have gotten a lot of mileage out of actually encouraging behavior that was “bad” in other games. Shadowbane ran a major hype campaign around “play2crush” and “I don’t play games to bake bread.” All the major games at that point were restricting PvP to people who had flipped their flag either directly or by entering a PvP zone. This “PK all you want!” attitude appealed to lot of people who wanted to be free from all those restrictions. Serious technical problems prevented the game from holding on to them, but right after launch they had 80,000 subscribers because of all the hype.

The other example of a game that tells you to do what you can’t do in other games is EVE: Online. There may be NPC-driven consequences in some areas, but they let you blow up any ship at any time (or at least try.) Probably more significantly, however, is that CCP is not going to stop one player from scamming a bunch of others out of an estimated $170,000: (From Razorwire)

On Friday, September 1st, I got to attend a virtual press conference held by CCP so that they could clear up some mis-information about the recent EIB scam. On hand to discuss the situation was Magnus Bergsson, CMO for CCP. One of the things he wanted to make clear was that the 790 billion ISK figure may be an inflated estimate, and that due to attempts to “launder” the cash through several accounts, it may take time to track down an exact amount, if it’s even possible. He also wanted to reiterate that the EIB was not an official banking option that was controlled by CCP, the EIB was strictly a player-run enterprise. He then stated that the Development Team wants to ensure a freedom of playstyle for EVE, and even though CCP do not agree with cally’s actions, they see an importance that those actions are possible.

While it’s not clear that the hard-core “run your own Ponzi scheme” approach is getting them many fans, their ability to PvP anywhere is very popular. And unlike most games, they’re still growing after almost 4 years.

And PvP restrictions aren’t the only rule that’s broken by certain games. Second Life doesn’t have the “no sex in front of random passersby” restrictions that most games have. It doesn’t get nearly as much press, but from what I’ve heard Furcadia also allows adult-only content in certain parts of its world. Second Life is also taking their client open source. That pretty much blows the doors off the “don’t hack the client” restriction.

And of course lots of games have RMT these days, so the fact that it’s forbidden in others isn’t really something you can offer exclusive freedom from.

I wonder if there are other Terms of Service that a game could be broken as a selling point. The remaining ones in the WoW Terms of Use are:

  • No gray shards
  • No Denial of Service attacks
  • No copyright infringement
  • A bunch of naming restrictions (including “no leet speak”, which people break constantly)
  • No harassment
  • No spamming
  • No spoofing
  • No exploiting of exploits

Of those, gray shards seem to be the most promising. If you could come up with a way to allow anybody to host a world instance and set the rules in that world, but still keep collecting revenue from those players, you could probably draw a lot of attention.

Are there any other rules enforced by most MMOs that you think we could design a game without? What about rules that are enforced by the game itself rather than the Terms of Service? Do any of those need breaking?

p

The spam found me today

Filed under: Administrativia — Joe @ 9:21 pm

I put the site up on January 7, 2007. Through January 30 Akismet trapped two spam messages and one of those was a legit comment. Today it trapped 33 spam messages, all of which were spam. I guess the honeymoon is over.

January 28, 2007

p

Less Talking, More Doing

Filed under: Game Design — Joe @ 8:28 pm

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.

p

I’m Gregory Benford

Filed under: Off Topic — Joe @ 7:33 pm

But who isn’t?

I am:

Gregory Benford

A master literary stylist who is also a working scientist.


Which science fiction writer are you?

January 24, 2007

p

Game 1 as a Laboratory for Game 2?

Filed under: Game Design — Joe @ 9:25 pm

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?

January 23, 2007

p

Identicons

Filed under: Off Topic, Engineering — Joe @ 11:26 pm

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

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

January 21, 2007

p

Game guides are evil

Filed under: Game Design — Joe @ 6:06 pm

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.

January 17, 2007

p

Ten Ways to Improve Developer Efficiency

Filed under: Production — Joe @ 6:48 pm

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?

January 13, 2007

p

Why can’t I play with my friends?

Filed under: Game Design — Joe @ 2:19 pm

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?

Next Page »