Showing posts with label bot. Show all posts
Showing posts with label bot. Show all posts

28 August 2012

Bots for load-testing

A list of MMOs, MOBAs, and FPS games that have been load-testing using bots.

TERA

Koo, 2010, How to support an action-heavy MMORPG, slides

Their system to load-test a shard is called Sisyphus, and runs 1500 clients per machine. The behavior of the bots is based on the behaviors from real players (probably from alpha). A WAN simulator is used between bots and realm servers; the average latency is set to 200ms. A high-performance machine and a "dedicated line" were needed.

EVE

Press, 2011, Orchestrator: A post-mortem on an automated MMO testing framework, slides

EVE started to make a thin client from its game client in 2010. Orchestrator is the tool they use to load-test and integration-test their architecture and code. Orchestrator does not send one script to each client, proxy, and server. Instead, it runs a single master script, and tells them, as they progress in the test, what the next operation is. The test can be stopped right when a client reports a bug, not until everything scheduled has been sent.

OpenSim

Lake, 2010, Distributed scene graph to enable thousands of interacting users in a virtual environment, paper

The limitations we have encountered with avatar scaling during these experiments have been in getting enough hardware to generate the load of over 1000 clients and the limited physics simulation capabilities of a single thread on the scene server.

League of Legends (allocating games to servers)

Delap, 2010, League of Legends: Scaling to millions of ninjas, yordles, and wizards, video + slides

  • Load-testing in a realistic setup: more than 50 machines with the same spec as those in production
  • EC2 is a good tool, but the network is not reliable, so careful not trying to fix problems that only happen in the test setting.
  • With thousands of clients, logs may not be the best way to gather test results.

League of Legends (chat)

McArthur, 2011, Building the chat service for League of Legends, slides

Dozen of EC2 machines, each running 5-9k bots. Each bot is an XMPP chat client (they used the Smack API). Load-testing is useless without proper modeling.

Crysis 2

Hall, 2011, A Programmer's Post-mortem Crysis 2 Multiplayer, slides

They wanted to check the frame rate with lots of moving entities, and detect bugs or gameplay issues. They used automatic testing. "Lots" of bots are run for 10 minutes per level to stress-test the builds. The bots do random actions like walking, jumping, or shooting.

Gears of War 3

Weilbacher, 2012, Dedicated Servers in Gears of War 3 Scaling to Millions of Players, slides

Their bots are clients without renderer and user input. They run automated bot matches to check the performance of their server platform. For Gears 2, they used to run 2.5 games per core in 2009. For Gears 3, they run 7 games per core in 2011.

Guild Wars 2

Patrick Wyatt, a lead programmer on Guild Wars and Guild Wars 2, discourages using bots: bot's behavior differs too much from actual users. Instead, he recommends recording live play data, and replay it on the server to fix bugs or check the load.

28 May 2012

The social side of gaming - Ducheneaut 2004

Notes from: The social side of gaming: A study of interaction patterns in an MMO, by Ducheneaut and Moore, 2004

  • SWG in 2004: 400k subscribers. The game mechanics make the classes interdependent: after fighting, marksmen go to cities to be healed and buffed by medics and entertainers. Medics need materials from scouts, etc. Social interactions clearly happen in cities.
  • Collect public chat events (= text + gestures such as '/bow') in the 2 places with most people on a single server. 100Mb of chat logs using the '/log' in-game command daily for a month. Used Perl to parse and MySQL to store and query events: who talks to who, how (eg /shout), and the actual text content.
  • 5500 unique players. Up to 1,200 chat events per hour in a single place.
  • Player interactions can be:
    • AFK macros: sending more gestures than they receive
    • Short and efficient instrumental talk: "buff plz", sending very few gestures
    • Genuine socialization, with as many gestures given as received
  • Entertainers get XP when performing for someone else, and owning a high-level entertainer may be required to become a Jedi master. Hence lots of entertainers were AFK-macroing their buffs.
  • Similarly, to become master in a discipline, players need to teach their skills to other apprentice-players. Hence, experts need to interact with newbies. That was also sometimes macroed.
  • Problem#1: AFK macroers and live players do not cohabit well in the same places. Live players do not know what to expect.
  • Solutions:
    • Different places for AFK and live players [eg Ragnarok's autotrade merchant map] - but then, the AFK players are never visited.
    • Players should be able to know, at a glance, who is available (and live) for a particular service. The existing name tag system, already indicating the player's guild and faction over players' head, could be used for that.
    • Reward live play
  • Problem#2: instrumental play (for the points) uses any means to progress fast; that includes macroing. Social play is not point-based, yet 1) social interactions are measured in points, and 2) playing for points requires taking part in social activities.
  • Solution: social progress should not be measured from instrumental play data (HP healed, buffs delivered, number of disciples ...), but rather from live social data (social graph ...).

11 April 2012

Networking and online games - Armitage 2006

Notes from "Networking and Online Games - Understanding and Engineering Multiplayer Online Games", by Armitage, Pool and Branch, 2006

Latency, jitter, and packet loss

Latency sources:

  • minimum delay: distance of link / speed of light (3ms for every 1000km)
  • serialization delay (transmitting a 1500 byte IP packet takes 0.12ms on a 100Mbps link, 20ms through 512kbps ADSL, and 350ms through 33kbps dial-up modem)
  • queuing delay: packets from different sources sharing the same link have to wait to be transmitted (add 50-100ms to the RTT if on wifi)

Jitter: main source is burstiness of queuing delay.

Packet loss: main sources are rare data corruption, temporary dynamic routing changes, and proactive packet dropping (the bigger the router's message queue, the less likely to accept new messages; this slows down TCP and completely drops UDP).

Possible solutions:

  • Preferential queuing of packets based on their source, destination, and protocol.
  • Increase the size of router's active queue management
  • Interleave multiple IP packets at the same time through multiple virtual channels, thanks to ATM and the 2 channels of ADSL

Latency compensation

"dumb client" = waits for server approval to render user inputs. no latency compensation. Types of latency compensation techniques:

  • prediction = playing on consistency-responsiveness trade-off .
    • Player prediction = client only predicts local player's units and fixes discrepancies when receiving server response.
    • Opponent prediction = predict other players' units based on their velocity and position; other players only send updates on their units when their actual position differs from the predicted position from more than a given threshold. Ex: sudden right turn). Trade-off between fidelity (the notification threshold) and number of messages sent. Unfairness problem: players with higher latency receive updates later. Solution: Time Delay (see bellow)
  • time manipulation:
    • Time Delay: server delays processing and sending of user commands to equalize latencies (or up to a maximum buffer size). Pro: fairness. Con: as responsive as the slowest client (or adds latency).
    • Time Warp: server knows current lag to each client. When receiving a client input, server uses current state minus lag to compute new state, and rolls back everyone's state if computed state differs from current state. Used in Valve's engine. Problem: client can cheat by pretending it's lagging a lot while it's not, and send actions that will roll back the state to his advantage.
  • bandwidth reduction (hence reduction of serialization delay): LZW compression, sending state deltas instead of the whole new state, interest management, using P2P for voice, and bucketing/update aggregation
  • visual tricks: show an animation to cover part of the lag

Playability vs network conditions and cheats

2 ways to discover player tolerance to network: 1) lab experiment, or 2) monitoring public servers.

Network simulations: Using custom routers to simulate latency and packet loss: NISTnet for Linux or dummynet for FreeBSD. ns-2 is a traffic generator. Problem: OS scheduler = 10ms buckets. Solution: change the kernel tick rate to 1ms. Other problem: simulation parameters are game-specific, change with the number of players, etc. (although server-to-client packet simulations seem to estimate reality quite correctly).
Use a normal (not uniform) distribution for latency for more realistic jitter. But careful: packet re-ordering may happen if modifying Nistnet's packet delay value on the fly.

Types of cheats
Type Description Solution(s)
client-side graphics (e.g. wallhack), input (e.g. aimbots runs as proxy and rewrites 'shoot' command packets, 24/7 farm bot) only send to clients the state they need, and check that client is running normally on the client-side (e.g. PunkBuster
server-side escaping a game you're losing to not be ranked, brute-forcing an opponent's password to steal his account, or to prevent him from logging in limit msg rate
network DDoS to increase victim's latency hide players IP

Traffic patterns

Sniffing packets on the server side: use a hub, or a switch with port mirroring. Tools: tcpdump (command line) and ethereal (GUI) to capture ethernet frames both in and out. Problem: The accuracy of packet timestamping of the sniffer depends on CPU clock precision, IO throughput, CPU load, ... Solution: calibrate sniffer from a known source emitting regular packets.

Player information: Reverse-DNS-lookup of player IP to know where he comes from. Careful: 2 players behind the same NAT receive the same IP, but they use a different port, so 1 player = (ip, port), not just ip.

Tick and bandwidth: In Wolfenstein Enemy Territory and Quake 3, the server ticks every 50ms (20 hz), while for Half Life 2, it ticks at 15ms (66 Hz). However, for both, the client requests updates every 50ms. The client can chose to request packets more often (e.g. 100 packets/sec), but the server will still send at most at its tick rate (20 hz or 66 hz). Clients can also specify a max downstream bitrate (e.g. 50kbps); this is useful when update packets are too frequent or too big.

Packet size and inter-arrival time: Server-to-client packet size depends on the map design, number of players, ... Packet inter-arrival times: if one packet per player, and each of the n players receives updates about the other n-1 players every server tick, then each client receives a burst of n-1 packets per server tick. In other words, n-1/n of the inter-arrival times should be in the "sub-millisecond region". For example, every 50 ms, a Quake 3 server with 15 players will send to each client 14 packets at a time.
Client-to-server packet size and inter-arrival times depend on client hardware, gameplay behavior, ... but each client has a distribution of packet size and inter-arrival very distinct from other clients. [It could be possible to identify clients that way, and eventually stolen accounts or power-levellers].

07 April 2012

MapReduce for MMOs

MapReduce is a powerful tool to parallelize batches of computations. MMOs may sometimes have to run batches, but from what local game companies tell me, nobody in the game industry is currently using MapReduce. I guess, this is mostly due to studios not knowing what to do with it. Here are some examples.

Business intelligence

Basic metrics such as weekly play time or stop rate can give a rough perspective of the retention of an MMO. These metrics can be estimated with a couple SQL queries on dumps of the production database(s). It starts taking more time and effort to distinguish accross server shard, faction, race, or class. Still, a SQL script running for a few hours can do the job. Fancier analyses such as machine learning or social network graphs explorations take even more time and effort. MapReduce can be used to tune machine learning algorithms through Mahout, and even to process graphs (Google's Pregel also seems interesting for parallel processing of graphs: the Pregel version of PageRank takes 15 lines of code).

Detecting bots, hacks, or gold farmers is not as straightforward, but I think it is doable. First, the typical deviant behaviors have to be determined and made explicit by humans. For instance, speed-hackers send too many messages per second to the server, while gold farmers interact with less players, but more intensely, than normal players. Then, detecting deviant behaviors can be a machine learning classification or a graph parsing problem. In both cases, MapReduce can help.

Game-specific

Matchmaking and ladder: Some pre-calculations or updates to parameters of the ladder and match-making algorithms could be done offline by a small MapReduce cluster. A player's skill is unlikely to change much in 12 hours, so a cron task could run the job twice a day. According to Josh Menke from Blizzard, matchmaking involves gradient descent or Gaussian Density Filtering. Not sure whether Mahout supports GDF, but gradient descent is supported.

Tuning and balancing can take days for system designers. MapReduce could do that automatically: each mapper job is given a particular set of system parameters: player 1 has skill A (cost x SP and inflicts y damage) and skill B (cost z SP and heals w HP), player 2 has skill C (...) and skill D (...). Mappers run a few hundred Monte-Carlo simulations of a player 1 versus player 2 match with a fixed set of parameters (player1:A,B; skillA:x,y; skillB:z,w; ...). When done, mappers pass average statistics (win/loss ratio, average amount of gold at the end of the match, ...) of the 100 matches to reducers who sort them. The interesting configurations for balance are those with a win/loss ratio close to 50%. Naturally, this brute-force way of balancing assumes a proficient AI, and designers will still have to tweak the configurations returned by MapReduce so that they feel fun.

Practical concerns

Engineering detail: MMOs have hundreds of shards, but really only one MapReduce cluster should be needed. Each shard could send its jobs to the MapReduce cluster when it needs them done, and wait asynchronously for the MapReduce answer on a particular port. If the MapReduce job uses data from the production database, producing a daily dump may induce a temporary extra load on the shard's database machines, but this should be fine during empty hours.

MapReduce can be a double-edged sword if overused. Exploring the parameter space of learning algorithms too aggressively may lead to less accurate models.


Edit: Some people have been using MapReduce for analytics: mogade's platform and keighl have been using it through mongodb, but it's more of an engineering constraint (scatter-gather queries in a nosql DB to build a ladder board) than an analytics or machine-learning endeavor.

14 March 2012

Rcmdr on Ubuntu

On Windows, R comes with its own GUI, but on Ubuntu, GUIs such as Rcmdr have to be installed manually.

Software sources

Add a local CRAN mirror to Ubuntu, e.g. http://cran.stat.ucla.edu/, which corresponds to USA-California 2. Remember the mirror you add, because it will be the only one that will be allowed by Ubuntu to fetch software packages. Anyway, add /bin/linux/ubuntu/oneiric at the end of the URL (change oneiric for your ubuntu version). This should give the screenshot below:

Then execute:

sudo apt-get update
sudo apt-get install r-base r-base-dev

Installing Rcmdr in R

sudo R

Then in the R command line:

install.packages("Rcmdr")

Then, finish the installation of Rcmdr by installing the missing dependencies:

library(Rcmdr)

A popup appears, select "CRAN mirror" (not "local folder"), click OK, and the console should start printing lines like below:

Loading required package: tcltk
Loading required package: car
Loading required package: MASS
Loading required package: nnet
Loading required package: survival
Loading required package: splines
also installing the dependency 'matrixcalc'

trying URL 'http://cran.stat.ucla.edu/src/contrib/matrixcalc_1.0-1.tar.gz'
Content type 'application/x-tar' length 8436 bytes
opened URL

...

The downloaded packages are in
 '/tmp/Rtmp6X20rs/downloaded_packages'

And the Rcmdr window should appear. To run Rcmdr in the future, type library(Rcmdr) in the R command prompt. Ctrl-A then Ctrl-R to run everything.

Encountered errors

'Rcmdr' is not available: An error like package 'Rcmdr' is not available (for r version 2.13.1) pops up if R was installed from the Ubuntu repository. The current version (as of March 2012) is 2.14.2. sudo apt-get update, then sudo apt-get install r-base r-base-dev should fix this. If you have the same error with not available (for r version 2.14.1), it may be that no CRAN mirror was added in the software sources to download Rcmdr from.

GPG error: The software center notifies you about new R updates from whichever mirror you picked. When sudo apt-get update, you get the following error:

W: GPG error: http://cran.stat.ucla.edu oneiric/ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 51716619E084DAB9

This article provides the solution:

gpg --keyserver keyserver.ubuntu.com --recv 51716619E084DAB9
gpg --export --armor 51716619E084DAB9 | sudo apt-key add -

Sources

20 December 2011

Play Money - Dibbell 2006

Play Money, Dibbell, 2006

Notes from the book, re-organized in sections by myself for easier summarizing and reading. Below, UO stands for Ultima Online, and OSI stands for Origin Systems Inc, the game company who developed and ran UO. OSI was owned by EA.

Playing

Players keep playing because they want to go up the player ladder the same way RL people want to go up the social ladder. At some point, you have to decide either to leave the game cold-turkey or to give the game a point: make it productive. Giving the game a point is easier because the game is addictive. Although flow happens 3 times more often at work than during leisure times, play makes flow more enjoyable.

Huizinga: play has always been part of society. Weber: the Protestant Ethic of Puritans considers productive activities as recommended by God, and sports and leisure as wastes of time. Capitalism principles come from Ethic of Puritans, hence a capitalist society considers play shameful. Dibbell: Games are symptoms of post-modern rampant abstraction and transformation of wealth creation. Marx: solidity melts into air. Dibbell about games: production is melting into play.

Troy Stolle is a RL carpenter who played a grandmaster blacksmith. When fired IRL, he decides to sell his 52-month old account on eBay for $500, when the account is going to be resold for $2k. He thinks it's all fake anyway and does not realize there is demand for virtual items.

Being part of UO's virtual economy

Virtual economies require and implement constraints and scarcity. Castronova: in MMOs, scarcity breeds market, and markets cross realities at their onset. Dibbell realizes there's a complex supply chain of warriors who drop, artisans who craft, hagglers who buy/sell IG, brokers who buy/sell on eBay or on their own website, and finally the clients. Example of a client: a Mum buys a $25 virtual item for her kid's Christmas. Why people sell for so low is the mystery that lies at the center of market economics: it generates profits at all levels of the chain.
Lesson: Theory of ludocapitalism, where play is a latent force waiting to be tamed the same way steam was the energy of the industrial revolution.

Julian Dibbell: born 1963, starts playing UO in early 2003. Weekly play time: 20 hours per week. First step in the economy: farming and selling batches of leather suits to another player. He Starts a blog in March 2003 to track his business adventures. A journalist VIP pass grants him earlier access to maps of the next update; he uses it to avoid the rush on new houses and buy 2 houses. Why keeping an uber house worth $600? I wanted to be envied. He accepts to share his house with a 17 year old kid, who sells IG some items for him and brings him a small profit. Unusual/weird "friendship". He plans to sell the other house for 30m gold, but a famous player on his shard asks for 20m and he accepts, honored and intimidated.

IG runebooks let players memorize places to teleport to them later on. Memorize all the mining spots in that book. Once the spots have been written in the first book, duplicating that book takes little time. Dibbell sells each book $3 on eBay. He quickly realizes this is too little profit for too much time spent. Some "rares", on the other hand, can sell on eBay for $75. Rares, along with other luxury items such as hair dyes or houses, are often only sold by NPCs to implement gold sinks.

Although virtual economies enable players to bond, when you get too deep into it, you're not a player anymore. The social aspects and the fusion with fiction disappear. Yet vendors of virtual gold are still immersed in some ways: Dibbell has no idea what he's doing at DiGRA or State of Play, talking about virtual economies and law, because he's more eager to live in [MMOs] than to understand them. He has self-doubt and wonders if the study of virtual economies has an intellectual substance about as substantive as pot smoke.

Scams and (lack of) protections:

  • Kids buy from their Mum's PayPal or credit card and receive the item within 15 mins. After a day or two, Mum reverts the transaction, but the player still has the item in his inventory, or even sold it to someone else.
  • Scammer advertises selling an item for half its market value. When buyer comes, the scammer sends him a link to a Paypal-looking phishing website in an email, and then empties the buyer's Paypal account.
  • A seller advertises a rare item. Using a thief character, another player goes to the seller's house, steals the item, and sells it IG or on eBay. Dibbell knowingly buys from the thief: in-game robbery is part of the game.
  • eBay and Paypal do not provide insurance over "intangible" goods. They provide insurance for soccer match tickets, presumably "tangible". Still, they say they can't insure a real paper ticket with a code written in real ink for virtual gold.

In 2004, the IRS said:

  • Declare as income anything you receive IRL, be it work of art, real dollars, or virtual gold. Illegal income such as stolen or embezzled funds must be included [...] if from your self-employment activity
  • For normal players, prizes won in lucky number drawing must be included in your income at their fair market value
  • Organizations that facilitate the trading of goods and services, such as OSI with virtual gold, should send tax forms to and withheld taxes from its players.

In 2005, an IRS specialist on the phone said there's no legislation yet on Internet barters or virtual economies.

UO vendors

IRL, dozens of monetary startups create "fake" money. E-gold backs their virtual currency with real gold stored in private vaults. An artist draws custom dollars and sells them, as art pieces, for more than their face value. Dibbell: We live in an age of money hackers. Make-believe [is] required to establish monetary value.

Blacksnow Interactive is located in Orange County. Business model: gold farm of 8 Mexicans in Tijuana, Mexico, paid $19/day, generate $30k profits per month. They play according to scripts given to them daily by their on-site supervisor. $800k sitting in inventory. Blacksnow trialed Mythic after they asked eBay to shut down Blacksnow's DAoC's gold auctions. Too bad Blacksnow vanished after being trialed by another game company, because justice would have had to determine who owns the IG wealth: players who spend the time, or companies who make and own the games?

Bob Kiblinger used to work as a chemist with decent pay. After playing UO nights and weekend, his wife divorced him. He bought and resold Troy Stolle's tower to Dibbell. Bob is a popular broker with 10k+ ratings on eBay. Has list of furnishers for each shard on IM. Spends 14 hours per day trading accounts and items. Belongs to the Markee Dragon conglomerate of the top 7 UO brokers. Markee Dragon provides server transfer, lets you pay your game time by gold instead of real dollars (they own the account and pay it for you), and brokers IG gold. Markee Dragon's ethics say: don't buy from bot farmers because they cheat. In 3 months of 2003, Dibbell bought $3700 of discounted gold from bot farmers, so he felt kind of unethical. Later, Rich the bot farmer gave him the list of his top 10 clients for 2003: Dibbell is 10th, all Markee Dragons belong to the top10, and number one is Bob who bought a total of $35k of gold in 2003.
Lesson: you need to buy from bot farmers to make a living in the US as a gold broker.

Using DeepAnalysis, an eBay market research tool, gives the market state and the list of vendors in a particular eBay category:

  • Weekly sales of UO items and accounts: $160k
  • Yearly sales of UO items and accounts: $4.2M
  • Change rate: $16 for 1M gold

And there are other sources of revenue for vendors that are not visible on eBay:

  • buy whole accounts for $300 and sell all the items in them for a total of $1200 = 400% profit
  • IG gold suppliers run big malls
  • A Guild has the monopoly on mining spots in a shard. Its guild leader sells gold to his broker.
  • Camp houses that will soon be re-opened for sale because their owner has not logged in for a long time. Can be done with a bot. Then resell houses for a lot of gold or dollars.

Working for Bob, in a solitary and obsessive interlude of 3 weeks in mid 2003, Dibbell made $1100 of sales by taking his share on buying and delivering suits on his shard. In the next 3 weeks, he only dedicated 2h/day selling packs of 100k or 1m gold and suits on eBay or to Bob. His sales remained around $850 per week. On average, brokers make 20% profit from their sales. After 3 months, Dibbell made $800 profits and ranked 65th out of 800 in terms of sales of eBay UO vendors. Bob is ranked first with $8k sales and $2k profits per week. Dibbell compiled those results thanks to the DeepAnalysis tool.

Gordon, a Cantonese exec, just opened a 10-man gold farm. He asks for partnership with Dibbell and Bob: his farmers would bring items that Dibbell and Bob sell to clients, and they all share profits. Predictions of $1600 sales per week. Gordon says he pays his farmers $1.5/hour and they can generate $5/hour. However, a NYTimes article in 2005 revealed that Chinese farmers are usually paid $75/months in 12-hour shifts, ie less than 30 cents/hour. Anyway, Gordon never generated the profits he mentioned. However, Dibbell, on a road-trip from Indiana to California, reached a max of $1k/week of profit for 4 weeks, mostly only selling 1m gold packs.

Bot Farmers

The game allows the use of a macro API provided players stay in front of the screen. Bots use macros on exploits such as 1) buy clothes from NPC 2) tear down clothes into tissue using basic tailoring skill and macro 3) sell tissue for more than the clothes. This technique generates 350k gold per hour. A Georgia man used it and amassed 20b gold, ie $300k. The total wealth of UO on all English shards was estimated at 35b, hence huge inflation wave coming up and detected by GMs. OSI fixed the exploit and wiped the extra gold by banning the bots.

Richard Thurman: 30 year-old software engineer. Leads the hacker group who developed EasyUO, a UO bot program. Rich's bots on 20 machines brought him 60k gold per hour using cartography exploits. Competitors denounced him to GMs and he was banned. Came up with a more defensive strategy: 1) eBay is too risky, hence build network of IG wholesale gold buyers. They get gold for 40% less than the eBay price. 2) to check for bots, GM wear a colored stick and ask the player "what's the color?". The bots would IM or SMS Rich when they were faced with a GM, and receive text to say to the GM by IM or SMS from Rich. 3) Plug A.L.I.C.E so that bots talk by themselves.

Blacksnow's leader and Rich meet in October 2003. Blacksnow proposes to agree on gold prices in return of receiving a dll used by EasyUO. Rich says it belongs to his group and refuses. Blacksnow discovers the hacker group had been blackmailed in the past by a player and had had to give the dll to the blackmailer. Pissed, Blacksnow reports Rich's bots to GMs.

An updtate from OSI on the merchant NPCs implements an offer-and-demand scheme, but assumes that players won't buy more than 500 items. Rich and another bot farmer find the glitch: buy 2k items at a time, the NPC believes you only bought 500 so the price does not increase as much, then resell the 2k items for small profit. Bot farmers use the exploit for a while, making millions of gold per hour. Blacksnow finds out they're making a lot and blackmails them for their technique against not denouncing them to GMs. The 2 farmers decide to stop their scheme and tell OSI about the exploit so that no other benefits from it. They made a total of $150k profit from 20b gold.



PS: Dibbell thinks that designing a single-shard MMO for 100k players is an impossible dream, and that's why MMOs stay sharded.

10 May 2010

[Literature] Digital Imaginaries: How We Know What We (Think We) Know about Chinese Gold Farming

In "Digital Imaginaries: How We Know What We (Think We) Know about Chinese Gold Farming (forthcoming in the June edition of firstmonday), Nardi and Kow first introduce what RMT consists of from the perspective of companies, players and gold farmers. They remark: It is no more or less strange to buy an item such as a piece of jewelry in Second Life, or Merlin's Robe in World of Warcraft, than to purchase a game of checkers, or a book (certainly a virtual experience) or really, anything we could think of that someone values enough to pay for.

The gold-farmer digital imaginary

Stereotypes are based on an intersubjective reality: we encounter people who are members of the stereotyped class, rather than imagining distant Others. Digital imaginaries are built through images, not actual individuals. Since we lack practical contact with the Others we are imagining, visuals concretize them.

The methods followed by journalists or researchers in their studies of gold farmers are seldom mentioned. As shown in the network graph above, only four authors have been to China, and two have conducted long-distance interviews with gold farmers. In 2008, Heeks guessed/estimated: There is a generalized assumption that the great majority of gold farmers are based in China. In the absence of any better evidence, we will go along with this and guesstimate that China has around 80-85% of employment and output in this sub-sector. The digital imaginary is based on these few sources. These sources do not bring a whole picture of the issue, but rather comfort the general stance taken about gold farmers.

Some videos of players proving they kill gold farmers can be found on YouTube. The Ni-Hao video conveys the player issues with gold farming. Nakamura analyzed the video and remarked that attacks are directed towards the Chinese culture itself:

Where did all the doggies and kitty cats go
Since the gold farmers started to show
Don't want to know what's in the egg roll.

Dibbel first coined virtual sweat shop as the place where the gold-farmer's life presumably takes place. In the digital imaginary, gold farmers receive low wages (10 cents an hour's good money when you are Chinese) for long days of work (12-hour shifts) and live in poor conditions. These conditions describe playbor, work that is also play.

A broader picture

Botting is often omitted from the imaginary of the Chinese gold farmers. Gold farming is supposed to be a dumb and repetitive work, not developing and using complex softwares. However, ubuy8.com, a consulting company, advised that gold farming companies invest 20-30 percent of their income on R&D [...] allocated toward the development of specialized bots, moving away from less effective generic bots. As the authors note, Botting does not play well with the notion of the virtual sweatshop.

The forensic analysis of the digital imaginary analyzed how and why Chinese gold farming is perceived as low-tech work-as-play. This digital imaginary persists for two reasons. First, the real-life anxiety and doubt that Third-World countries are getting more and more powerful. This fear is accentuated when Western players meet Third-World workers in the game: strangers invade paradise. Second, the complexity of hyperlinks establishes connections that lend confidence and assurance to the materials they propagate. Actually, there are only too few reliable sources still available.

Some contributors to the digital imaginary presume that gold farmers are actually farmers in real-life. The authors explain that Eighteen year old boys are not generally members of any specific workforce, and certainly they are not “farmers”—a difficult profession requiring the accumulation of years of expertise. People are nevertheless fascinated by the gold farming phenomenon. Gold farming is a mirror that reflects us back to ourselves as culturally superior.

13 February 2010

[Conf] Regulating Today for Tomorrow's New Technologies

Last Wednesday (ie on February 10th 2010), Han Somsen talked about "Regulating Today for Tomorrow's New Technologies: The Challenge of Connecting Regulation to Technological Realities" at the UCI School of Law. Somsen is a Dutch researcher at the TILT of Tilburg University and an expert in the areas of biotechnology and environment regulation. In his talk, he managed not to focus too much on bioechnologies but more on the regulation issues of new technologies in a broad sense. From a MMOG perspective, this (great) talk brought a lot of interesting points.
Do MMOG worlds need to be regulated? Unlike traditional single-player games, MMOG gather thousands of players in the same virtual places. Hence, in order to prevent their virtual worlds to collapse in chaos, I think MMOG need regulations. My comments are [in square brackets].

Regulators have three ways to regulate A (A = anything that can be regulated) [for MMOG: bots, trade, leading a guild, ...] [regulators can be Game Masters: hunting bots, game devs: implementing an anti-bot system, game designers: designing the game actions so that a bot can not do them, etc.]

What the regulators can sayWhat enforces the regulation[Examples in MMOG]
A is morally badsociety[bot, cheat, exploit, hack, corpse camping]
A is not in your interest
or A is useless/stupid
market and law[weird character builds, tradeskills, AH]
A is impossiblecode, encryption [or conceptual design][teleportation at will anywhere in the world, changing the public transportation destinations, destroying buildings, infinite inventory]

How can regulatees accept regulation? New governance can be a solution if adaptive mechanisms can be found to keep the machine running by itself and not crash. [As seen in the diagram, MMOG lack clearly-defined third-party actors. Are they game journalists? Add-on/Mod communities? Hackers??] [However: MMOG are games, and games can be artful. Art does not need third-party actors and new governance models at all, it is delivered to the end-user as it is. But MMOG gather so many people that they need a regulation of some sort.]

Conditions sine quibus none:

  • all parties have to agree on the goals [we do not want cheaters/bots]
  • Name and shame policies are unlikely to word, and sometimes regulatees do not have a reputation to loose [you never see "Dude987 was a bot!" in the news of MMOG websites for this reason, and also because there are too many bots banned at a time]
  • communities must be mature

Sources of regulatory ineffectiveness
Regulators can be unclear about their goals [why do you enable a certain add-on/macro API function if you know it might be used to automatize actions that should not be automatically done?]. Regulators have to monitor efficiently [is everything logged?]. If the system fails, regulators must have backup/repair procedures [can you use a load-balancer strategy to host the map servers?].
Regulatees can try to resist the regulation a priori or a posteriori, or they can or comply only in the spirit of avoidance (this quote is taken from the paper from Brownsword and Somsen entitled Law, Innovation and Technology: Before We Fast Forward — A Forum for Debate).
And obviously, external factors (ie neither regulators nor regulatees) can threaten the regulatory system.

Questions raised: Does the introduced framework connect all parties? How do we keep parties connected? If there is a disconnection, should we reconnect?
Hints: The more vague your words are in the law, the more breathing space justice has in court judgements. But this solution relies on courts and legal precedents, not on law. More formal laws need to be updated more often and consume much more time. We have to think about what happens if we change our laws or policies, and what happens if we do not change them. Cooperation, education and persuasion are more effective than coercion. The more you educate people, the more cirtical they become [WoW Threat Meter used to be an empirical add-on and became provided within the game by Blizzard with the 3.0 update]. Better say "I do not know" than nothing [hmm... I do not know if this one always prevails in MMOG].

Sometimes it is hard to subscribe both to global values (human rights, WTO) and local values (EU, cultural differences) [global = MMOG should be fun, local = Hardcore versus Casual, Asian may prefer XP grinding and hardcore PvP versus Western players prefer PvE? Asian and Western do not see virtual property the same way].

Edited on February 22nd 2010 to add regulatees sources of effectiveness