Posts from October, 2004
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.