May 18, 2005
Thoughts on a No-Cash System
Barry Kearns has posted a very interesting article about how the economy would work for an MMORPG using a No-Cash System. A major goal of such a system is that it prevents twinking, and prevents players from buying game currency for real-world currency on the internet. Whether these are laudable goals is debabatable, but debatable elsewhere.
I find the ideas intriguing, but has at least two flaws: (1) It places constraints on the nature of objects that can be bought and sold, or (2) it won't work, anyway. If we understand these problems better, we may be able to re-design an economy that meets those goals.
Kearns calls this proposal a "continuous double auction with a closed order book." In his example, Ellen has purchased 10000 units of gold from James external to the game and is trying to deliver it. They try to use the commodities market to have James buy 1 of some item Ellen is selling for the 10000 gold, but they are stymied because the system itself is willing to buy items offered for sale at less than 25 gold, and is willing to satisfy demand for that commodity for any buyer willing to pay 75 gold. James can't buy Ellen's item for 10000, because the system itself will sell him cheaper items at 75.
But if I were James, here's what I would have done. It requires two things: one commodity market that is cleared of all buyers and sellers other than James, and that Ellen have enough funds to buy one item in that market. Assuming that James runs a business, and has a source of game currency, he may have to expend some of that currency to keep some market clear, but that's just the cost of doing business.
Once we have the conditions above, Ellen bids to buy one item at 26, and then James offers one item for sale at 26. Next, James offers to buy at 74, and Ellen sells one for the same amount. Ellen now has 48 gold profit, and we repeat the cycle, and she has 96 gold. Now we can do it again with 2 items, so that Ellen is up 192 gold. And so on.
With a clear market and enough cycles, James and Ellen can exploit the system-bounded price range to transfer as much gold as they want (in O(log n) transactions).
Sellable Items Must Be Common. To thwart this more subtle attack, it must not be possible to empty an market. But to do this would place constraints on the nature of objects that can be bought and sold.
For example, on my World of Warcraft server there's usually around 5000 items offered for sale by other players, of which 1500-2000 are "uncommon" armor pieces. (As an enchanter always on the prowl for cheap ways to get enchanting reagents, I happen to watch this market closely.) And after disenchanting about 10,000 items, about 15% of the items on today's market are ones I haven't disenchanted before.
To use the No-Cash system, the game would have to avoid these "rare" objects, which are so common in games like WoW.
All Sellable Items Can Always Be Purchased. This is a side-effect of the system having a sell-to-you price that bounds the highest price that may be paid for such an item. If this price is set very high, then Ellen and James can play their backwards arbitrage in a small number of iterations. When it is set lower, however, then anyone who wants that item can just fork over the bloated price.
Failure to Find the Correct System Buy and Sell Prices Results in Empty Markets. Let's imagine a situation where demand for Heavy Leather is strong enough that the price rises to 15 gold for a stack of it in a free-market situation. But the system price controls bound the price between 8 and 14 gold. The leather gatherers can sell all the leather they want at 14, but if they offer it at 15, the system underbids them. So they have to scratch their heads and ask, "Is it worth gathering heavy leather if I can only get 14 gold for it?" As long as demand stays heavy, and the price bounds stay fixed (which is not guaranteed), the market will stay empty.
Posted by at 10:09 AM | Comments (4) | TrackBack
May 17, 2005
Collecting Data from World of Warcraft
In constructing World of Warcraft, Blizzard made the interesting design decision to implement the client-side UI in a way that is open to extension and modification by the user community via an API. Combine this with a way to query the population in-game (the /who command), and it becomes possible for us to issue a decree to take a census of the known world.
Others (WoW Census, for example) have done this before, but for one reason or another, the data was not quite in the format we wanted, so we rolled our own. In essence, we have a way to collect a census snapshot of one faction of one server in about 5 to 15 minutes, depending on server load.
Fine print: Essentially, we loop through all race/class pairs (e.g., "Dwarf Paladin"), emit the appropriate /who command, and wait for the server to respond, at which point we stash away an entry in the SavedVariables.lua file of the form,
Thunderserver,2005/03/24,Crandall,56,Ni,id,y,Felwood,Ant Killers
for a level 56 night elf druid on the server Thunderserver. He's currently in Felwood, grouped ("y"), and is part of the Ant Killers guild. The server is only willing to return 49 entries to us at a time, so if there are more than that, we restrict the levels (e.g. "Dwarf Paladin 1-25") until we're sure that we're seeing everybody. (Caveat: We currently have no way to catch all players if there are more than 49 online gamers with the same race, class, and level. So far, we've only seen that with level 60 dwarf paladins at peak times. And we're ignoring this for the moment.)
We are currently collecting snapshots from both factions of three different worlds: the RP realm that we commonly play in, a normal server which was listed as having a moderate load, and a normal server which was considered to be heavily loaded.
After exiting the game, we have same Lua hackery to scavenge the data in SavedVariables.lua and leave it in a more permanent form on disk.
We've been harvesting data on and off since late March. (We have a manual upgrade process after each patch.) To date, we have taken about 6000 snapshots, or roughly a thousand snapshots per server per faction. Afterward, we're analyzing the collected data with our own Jawa application and Excel, but that's a story for another post.
Posted by at 04:17 PM | Comments (7) | TrackBack