T=Machine

Yahoo recently posted a page listing and describing eight different design patterns for a reputation (or ranking, or achievement) system for a community - where community could be a web community, the players of a particular game, etc. For a long time now, I’ve been meaning to write a post on this stuff, and this finally poked me to do it…

EDIT: It’s Bryce, not Bruce. Argh. Sorry, Bryce - I was thinking about Bruce Schneier at the time, I think.

(thanks to Jeremy Liew for posting about an interview with the guy behind it, Yahoo’s Bruce Glass, which looks at some of the thinking behind it and his own views on what to do and what not to do)

Reputation systems - why?

For most game developers - and moreso most game publishers - the answer is “look at XBLA” (Microsoft’s Xbox Live Arcade). In the past 2 years, MS has put out a series of press releases and marketing pimping up the large amounts of money that they - and the publishers - have been making off the additional sales generated by this simple achievements/reputation system.

(I think that’s great, but also a bit sad, because XBLA does some other equally special stuff that hasn’t had quite so much explicit attention. Who’s talking about the GamerCard, and what *that* means for online communities? Plenty of people have, but it’s not achieved quite the same amount of attention. I think a lot of people have dismissed it as a gimmick in comparison to the reputation system - which is foolish of them, because the GC provides an excellent way for players to spread their Online Identity, and identity is a much bigger pie to be taking slices of than reptuation systems ever will be. But it’s harder to work with, and I’ll come back to that in another post sometime in the future.)

Or, as Joshua Porter puts it in the Bruce Glass interview:

“Reputation systems have driven the entire business at eBay.com, much of the business at Amazon.com, drives activity at Digg.com, powers the moderation system at Slashdot, etc…and yet for all the millions of words written about web design very few of them have been dedicated to this type of software.”

Choosing a rewards system

As an online game and MMO developer, and someone who focusses on social gaming and how to integrate it with mainstream games design, I’d say that the answer to “which form of reputation system for your social game?” is simply and clearly “all of them”. And at first I thought that was just me.

I’ve worked on games that have had a heavy social/web element, and adding additional parallel rewards/reputation systems has only ever helped both the community and the game. Nowadays, everything I see reinforces this, at least for games.

For instance, easy example - look at Kongregate. Kong has 5 independent, parallel rating systems for each game, and 7 (!) reputation systems for each user/player/developer on the site.

Looking at how those interact with each other, I would argue that a lot of the site’s success is precisely because it has these multiple *independent* forms of valuing user content; it allows you as a member of the community to say “this is nothing special in many ways, but in one aspect it’s the best thing I’ve ever seen” - essentially allowing for a multi-dimensional measure of “goodness”.

So, although I understand and by default agree with Y!’s suggestion that you should look at your community, assess your target market and your product aims, and pick one reputation system, I feel that you really shouldn’t do that with games.

Why one is never enough

Because only having one:

• Limits self-expression: you CHOOSE to invest of yourself in various ways in a community. Bruce Glass mentions this. He doesn’t mention the knock-on implication: what you choose to invest says something about who you are and how you wish to be perceived. So, this is a part of your personal online identity.you can only be good at one thing, not a set of things, and there’s no way to show
• Reduces learning opportunities: with multiple rep systems, a community can let a member know that “we think you are really awful at some things, but really good at others. Please do less of the bad stuff”, instead of just “we don’t value you”
• Prevents the majority of people from being recognized: Go read about the Bartle types. Then read Erik Bethke’s presentations on what happened when he thought that some of them “didn’t apply” to his own MMO, GoPets, and what happened when he changed his mind on that. There is no MMO without all four player-types represented. One rep system can only satisfy one quarter of the traits that are present in all your audience. It may be the largest represented quarter, but it’s still artificially limiting your appeal as a game/product/experience/community
• Assumes you actually know - and can control - what your community is, what it will become, and how it will grow to get there. That’s usually not the case. It seems (at least in MMO and online games) that good community management these days is not directive, it’s reactive. That’s not an excuse to abrogate responsibility for encouraging and supporting your community, it’s just saying that you need to give them more opportunity to tell you what they want, so that you can then modify your offering. And they will change what they want, they don’t remain static

And after saying all that, I wonder: how much of this is games-centric? Because although I’m no expert on online communities in general, that sounds pretty applicable to a wider set of online properties - not all, I’m sure, but many more than just “games”.

Which leads me to wonder whether the suggestion itself (that you should carefully choose just one) is a nice idea in theory, but perhaps not appropriate in the modern web world: perhaps communities now are sufficiently savvy, picky, and accustomed to being the ones to control success (e.g. youtube, where the community makes a video successful, not the site owners), that single-value measures of reputation are no longer what your community wants and needs.

Maybe?

And as for Kongregate … well, now I’m going to finally write up the post I’ve been meaning to for a long time about that.

Filed under : computer games, games design, massively multiplayer, web 2.0
1 Comment »

Or so this blog on security says.

“Some experts claim that two-factor authentication won’t work. They are wrong, of course.”

The expert linked to is Bruce Schneier, and the main attack he points out that isn’t affected by TFS is … fake website asking for your credentials.

Funny. That was one of the main ways of stealing people’s MMO player accounts when I first got into MMO dev around ten years ago. And it’s still one of the main ways now (although there are plenty of other good ones, as noted in the linked post). It’s just … so easy!

Which would suggest that yes, actually, Bruce is right: TFS is going to do little to combat the *actual problems* being faced here.

Personally, I’ve always been on the side of security is pretty simple really: prevention is impossible, and anything that claims to provide great prevention is snake oil, and the reason security in practice is hard is because you have to find ways to deal with detection and response, and *that’s* where all the interesting stuff is.

On the other hand, I’ve now heard a couple of people suggest that the one-time-passwords thing from Blizzard isn’t about the passwords anyway: it’s about reducing credit-card chargebacks by shipping goods to the actual address first. In a way, it’s a basic form of TFS on the act of issuing a CC charge: you have to know the CC details and be able to intercept snailmail post, and until you succeed at both, the company doesn’t need to issue the CC charge.

Again … prevention? Nah, I can still intercept post, even on a large scale. But … detecting that interception is going to be somewhat easier, and responding to it (getting people fired from FedEx, or whichever company has been infiltrated and/or has a dodgy employee that’s been fired) is probably a lot easier than dealing with an unknown anonymous person from “somewhere” on the planet who bought 10,000 CC’s on the black market.

So, props to Blizzard. But not for making “a better form of password”. And a thumbs-down to Errata Security: sorry, but I’m not convinced by your analysis. I see what you’re saying, but I suspect you’re barking up the wrong tree. And I’m afraid I’m always suspicious of people who defend any preventative measure too closely - security doesn’t seem to work like that, sadly.

Filed under : computer games, games industry, massively multiplayer, networking, security

1 Comment »

I just heard this talk at the MMOGfest academic mini-conference last week - apparently, it’s mostly the same as the talk he gave at the independent MMO conference earlier this year, but I think a lot of people didn’t manage to go to that one, so it seems worth reporting here.

Like all the other conference-talk writeups, any errors and ommissions are my fault, and my personal comments appear in square brackets throughout.

Summary

As noted in his Guardian article, “We’ve won”: games are here to stay. In the MMO space - despite all the threats and challenges - it looks like MMOs will continue to innovate and expand, and become better and better. A good, upbeat, keynote talk.
(more…)

Filed under : computer games, conferences, games design, games industry, massively multiplayer

5 Comments »

I’m seriously fed up with the mediocrity (you could use worse words; I’m being civil here) of most MMO publishers’ patching systems for MMOs. The very least you should expect as a player, even back in 2001, should have been something akin to the PS3 / 360 patching systems today: the most basic “fire and forget” - you try to play the game, it does a background download, then popsup to tell you when to click to finish the install. That’s *it*. No more.

So, how should it be? Well…
(more…)

Filed under : bitching, computer games, games design, massively multiplayer, web 2.0

4 Comments »

We were talking about backups recently, and I remembered one of the things we did at MindCandy to great success that I now consider essential to any online game which has a live database: use your live backup as the input for all your development machines.

NB: this is all about backing up LIVE SERVERS, not backing up your development machines - if you can’t make your development backups work perfectly then you have serious problems and need to get some better IT personnel. I’m not covering that issue at all: that’s just standard to any technology company!
(more…)

Filed under : agile, dev-process, massively multiplayer

2 Comments »

Edward Hunter, comScore

Summary

Some useful stats, and some interesting issues raised in terms of privacy and practicalities of gathering stats.

A lot of good advice on how to select a target market for an online game that’s better than “any hardcore RPG players” - both better as in more precise and usable, and also better as in bigger and worth more money.

LOTS of questions afterwards; read to the bottom to see them all.
(more…)

Filed under : ION 2008, computer games, conferences, databases, games industry, massively multiplayer, web 2.0

3 Comments »

With some Wordpress-Fu, I’ve added a page that’s a category and auto-includes links with custom meta-information.

Or, in other words, there’s now a page where I can effortlessly post all my various bookmarked links to do with MMO development - and add my own commentary to each link - which you can’t ordinarily do. Which is why it’s taken me some time to get around to it (previous efforts to do this without customizing WordPress, or using plugins only, failed).

The (practically empty) page in all it’s (non-)glory can be found here:

http://t-machine.org/index.php/category/mmog-dev/

Over the coming weeks, I’ll be posting much more stuff to it. I hope.

Filed under : computer games, massively multiplayer, mmog links, networking, programming, system architecture

0 Comment »

…according to Ed Castranova’s snippet that Scott J posted from the MDY vs Blizzard trial notes.

Courtesy of Scott, here’s a hosted copy of the source documents.

Ed writes a nice little explanation of why / how bots damage an in-game economy. I liked that. Good stuff - go read it. So far, so good - a great primer for anyone wanting to understand the situation better.

Unfortunately, the implication throughout the document is that this is all directly damaging to Blizzard’s revenue, and should be prevented *by someone other than Blizzard*.

I think this is a really stupid way of looking at things. My impression from reading the submission was that it’s overall a somewhat twisted description of the situation, coloured by a desire to use the facts (economic analysis) to support a personal desire (stop people using bots rather than go to the effort of fixing the bugs in the game-design). Sure, capitalist companies will pursue the cheapest possible means to achieve their goals, including suing people if they think they’ll succeed, but I deeply object to this kind of good factual analysis being spun to imply it proves stuff that it does not prove, and which consists an attempt to dodge responsibility and use the legal system to make up for mistakes in a company’s product-development strategy. Make better games, don’t blame the players for not playing the way they were “meant” to. Even the ones who are cheating. Ban them for cheating, stop them however you can, but don’t claim it’s not your fault that they’ve managed to cheat in the first place: of course it’s your fault.

Picking the snippet Scott quoted, which is nicely indicative of the whole piece:

Glider bots destroy this design, distorting the economy for the average player in two specific ways. When a Glider bot “farms” an area, it picks up not only experience points for its owner, discussed above, but also the “loot” that is dropped by the mobs killed by the bot. Because Glider can run constantly, it kills far more mobs than anticipated by WoW’s designers, thus creating a large surplus of goods and currency, flooding the economy with gold pieces and loot like the Essence of Water. This surplus distorts the economy in a specific way.

When bots gather key resources, they gather them in abundance. Owners of bots usually sell these resources to other players for gold, which inevitably deflates their price. Blizzard’s design intent is for the resources to command a certain high value, so that average players, who might get one or two of the resources in an average amount of play time, may obtain a decent amount of gold from selling them. But because characters controlled by bots flood the market with those resources, the market value of these resources is far less than Blizzard intended, and the average player realizes only a fraction of the intended value from the resources s/he finds. The deflated value of key resources presents a critical problem for ordinary players trying to enjoy the game. Blizzard’s game systems assume that players will be earning a certain amount of gold per hour, and many systems, such as repairs and travel, force players to make fixed payments of gold into WoW’s systems. Buying a horse, for example, costs a certain amount of gold. That pnce IS set by the game designers based on the assumption that normal players will accumulate gold at a certain rate, and that some of their gold will come from the value of resources that they harvest and sell. When the value of those resources plummets because of Glider, the amount of time it takes to accumulate the gold required for in-game expenditures like the horse skyrockets. This skews the economy, frustrates players, and, as a result of a less-satisfied user base, damages Blizzard.

My interpretation of the above argument:

1. Designer makes various tables of numbers showing relationship between prices, rarity, the difficulty of achieving items at a given level, etc. This is normal - people who do this are often called “balance” game-designers, because they’re balancing out the risk/reward, cost/effect of everything
2. Developers hard code these values, on the assumption that the world is perfect, they are God, and nothing could ever go wrong (this is fine; normally you make that kind of mistake once, and then fix it when you realise the problems this is going to cause)
3. System collapses because of “bad people”
4. When caught in such situations, Developers get to blame everyone except themselves, even though it’s clearly their own shoddy game design / implementation

The analysis is economically accurate, but the conclusions about the impact on design, and whose responsibility it is to contain/prevent/undo this, is just making out game developers to be lazy, stupid, bullies. People should take responsibility for their mistakes, not blame everyone else. Especially not blame the users of a game. Even if they hack your game to pieces and cheat like crazy THAT’S STILL YOUR FAULT AS A GAME DEVELOPER. You may hate them, rightly so, but it’s your responsibility to make better games. At least, that’s how we used to make games. Maybe the industry doesn’t work that way any more. Maybe it’s just me that thinks that way, maybe to everyone else in the industry a “bad game” isn’t your fault as a developer, it’s the players’ fault for not being clever enough to appreciate the coolness of your game.

Look at Diablo - it fell to pieces and died because of in-memory live hacking of the game-data. Seriously hardcore stuff (in a way). But that didn’t mean everyone just shrugged and said “those nasty hackers, they ruined a perfect game, it’s not the developers faut”, instead we took it to mean they hadn’t built it well enough, that next time they would have to change their approach, or their priorities, to prevent this from happening again.

To pick one more quote that underlines how silly I think this piece is because of the spin being put on it:

Glider bots occupy resources that Blizzard could otherwise put to other, more constructive uses. Because those resources are required to fight Glider, they are spent in a way that does not improve the game

Well, duh. And the same is true of most of the work being done by the Customer Service depts that all of the MMO companies pay large amounts of money to in salary every day. And it’s also true of the hardware that we use to run the game. Etc, etc. Just because a development cost “does not improve the game” doesn’t mean you have grounds to go and sue someone else for causing you to have to do it.

Where does it stop, if you go down that route? Are we going to start suing players who ask questions of the CS team that are too stupid? Will we bill players with crappy graphics cards for our time that was wasted diagnosing problems with their hardware that were stopping them from playing our games?

Which is not to say that I support botting or bot applications. I don’t support either. And I believe there are many different ways you can fight them, and there are many good reasons for shutting down people and organizations that use them. But I don’t think the reasons given above are included. And I don’t want to sink to the level of making specious arguments just because it’s the path of least effort…

Filed under : computer games, games design, massively multiplayer, security

4 Comments »

Massively Multiplayer Entity Systems: Introduction

So, what’s the connection between ES and MMO, that I’ve so tantalisingly been dangling in the title of the last three posts? (start here if you haven’t read them yet).

The short answer is: it’s all about data. And data is a lot harder than most people think, whenever you have to deal with an entire system (like an MMO) instead of just one consumer of a system (like the game-client, which is the only part of an MMO that traditional games have).

Obviously, we need to look at it in a lot more detail than that. First, some background…
(more…)

Filed under : computer games, databases, games design, massively multiplayer, programming, system architecture

8 Comments »

Summary

Speakers: Daniel James, Three Rings; Matt Mihaly, Iron Realms Entertainment

Very brief notes…

(more…)

Filed under : GDC 2008, computer games, conferences, games design, massively multiplayer

0 Comment »