April 20, 2005
Sony Slides to the Bottom of the Slippery Slope
Last October in my KidTrade paper, I asserted that eBay virtual goods markets are the direct result of design choices that have important (and potentially harmful) side-effects. Not all virtual economies need follow the same path. But some companies continue on boldly… In part, I wrote:
From Twinking to EBay:
The MMOG Virtual Economy Design “Slippery Slope”
- Gifting → Twinking
- Gifting + Multiple Chars/Server → Muling
- Gifting + Messaging + Trust → Trading
- Trading – Messaging – Trust + In World Machinery → Robust Trading
- Robust Trading + Scarcity + Liquidity → External Market (eBay)
- External Market – Trust + In World Machinery → GOM
It seems that Sony has embraced this inevitability and has announced that Everquest II will take the final step on the slippery slope and create an online market for users to exchange real-world money ($$$) with virtual goods, within the game.
I guess that’s one way to handle an economic design that leads to farming – rather than fix it, ‘legitimize’ it. :-P Honestly, a system that has a market like this should be designed from the ground-up to mitigate abuse and manage production rates. This feels so much like:
Ready…
Shoot!
Aim…
I can’t wait to see the TOS for using that market – this is a very risky play.
[Discussion pointer: TerraNova]
April 5, 2005
Stretching the Lessons
A response to Marc Hedlund’s Reading Yahoo! 360° through “The Lessons of Lucasfilm’s Habitat”
First, I must say that I’m personally flattered that Marc Hedlund and Clay Shirky think that The Lessons of Lucasfilm’s Habitat is “fantastic” and “Best. Essay. EVAR.” I’ve never been called a hero before. :-) Frankly, the paper is showing its age, so I was quite surprised that Marc chose it to frame his thoughtful and lengthy critique of the Yahoo! 360° service. You see, in the spring of last year, Chip and I started this blog: Habitat Chronicles in part to archive and transcribe the “Habitat Redux” (ppt) presentation, where we take our original paper to task and talk about the new lessons learned since then. Chip and I haven’t transcribed everything yet, so that Marc may have missed some of the hindsight, reinterpretations, corrections, and retractions is understandable.
Despite our best efforts at clear communications, The Lessons of Lucasfilm’s Habitat has become a bit of a social software Rorschach Test: In it, people see some wisdom that was not intended, or was quite accidental. Marc’s critique does suffer a bit from this effect and in a few places even acknowledges it, but he goes further as he re-interprets several of the lessons.
I welcome all thoughtful critiques of my work (new, and old), and think that several of Marc’s prescriptions are correct for Yahoo! 360°. But, since his critique used The Lessons as framework in ways that I find personally challenging, this seems like the right place respond.
Identifying the Customer
Marc says:
… Yahoo! Mail or MSN Passport is a bad idea, since the service’s goals will diverge from yours over time … an email address in your own domain will serve you better than one @yahoo.com. Great stuff, especially now that domain name registration is effectively free.
This statement typifies an attitude that separates us digirati from the rest of the world.
My mother [sister/nephew/etc.] can barely manage her web-based email. How on earth would she manage her own domains, servers, and what would motivate her to cough up the additional money to pay for these services? I run a server farm from my garage but can’t get AOL to accept a connection from my mail server. Likewise, pobox.com bounces all mail from my machine as coming from a dynamic domain. I get spam from people trying to trick me into using their domain registry with deceptive mailers that look like bills. Why was my own email domain good idea again? There is a definite cost/benefit trade-off calculation here.
It seems presumptuous to tell everyone that the free web-based email provider that they use is not good enough – that they should pay for so called ‘effectively free’ services that are significantly more expensive and complex – when all they want to do is send baby pictures to their relatives. The presumption that you understand other people’s cost/benefit calculus better than they do was at the heart of the final and most important of the Lessons: Get real. For millions of people, web mail is plenty good enough.
Stretching The Lessons
How better, then, to look at Yahoo! 360°, than to take these lessons learned nearly two decades ago, and apply them to the brave new project? Yes, let us arrange the deck chairs to spell Habitat, and see how they feel.
- A multi-user environment is central to the idea of cyberspace.
On the surface, Yahoo! 360° seems to have learned this in kindergarten. But the world is different than it was then, and there is not one Habitat, but many. It connects you to your friends with Yahoo accounts, and not to any other friends you might have…
We’d like to believe that eventually we’d be able to share with any friend the same way we can email with any friend, but look at Yahoo Messenger and its competitors, and that’s not the future you’ll see.
Yahoo! 360° is built fundamentally on the idea of sharing – what is more multi-user centric than that?
During Marc’s visit to preview the project, the development team shared that more integration with non-Yahoo! services was consistent with the goals of Yahoo! 360° and already on the product roadmap. Look at the recent release of web service APIs, deep support of RSS over all its services, acquisition of Flickr, and initial availability of RSS feeds on public blogs for evidence of this commitment. It is not a matter will or understanding that it needs more integration. It is only a matter having the resources and time to implement.
- Communications bandwidth is a scarce resource.
Lessons talks literally about modem speed when it talks about bandwidth, but it also talks about attention bandwidth…Today, the problem with attention bandwidth is the number of applications that want my daily attention…RSS comes out of 360 only through blog postings, one feed at a time (no “show me blog posts by all of my friends,” as Flickr would have it); other system messages aren’t available at all without logging in…
The original lesson doesn’t mention attention at all, but I’ll take the bait anyway :-).
Yahoo! 360° is designed with the idea of reducing to one the number of places you have to go to get the latest photos, blog entries, reviews, favorite songs, group postings, messages, etc. That it currently fails for his case is a concern, but already there are customers that are telling us that we have significantly reduced the number of separate sites that they have to ‘hand out’ to their friends and family.
- An object-oriented data representation is essential…
…360 represents data in HTML only; no access allowed unless you’re logged in through a browser…[The Lessons] hint at a web services API. My usage of my data might be arbitrarily elaborate; allow me to communicate with the service at a behavioral level rather than through your presentation…
Stretching this lesson to talk about web services APIs is probably appropriate, but not exactly the original context. I still believe that online services should offer object-level semantic interfaces, where it makes sense. And it makes sense for Yahoo! 360°.
Yahoo! 360° will have more feeds and APIs as soon as we can get them working. I can’t think of a service this comprehensive that had full web services APIs on their first day of Beta. Even Flickr took the better part of a year.
- Detailed central planning is impossible; don’t even try.
Relationships between people in 360 — the social networking part — are bi-directional, as with Friendster and Orkut…
Sharing and the free flow of communication are not built around awkward social questions. Let me browse around, see what there is to see, and choose the things I like enough to want to see more. Let me send out my ideas and my pictures and whatever else to people who haven’t joined and haven’t linked to me, and may never…
The original lesson was a call to let the users create their own content, instead of depending on a single content creator (aka the bottleneck) to meter out the experience in a linear form. As originally written, Yahoo! 360° exemplifies this goal: There is only user-generated content.
As to the critique of bidirectional links: there is much debate on this topic – there are some things (such as permissions management, gathering recommendations by degree, etc.) that are simplified for users by establishing these kinds of relationships. Though no one in my family, nor any of my strong ties, has any problems with this connection structure, the desire to observe other’s public activity anonymously is a valid request and is currently enabled for public blogs via RSS feeds. The product team is considering other one-way connection schemes as well.
- You can’t trust anyone.
A central point of 360 is its controls for permissions and… the privacy interface creates an expectation that it will actually do something to protect my privacy… The idea that a site like Yahoo can give me actual control over the distribution of my ideas and photos with a popup menu is absurd on its face; if the idea is sharing, then sharing will find a way. You can’t trust anyone but the promise of the site is that you can.
The original lesson explicitly limits its scope to client-server interactions, like an API. It is a software security lesson, not a distribution of information lesson.
As to the claim that Yahoo! 360° protecting your information is “absurd on its face”, I beg to differ and propose a challenge to prove my point: Marc – Please send me a copy of pictures of the gift my daughter made last Christmas for a friend. They are available through Yahoo! 360° and Yahoo! Photos and are protected only by “popup menu” settings. You do not know who has permissions, and even if you can guess, they don’t trust you.
Do Linux file permissions (set from an even more primitive command-line interface) mean that those files aren’t protected? Come on.
Marc closes with…
What 360 gets right is that it isn’t about anything in particular; it’s a blank piece of paper with some wrinkles and lines. What users do with it, even in its closed-garden, api-less, feed-free incarnation, is their own choice, and they may well find a way to make the tool better than its designers originally intended.
This is no accident. Yahoo! 360° did learn Lessons from Habitat (and hundreds of other projects, papers, and products). What we didn’t do was get every feature/integration we wanted working before we put it out into the market.
But, the proof is in the pudding – watch the way Yahoo! 360° evolves and see for yourself.
F. Randall Farmer
March 29, 2005
Yahoo! 360 Invitation Only Beta
Yahoo! 360° has entered an invite-only beta and you can read my description of what makes it special on the Yahoo! Searchblog.
I’ve already sent out a few invititations, but I’m sure I’ve missed a few of my friends out there who are interested. I’ve got a limited number of invitations, so I’m distributing them only to folks I actually know (in person) and/or are related to. That means you have my email already – just drop me a line.
[I’m wondering if/when the invites will show up for sale on eBay…]
Into the breach!
Randy
March 20, 2005
Another Reason Randy Has Been Busy
I’m been championing Yahoo’s just announced aquisition of Flickr.
Flickr + 360?
Flickr + Search?
Flickr + Groups?
Use your imagination…
Things are getting a lot more interesting for communities at Yahoo.
March 15, 2005
Announcing Yahoo! 360°
Since we are both too busy to keep this blog up-to-date, I figured I’d share what it is that I’m doing that would keep so occupied that I can’t keep up with the much needed ranting about virtual worlds, avatars, secondary markets, security and the like…
Announcing: Yahoo! 360°
Press Release
As it hit the wires in the wee hours of 3/16/05:
WSJ:Yahoo Plans Service to Let Users Create Blogs and Share Content
Charlene Li: (Forrester) Yahoo! announces blogging and social networking betas
AP:Yahoo Tests Blend of Blogging, Networking
Early bloggers are intrigued:
Marc Canter
Micro Persuasion (Steve Rubel)
SearchEngineJournal (Greg Sterling)
and hundreds more.
The invitations start at the end of the month…
November 24, 2004
Thanksgiving Lasagna
For reasons which entirely elude me, it has become the tradition in our household for me to cook a lasagna for our Thanksgiving dinner. I think it may have something to do with giving my wife an excuse to make me cook, but in any event I make a pretty good lasagna.
The recipe I use is one of those recipes that has been passed from friend to friend over the years, mutating ever so slightly at each step. My contribution to this process came about 25 years ago when I was first learning to cook for real. My wife (then girlfriend) was teaching me, but I tried to lean on her assistance as little as possible, mainly because I tend to favor the Jump Straight Into The Deep End school when it comes to learning new things. This recipe seem pretty straightforward and self-explanatory, so I didn’t ask for a lot of advice. However, being a novice, I was unclear on the distinction between a clove of garlic and a bulb of garlic. The recipe called for a clove, but I chopped up a whole bulb’s worth and put it in. Janice, who insisted, despite my whining, on periodically checking my work in progress, tasted the simmering meat sauce and pronounced that it was pretty good but that it needed more garlic. I protested, and insisted that I had already put in an entire clove, holding up a garlic bulb as illustration. It was at this point that the magnitude of my error became clear. We learned three important things that day which helped draw our growing relationship even closer: (1) she really likes garlic, (2) I really like garlic, and (3) you know, it’s really pretty hard to have too much garlic, isn’t it?
Chip’s Lasagna
Meat sauce:
3 lbs. ground chuck (can substitute ground turkey for cheapness or leanness)
1 large bulb fresh garlic, minced
1+ tsp. Italian seasoning
1+ tsp. oregano
1 29oz. can or 2 15oz. cans tomato sauce
2 6oz. cans tomato paste
Brown meat slowly. Spoon off fat. Add other ingredients. Simmer at least 1/2 hr. uncovered (longer is better).
Cook 8oz. lasagna noodles as directed on package (rinse in cold water)
Cheese filling:
~2 cups Ricotta cheese (1 lb. carton should suffice)
1/2 cup grated Parmesan or Romano cheese
2 tbs. parsley flakes
2 beaten eggs
1/2 tsp. pepper
Mix.
Slice 1 lb. mozzarella very thin
Put 1/2 of noodles in 13″x9″x2″ pan.
Spread with 1/2 of cheese filling.
Cover with 1/2 of mozzarella and 1/2 of meat sauce.
Repeat layers.
Bake at 325 degrees for 45 minutes.
Let stand 10-15 minutes before cutting; filling will settle slightly.
Eat!
October 29, 2004
SOP II Presentation Slides
As I feared, many at State of Play were speaking about virtual objects as if they were user’s personal real-life property. The general reasoning is:
Secondary Virtual Item Market implies Real World Value and that implies that it is Real World Property and, by extension, subject to real world property laws.
Refuting this position is why I prepared the KidTrade position paper and released it two weeks early. I didn’t want to spend my time at the conference talking about KidTrade proper, but use it as one of several proof-case(s) that the the formulation above is an insufficient to rationalize the Real World Property hypothesis. I was able to achieve this goal.
The powerpoint slides I used as notes are available, and as an added bonus the deck includes the “History of Habitat” slides I presented at the evening event at the Museum of the Moving Image, complete with screen shots.
UPDATE 11/12/04: The video archives are up and you can watch my panel.
October 16, 2004
The Vision: Cyberspace Protocol Requirements
In 1993 Electric Communities was a three-person consulting partnership: Randy, me, and our former Lucasfilm Games coworker and frequent collaborator, Doug Crockford. We had several clients, but by far the biggest and most important was Fujitsu. Fujitsu had hired us to do a business plan for bringing Habitat back to the United States, starting from the Fujitsu Habitat system they had developed in Japan. This was the project that eventually became WorldsAway (and which they eventually hired us to staff and manage during its formative years).
We, for our part, were far less interested in Habitat per se, which for us was yesterday’s thing, than we were in newer, more cutting edge stuff. The biggest limitations in the Habitat architecture, from our perspective, were that it relied on a unitary, centralized server, and that the environment was not user extensible. We wanted to put together a system which overcame these limitations.
We had some ideas about how to do this. We were heavily influenced by lengthy discussions with Dean Tribble and Mark Miller, who introduced us to the wonders of the capability paradigm for security and optimistic computation for implementing distributed systems. Dean and Mark worked at Xanadu during the time Randy and I worked at American Information Exchange. We got to talk to each other a lot because, for about five years, AMiX and Xanadu shared offices in Palo Alto (both companies being part of the Greater Autodesk Coprosperity Sphere at the time). But that’s another story.
Our arrangement with Fujitsu was that they would pay us to spend half our time working on WorldsAway and the other half doing advanced conceptual studies, planning, and prototyping for a next-generation system. They’d own the WorldsAway work and we’d own the conceptual stuff, though they would have the right to make use of the latter however they wished. It was a pretty sweet deal, especially when viewed in the light of these post-bubble years. We got to sit around and think great thoughts about pretty much whatever we damn well pleased while getting paid rather well for our trouble.
For the most part, I worked on the conceptual stuff (with a little bit of WorldsAway), Randy worked on WorldsAway (with a little bit of conceptual stuff), and Crock worked on figuring out how to present all this weirdness to the people at Fujitsu. After a couple of years of producing various presentations, studies, and reports, the ultimate end product of this effort was a hefty document gradiosely entitled Cyberspace Protocol Requirements, which we post here in public for the first time. (Note that although this is the final revision of this document, dating from February, 1995, the principal work was published in the March, 1994 in a form only very slightly different from this.) This document is really quite embarrasingly dated, but we decided it would be worthwhile to get it on the record. It’s probably also worth pointing here to the manual for Dean Tribble’s Joule language, which was included as an appendix in the dead tree version of the Protocol Requirements document. Joule was our first round pick for the foundation language for the infrastructure we proposed building.
An important piece of historical perspective to keep in mind, should you actually attempt to read this: there is one seriously major development that had not yet taken place at the time this was originally drafted, namely, the rise of the Internet. The Internet was just beginning its explosive takeoff at that point; indeed, we allude to this. However, though people certainly expected that some kind of dominant, global, electronic network was going to be the wave of the future, at the time the Internet per se did not appear to be the foregone conclusion that in retrospect it obviously was. It was a time when all the various large media companies (phone companies, television networks, cable TV operators, etc.) were announcing mergers and new strategic alliances almost daily, in an absurd and furious spectacle that we referred to as “The Dance Of The Dinosaurs”. Nothing concerning the look of the future was very clear. It was a time when people were still getting used to the idea that commercial use of the Internet was even legal (which it hadn’t really been for most of its existence up to that point, since it had been a creature of the world of academia). In particular, we were getting along with FTP and Gopher and none of us realized the the World Wide Web would be the big winner. Indeed, those of us who had been associated with Project Xanadu were especially surprised by the success of the Web, since its technical deficiencies were, in our eyes, so profound that we never quite believed that anyone could ever take it seriously (as Mark Miller put it, “if we had known at the time that the thing didn’t actually have to work, we would have been done a lot sooner.”)
Another disclaimer is that there is a lot of visionary stuff in here that I either no longer believe or believe in a profoundly modified form. I’ll have a lot more to say about this in my next post, which I’ll have up here soon.
October 12, 2004
KidTrade: A Design for an eBay-resistant Virtual Economy
A position paper for State of Play II Reloaded, for the
Virtual Property/Real World Markets: Making a Living in a Virtual World panel.
Updated October 20th, 2004
Preamble
Though many of the ideas presented in this article have been kicking around in my head for more than 20 years, and some of the features were tested here-and-there in various virtual economies that I’ve been fortunate enough to help create, the bulk of the work presented in this paper is part of an undeveloped children’s MMOG, designed for a Tantrum, Inc., and appears in this paper with permission. As always, I wish to thank the entire MUD/MMOG development community for constantly challenging and refining many of the ideas contained herein, and especially Chip Morningstar, who co-designed and implemented most of the virtual economies that inspired this design. The latest draft of this article clarifies some design issues and makes a few minor fixes, all as the direct result of discussions on Habitat Chronicles and TerraNova. Thanks gang.
There are many external markets for virtual objects, including Gaming Open Market (GOM), TheGoods , and eBay to name a few. Not all use real currency to facilitate trades. For the sake of brevity, I will refer to all external trading markets as eBay, acknowledging any significant differences, where warranted.
An eBay compatible virtual economy is now a design choice.
“For every person you see selling an [Ultima Online] account on eBay … there are a bunch of people bidding, too. And they are bidding on intangibles. They are offering up their hard-won real money in exchange for invisible bits and bytes because they see the intangibles of UO as being something worth having. A tower for a sense of pride. … I find it odd that people think this cheapens the whole thing. I think it validates it.” – Koster
“ …[an eBay-able virtual] economy primarily indicates that the leveling grind is a design flaw…” – Lastowka, Castronova, and others on TerraNova
“…You may not buy, sell or auction (or host or facilitate the ability to allow others to buy, sell or auction) any Game characters, items, coin or copyrighted material.” – EverQuest EULA, Section 9
“As a player, I still prefer a subscription model with no eBaying.” – Ed Castronova
Among MMOG customers and developers, online debate rages about the unfairness of the time-investment vs. money-investment trade-off. Those who have an excess of one resource and a shortage of the other face off against those with the opposite resource imbalance. I will not retread that ground here, but instead offer an alternative approach to the entire idea of the virtual market.
An eBay compatible virtual economy is (now) a design choice. We may not have known that this would happen a decade ago (though, arguably, we should have), but now there’s no excuse for ignoring this effect when developing a new game. We can design our products, service rollout, Terms of Service and End User License Agreements with our eyes wide open.
We don’t have to do it the same –old way, especially if it doesn’t make sense for our game. There are other virtual market designs that do not have these same properties, and may be suited better to your property, especially if externalizing virtual object markets will be harmful to the health and/or profitability of your product.
I will present one such model in detail: KidTrade.
First I will describe the de facto-model of many large MMOG virtual economies and deconstruct and name the primary design decisions that lead it, seemingly inescapably, to items for sale for cash on eBay.
Next I will present a specific model for an eBay-resistant economy, designed for children to trade scarce virtual objects without fear of being cheated by smarter, craftier (adult) traders who are generating a lifestyle-supporting income from eBay-ing the kids’ poor trades.
Finally, I will review the tradeoffs proposed and the anticipated effects they will have on the game experience.
From Twinking to EBay:
The MMOG Virtual Economy Design “Slippery Slope”
Twinking[1] is a design choice. Muling[2] is a design choice. These are built on gifting, another design choice. Gifting is person-to-person transfer of virtual goods. Just add private messaging (email or IM) and some trust, and gifting becomes trading[3]. Most designers figure this out (eventually) and implement a trading machine interface to remove the trust requirement. Introducing object scarcity increases the play value sufficiently that, when combined with a large enough target audience, you only need to reintroduce trust to create the incentive for an external marketplace to thrive, like eBay. GOM even removes the trust requirement again by implementing deposit/withdrawal ATMs in Second Life.
So, the steps on the virtual economy slippery slope are:
- Gifting → Twinking
- Gifting + Multiple Chars/Server → Muling
- Gifting + Messaging + Trust → Trading
- Trading – Messaging – Trust + In World Machinery → Robust Trading
- Robust Trading + Scarcity + Liquidity → External Market (eBay)
- External Market – Trust + In World Machinery → GOM
The items in bold face are the ones that designers have primary control over. The rest is up to the users. They decide on the economics of twinking, muling, eBay-ing, etc.
Some may think that this chain of design decisions is inevitable, and some have argued that, for good or ill, it is now a de facto standard and is expected by the customers. I have personally designed and/or implemented many products that have followed this path, but, like many other service operators, found this design unsatisfactory. Many play online games to escape the fact that they aren’t as successful (aka: rich) in the real world as other folks. Correct or not, a portion of our audience sees virtual worlds as a new level playing-field, where everyone starts fresh, without any particular advantage. For at least one audience, this is particularly true: children
I took it as a personal challenge to someday build a virtual economy that did not rely on the slippery slope of the typical MMOG. In 2003, I was given that opportunity when I was the lead designer for a tiny self-funded startup working on a children’s virtual world. KidTrade is the name that I’ve given for the economic model I’ve extracted from that design and am now presenting here. I offer it as an alternate economic model with man
y interesting properties,
including resistance to the sale of game items and currency on eBay.
KidTrade: An eBay resistant economy[4]
Background & Goals
The KidTrade economy is a part of a kids MMOG design described as
“NeoPets meets Toontown: But the objects work!
Children have humanoid cartoon kid avatars and collect, trade, and play with virtual objects including pets, fun vehicles, combat contraptions, clothing, toys, decorations, furniture, and houses, all in a safe, shared virtual world with various locations and activities, each targeted at a different set of kids’ interests.”
The product has no treadmills: Being online for more hours a day does not increase your wealth or power. Items are generated at a time-release rate. Family play is one of the design goals, bringing the game within reach of a younger audience and was optimized for sparse, short sessions.
KidTrade a proposed economic model underlying a service that is a collection of children’s multiplayer games and activities, many of which may/must be augmented with the virtual items provided by the system. The market is not intended as a primary play-feature of the service.
Trading is specifically meant for optimizing the service’s play model: collecting the components of a vehicle, building and furnishing your house, or gathering the resources needed for a team-play game. Focus is placed on subjective value over objective (quantifiable) value.
KidTrade: Design Elements
A Thing Based Economy
The service is built almost entirely out of ‘game-objects’ which I will call things, for simplicity. Things are what the players collect and trade. Instead of a CCG (collectable card game), it is a CTG (collectable things game.)
Things are all active: Each thing does something when it is in the world. The vast majority of user activity is expected to be the using and trading of things. There are pets, vehicles, combat contraptions, clothing, toys, decorations, furniture, and more. They all wear out with use, so the kids learn to not abuse their things. This discourages antisocial hoarding behavior.
Things come in three basic categories: collectibles, consumables, and customizers.
Collectibles
Collectable things are meant to be purchased by a player for personal use and sharing/displaying to others. These things are often quite utilitarian in nature, such as vehicles, clothing and toys. Just as often collectibles are aesthetic, such as decorations and furniture.
Sets (Crafting, Part 1)
Some collectibles are parts of sets. When all the things in a set are collected by a single player, the objects may be combined to produce a combination object, representing the whole set. For example, the individual things CAR TIRE x 4, LONG CAR BODY and HUGE CAR ENGINE could combine to create a LONG CAR WITH HUGE ENGINE vehicle. A collection of action-figures/dolls could be combined with a PLAYSET to produce a diorama scene for display in a kid’s house.
Uniques (non-tradable)
Some collectibles may be non-tradable unique things. These are usually given to kids for personal achievement, winning contests, or for participation. These objects are non-tradable as they represent personal achievement. When a set of things is combined into a new thing, it becomes a unique thing and may not be disassembled or traded. If the service supports Sharing (see below) things, unique things may be shared. Several games refer to this category of objects No-Drop.
Consumables
Things that are intended for immediate use are called consumables. These include things like repair kits, combat contraptions, fuels, medicines, and the like. Unlike collectibles, it is common for consumables to allow for a fixed number of uses and then are used up or destroyed.
Customizers (Crafting, Part 2)
An interesting subclass of consumables is customizers. Things that mutate the nature of other things are in this category: Cans of spray paint, texturizers, shape/size-changers, sound-changers, voice-distorters, etc. These are always consumables (limited use) and only work on appropriate customizable objects. For example, a user could use one to change the door-opening sound on their house, or change the pattern of wall paper in a room, etc. Neopets.com uses Paint Brushes in this way to great effect.
No Currency
Hoarding of objects and currency is a standard practice in many online games. So is hyper-inflation of the internal currency. These behaviors are do not provide an appropriate model for younger children: Parents want their kids to learn good citizenship and sharing skills, not caveat emptor.
The service is presently designed without a currency to discourage hoarding and other antisocial trading schemes.[5] This should help emphasize subjective/relative value: “I need x and I can trade y for it” over numeric objective value: “I need to convert objects y & z to currency to get enough cash to buy the hyper-inflated x that I want.”
Production and Consumption
The product implements a Faucet and Drains economic model, where things are carefully introduced into the world by the service operator (the Faucet), and they leave the system as a result of being either combined (collectibles), exhausted (consumables) or by being discarded by users because they have decayed to the state of being broken. This provides two points of leverage for managing the value of things in the world.
Faucet: Paid Membership → Thing Income
Users are given things purely based on being a paid member of the community. Each X day(s) a thing is added to the user’s inventory. It is randomly selected from the players approved set of things.[6] This model equalizes the playing field for all players, with each having roughly the same chance to get any subjectively desirable item. Since the Trader’s Market (described below) only allows anonymous trades with the community, players who can afford multiple accounts can not use them to create a disproportionately rich/powerful player via muling or making lopsided trades with themselves.
Another method for the introduction of new items into the game is for system staff to make them available in the world as prizes for contests (treasure hunts!) or list them in the Trader’s Market.
No tradable scarcity
By design there is no scarcity of tradable collectibles or consumables. The number of things of each type remains roughly constant across the active user base which is kept in balance by the faucet As noted above, only Uniques are scarce and are not tradable on the market at all.
Special Drain: Decay (Wear, Tear & Repair)[7]
Neopets.com suffers from irreparable runaway inflation of its currency: NeoPoints (NP). This is because currency and objects are introduced into the economy at a rate significantly higher than their consumption. As a result, needed items, such as medicines to cure pets of illnesses are priced in the range of 100,000NP, when the same item was at the system store (for about 2 seconds, before a bot bought it) at a price of 100NP. New users are at such a disadvantage that if a pet gets sick it is better t
o abandon it rather than work to heal them.
We will avoid this problem and encourage responsible care of owned collectibles by having them decay. Excessive use of items causes wear & tear, eventually leading to the object being broken.
There are consumable items that can repair damaged and broken items up to used status.
Consumables are not normally subject to wear & tear, as their use count is limited instead.
A thing does not decay if it is part of a standing offer that is currently unfulfilled in the market (see below.)
Trading
Of course, when a kid sees some thing that someone else has, they might want one of them. Since the only way for items to enter the world is via the daily award faucet, it is very unlikely that a user would get exactly the item they wanted just by waiting for it.
Instead of waiting, we encourage kids to trade their things for other people’s things, since this is the only way for them to get a specific item.
The Trader’s Market
Since there are so many kinds of things, with so many combinations of attributes, and not everyone is online at the same time, the service offers a special Trader’s Marketplace, available at all times on the user interface. All online trades happen here. Like the stock market, all trades are listed anonymously, best terms only. Since the identities of all traders are hidden, this market resists the establishment of an external money-for-things marketplace by preventing specific user to specific user trades: There is no way to make a guaranteed delivery. This also discourages adults buying multiple accounts just to raid them for their daily thing grants.
All trades may be completed asynchronously – while the offering party is offline. If a user’s offer is accepted while they are offline, they will be informed as soon as they connect.
Browsing
The market is presented as a series of pages, each displaying the things available for trade. Buttons on the page limit the search criteria by types, sets, and specific attribute values. Each line shows thumbnails of what is being traded for what. Each oldest, best trade with a particular set of terms (x for y) is the only one displayed for those terms (trades with duplicate trade terms are not displayed). This massively simplifies the display, removing duplicates and lower-value trades from consideration. No information is provided about the number of offers available at these terms, nor the age of any particular offer.
The first trades listed are those that the kid can fulfill immediately for items he’s otherwise already made offers for, next are items that he can fulfill, third are items that he can fulfill with currently banked things (see below), next are trades that he can’t fulfill but contain items that he’s made offers on, and lastly the remaining items for trade. All of the sort buttons respect this ordering except the Sort By Thing button, which sorts in alphabetical order.
Completing a Trade or Making and Offer: “I want a big engine”
The kid can either accept any fulfill-able trade as displayed, or compose a new offer. Offers are constructed graphically and always one for one.[8]
When a thing is offered in trade, it is put in escrow or banked until the offer expires or is accepted. Banked things can not be used in any way or offered in another trade. Banked thing are not subject to decay If an object is removed from the bank, the corresponding offer is removed from the market.
When browsing, trades that the player could conclude with objects that are banked for other offers are listed second. If a player accepts a trade that includes items he has banked, the user is informed that completing the transaction will cancel their other offer.
Banking teaches children about committing resources to achieve a long-term goal.
A Word About Liquidity
In order for the market to have the property of masking the identity of the traders, there is a minimum liquidity level required for each trade type. Offers of each formulation (x for y) will not be displayed until this threshold is met. The liquidity threshold should be some fixed minimum value plus a random bonus to discourage gaming.[9] See the Appendix for a detailed defense of how this market is resistant to eBay.
Sharing (No Gifting)
The Trader’s Market doesn’t allow you to give something to your friend. Given that I firmly believe that gift-giving is the foundation of community, the elimination of gifting in a children’s product seemed extreme. Fortunately, the answer came in the form of a feature from a competitor: There.com’s lending feature.
A user may choose to share a non-unique collectable with a friend for a fixed amount of time (20 minutes?) after which the thing automatically returns to the owner. The borrower cannot, in any way, be considered as the owner of the thing, but may use any type-specific behavior: he may ride the bike, spin the top, etc. Note that the object will still decay normally.[10]
Tradeoffs & Conclusions
The KidTrade virtual economy design avoids the slippery slope from Gifting to eBay by integrating the market directly into the game as well as making the identity of the traders anonymous. It effectively prevents muling, twinking, and eBay trading while trading off the features of a currency (an audience driven design choice), some scarcity, and gifting (this is mitigated through sharing/loaning.)
Though this model has yet to be implemented and thus has not revealed its own particular weaknesses, I contend that it is rich enough to provide an entertaining and vital economy, especially for its target audience: kids.
I submit that this design is specified at a sufficient level to demonstrate my position for this panel: “An eBay compatible virtual economy is now a design choice.”
Be sure and let me know if you try any of this stuff before I can. Discussion of the KidTrade is taking place on Habitat Chronicles.
[1] Twinking is the practice of experienced players gifting powerful virtual objects and/or large sums of currency to beginning players or low-power characters.
[2] Muling is the practice of users transferring objects between their multiple characters on a game server. This is typically done to get around per-character item storage limitations.
[3] The most primitive form of MMOG item trading was in the original Lucasfilm’s Habitat, in which Avatars gave objects to each other by dropping them on the ground at their feet and walking to the other party’s objects and picking it them up.
[4] Note: This model does nothing to address the sale of characters on eBay. The service’s position on character transfer was TBD but would have, most likely, followed Sony’s lead: Transfer is against the Terms Of Service, and the company will not offer customer service support for such transfers.
[5] Other designs are worth considering to meet this goal: A currency could be implemented with a limited-maximum wallet/purse for kids. To teach cash management and good saving skills, any cash allowance would have to be pre-allocated to the purchase of a specific thing. Als
o, the market could set the token price of all objects to a fixed value. This alternative was not explored in any depth and is left as an exercise to the reader.
[6] The base set may vary by user, based on play behavior: For example, if a user is hoarding collectables, they may receive more consumables to encourage other game play.To meet the no-scarcity requirement, the random selection will favor any things that are in non-equal supply.
[7] Decay complicates the trader’s market by adding wear status as a dimension, but seems like an important feature for a kid’s educational game. Stuff that lasts forever, even when you use it heavily, doesn’t match their real-world experience.
[8] Another exercise for the audience: How does the market change if you allow many-for-one offers? How about many-for-many?
Appendix
A walkthrough The Trader’s Market and eBay market resistance features.
Several questions have been raised about my claims about KidTrade’s features and how the market for Things is eBay resistant. In order to defend the claims, I will first lay out the requirements for a successful eBay trade, demonstrate how an established KidTrade Trader’s Market inhibits fulfillment of those requirements, and how liquidity limits effectively protect the market until it becomes established. Finally, I visit the sharing feature and demonstrate how to mitigate the risk of using eBay to ‘rent’ Things.
Requirements for an eBay transaction to succeed
There are several requirements for an external market transaction on a service like eBay to be possible for the transfer of virtual goods between characters on a service:
- Requirement 1: The Seller must be able to guarantee delivery of the virtual goods to the correct buyer in a reasonable timeframe. Delivery to the wrong party is not acceptable.
- Requirement 2: The Seller must also be able to confirm delivery of the virtual goods to the correct buyer, or be subject to potentially fraudulent buyer non-delivery claims.
- Requirement 3: The universe of Buyers and Sellers must believe that Requirements 1 and 2 can be reliably met, or the market will not develop. This belief is only established through a history of successful transactions.
- Requirement 4: The value of the Thing being sold is greater than transaction costs including: Transaction fees, market liquidity, delivery fees and delivery coordination. If the sale value drops to zero, this requirement can not be met.
KidTrade needs only prevent requirement 1 or 2 to make the market nonviable, but this design interferes fulfilling both requirements!
The properties of an established KidTrade Trader’s Market
To demonstrate the eBay resistant features of this market, we will first consider an established trader’s market. This is defined as the state where there are significant numbers of outstanding offers for each type of item on the market.
Since, from the point of view of an external observer, all offers are commutative (A for B is the same offer as B for A) the number of outstanding offer formulations will be the number of pair-wise combinations (C):
C = n * (n – 1) / 2
where n is the number of tradable thing types.
In an established market as defined, for any specific Thing type, there are(n – 1) offer formulations (one for each other Thing type), each with many offers for each.
Threat:
- A seller lists a Thing for sale on eBay, promising to transfer it to the buyer using the Trader’s Market
Design givens:
- All orders are anonymous:
- No one knows which offer will be fulfilled.
- No one knows the number of offers of a formulation that are pending.
- No one knows when an offer will be fulfilled.
- No one know which offer is their own.
- When your order is fulfilled, you have no idea who you traded with.
- Any attempt to formulate an offer will be fulfilled first and immediately with standing orders.
- An established market contains many standing orders for all offer formulations
Conclusion:
- The seller can not meet eBay Requirement 1, since it is not possible to guarantee delivery to a specific buyer due to anonymity and instant fulfillment.
- The seller can not meet eBay Requirement 2, since there is no way to independently confirm that the delivery was made to the appropriate party.
- Therefore, the eBay market is resisted.
[Auto]-Collusion attack against an unestablished Market
But, the definition of an established market is key. That won’t exist at all times, and most certainly won’t at the beginning of the service. If there isn’t sufficient liquidity (enough offers of a specific formulation available), it might be possible to find a way to almost-meet eBay Requirement 1. It has been suggested that the collusion of enough sellers (accounts) may be able to control a set of offer formulations for the transfer of goods.
Threat:
- A seller creates many KidTrade accounts (or colludes with others), collects several of a specific Thing type (CoolThing) on a subset of those accounts. He lists a Thing for sale on eBay, promising to transfer it to the buyer using the Trader’s Market, intending to have the buyer use an often-traded (statistically determined) item as placeholder-currency to complete the transaction. The seller will use as many accounts as it takes to fulfill the trade.
Design givens:
- All orders are anonymous
- No one knows which offer will be fulfilled.
- No one knows the number of offers of a formulation that are pending.
- No one knows when an offer will be fulfilled.
- No one knows which offer is their own.
- When your order is fulfilled, you have no idea who you traded with.
- Any attempt to formulate an offer will be fulfilled first and immediately with standing orders.
- The liquidity for the PlaceholderCurrency-for-CoolThing is low enough to manipulate.
Conclusion:
- The seller may be able probabilistically meet eBay Requirement 1, with a large number of accounts, each with their own CoolThing. This reduces the US$-value to a crap shoot: The seller can’t know how many offers he will have to fulfill to deliver the goods to the correct buyer. Along the way, any mis-delivered items were given to unexpected (presumably very happy) recipients.
- The seller can not meet eBay Requirement 2, since there is no way to independently confirm the delivery was made to the appropriate party. In the end, the seller has given away all of his CoolThings and doesn’t even know if the buyer has been ripped off or, worse, taken him for a ride by collecting all of them for the price of one, while demanding a refund.
- Therefore, the eBay market is resisted. Though not
quite as effectively as in a fully liquid market.
Bootstrapping an established market (liquidity control)
What little potential the collusion attack may have can further be weakened by increasing the liquidity in the market to approach the goal of an established market. What level of liquidity is required to resist the probabilistic market manipulation proposed in that attack?
An interesting baseline calculation is the expected number of offers-per-formulation (o) in the market based on the current number of tradable Things (t), percentage of things banked (b%) and the number of thing types:
o = t * b% * 2 / n * (n – 1)
So, with 1,000,000 tradable things, 10% listed for trade, and 100 tradable thing types you get an average of o = 20 trades for each formulation. Any minimum liquidity threshold should be less than o, perhaps .5*o or 0.75*o. It may well be reasonable to have a different (or even changing) liquidity threshold for specific things/formulations based on trading patterns.
Use Case: The HotNewThing
This design explicitly does not claim that 1:1 trade means that the value of all things is equal. On the contrary. Some things will be more desirable than others, or more desired by many players.
Consider the case of the HotNewThing. These services are content-consumption dependent, and new items are desired most strongly by the core community. Many will want the newest thing and would this increases pressure to consider alternate delivery methods (such as eBay), if technically possible.
What would a HotNewThing most likely trade for? A CruddyOldThing? Probably not as fast as for AnotherPopularThing. There will almost certainly be many CruddyOldThing-for-HotNewThing offers pending in the market, as people would have no reason not to try that trade, given that it may eventually succeed. Given the proof in this appendix, it should be clear that the trade that is most likely to complete in the shortest time will be AnotherPopularThing-for-HotNewThing, confirming the perceived value of both objects.
This should be the final nail in the coffin of the thing-transfer-by-eBay argument: There won’t even be a junk thing for eBay-traders to use for placeholder currency as the largest number of outstanding offers for each widely most-valued object will be in exchange for CruddyOldThings, because they are less-valued and it is no burden to offer them in exchange for any desired item.
Sharing and eBay: The Question of Market Friction
The sharing feature of KidTrade is optional, but desirable for social-education reasons. Here we consider the so-called “Blockbuster” threat:
Threat:
- A seller rents the right to use a CoolThing for 20 minutes using eBay for the cash transaction and fulfilling it in the system using the Sharing feature.
Design givens:
- Sharing allows a specific user to lend a thing to another user for 20 minutes.
- Shared items have limited functionality.
- Some number of CoolThings are available for trade on the market.
- There are as many CoolThings in the economy as any other Thing.
Conclusion:
- The seller can meet eBay Requirement 1.
- The seller can meet eBay Requirement 2.
- The seller can meet eBay Requirement 3.
- The seller may be able to meet eBay Requirement 4, if:
- The selling price is greater than the listing costs (and other overhead.)
- Many potential renters don’t already have a CoolThing and the limited-use value of the CoolThing is greater than the selling price.
- Many potential renters can’t (or won’t) easily trade one of their Things for a CoolThing.
- Many potential renters can’t simply borrow a CoolThing for free from anyone they know/see, which is it very reason for the Sharing feature.
- The eBay/Thing rental market may or may/not be resisted depending on the temporary-use value of things and transaction costs. I contend that the frictions described above are considerable and sufficient to, at least, severely limit the effect any external market.
- If an external rental market appears, the service provider may implement one or more of several mitigation options:
- Enable users to borrow one of each Thing type from the system once, for evaluation. (This should kick the teeth out of Requirement 4)
- Limit the number of times a thing may be shared per owner per unit time.
- Reduce the lending time.
- Disable sharing, disabling the threat.
- Use standard hunt-the-TOS violator techniques (not recommended.)
- If it represents a small amount of the total sharing transactions, just ignore the external market. The kids don’t have credit cards. It isn’t hurting anyone. :-)
This appendix reinforces the main point of this article: The eBaying virtual items is not a necessary-evil of MMOG design.
September 13, 2004
The Avatar is Legal Voting Age
I finally got around to scanning my copy of the first print reference for the use of the term Avatar to represent a user’s graphical online presence.
Definition Habitat: A make-believe world inhabited by small, colorful creatures, called Avatars. Human beings may visit Habitat and move freely about its regions, interacting at will with with Avatars. Human beings reach Habitat by traveling many miles through tiny telephone lines and entering through a large gateway, called QuantumLink. Once a human being enters Habitat, he or she takes on the visual form of an Avatar, and for all intents and purposes becomes one of these new-world beings. In the world of Habitat, people can play games and go on quests, but mainly they meet other people and have fun. — Run Magazine, August 1986 (full text transcription)
The Avatar just turned 18.
[Update July 06, 2008 by Randy]
A client provided me with another historical link to a 1986 article in Compute Magazine that has been archived online: Habitat: A Look At The Future Of Online Games by Kathy Yakal.
In the extended entry are the scans of the page of the screen shots (linked from the archive)…