26 August 2011

Human-Currency Interaction: Learning from Virtual Currency Use in China

Yang Wang and Scott Mainwaring, 
“Human-Currency Interaction”: Learning from Virtual Currency Use in China, 
CHI 2008
  • 50 semi-structured interviews on the use of RMT in China during Summer 2007. Respondents of all ages, playing WoW, Mir2, MapleStory ,Second Life and others.
  • Gateway currency = legally convert real money into IG time or currency: Q coin, WoW 66-hour play card. Game-specific currency = in-game gold.
  • Realness: students and young professionals consider gateway and game-specific currencies as both virtual and real. For older adults, the currencies are purely and solely virtual. Virtual currencies are dishonest, they are masquerading as an innocuous, too-easy-to-spend plaything, while in fact they represent a lot.
  • Trust: face-to-face cash transactions. Need to meet sellers/buyers in person to be sure they are doing their part => meet in a wang ba, both avatars and human beings face each other. Online trusted third-parties require credit card => not for kids. Face-to-face = hassle, but it's also fun to meet IRL other players.
  • Account sharing: Pros = with friends, try other characters. Cons = they can steal your stuff, you give them the password you use in many other applications, including RL ones (e.g. email). How to allow account sharing without compromising player security and privacy?
  • Fairness: small buyers ($10/month in RMT) find unfair that some players can spend 10-100 times more than them. Buying from other players is felt as less unfair, and seems to alter the game balance less, than buying from the game company.

25 August 2011

The life of the Chinese gold farmer

Notes from a June 2007 New York Times article about gold farming by Dibbell.

Julian Dibbell, June 2007, The Life of the Chinese Gold Farmer, 
  • 100k Chinese workers are involved in RMT. RMT market = $1.8 billion worldwide
  • 80 MMOs and 30M players worldwide. WoW brings $1bn/year to Blizzard.
  • The Gross Domestic Product of the MMO player population is between $7bn and $12bn.
  • The gold farming wang ba given as an example has 10 employees and generate $80k/year. 12-hour day/night shifts. Dormitories are in the second floor of the wang ba.
  • Farmers collect 25 gold/hour. For 100 golds, the farmer receives $1.25 by his boss, and the boss receives $3+ by the gold selling website which sells those 100 gold for up to $20.
  • After Blizzard banned 50k gold farmers, the exchange rate went from 6c/gold in Spring 2006 to 35c/gold in January 2007.
  • Differences between power levellers and gold farmers: bigger teams (25 per 12-hour shift), less sweat-shop-like, have a company tee-shirt/polo, team spirit, less ban (because they use the customer's account and act nearly like actual players). Some leave gold farming to power levelling to have more room to play for themselves. They like the game/work because playing WoW = learning. Some even buy gold because they don't have time to grind.
  • Raids have drops bound when picked. Therefore, gold farming/power levelling for high-end content is hard. Solution: make a guild, invite the customer in it, raid with him, and have him pick the loots when a boss is downed. Problem: too few customers buy it => cancelled.
  • Gold farmers too want to play.

22 August 2011

Blogroll v3

Below, the feeds currently in my Google Reader. There were 200+ feeds in January 2010 (around 150 items posted every day) and 99 feeds in September 2010 (40 items posted per day). I am now down to 77 feeds, and a total of 25 items to read every day.

I obtained this list by using a series of Notepad++ regexp on Reader's ODML list of feeds (this link will redirect to your own ODML, if you are using Reader).

Game Dev Blogs

Double Buffered
Gaffer on Games
Gamasutra Feature Articles
Game AI for Developers
GameDev.net - Latest Articles and Columns

MMO Gamers

Blessing of Kings
Stropp's World
That's a Terrible Idea
Uploads by TheDoddler

MMO Devs

Broken Toys
Creating Living Online Worlds
Derek's Blog on Games, Home Theater and Programming
Elder Game
Measuring Gameplay - article
Of Course I'll Play It!
Online Game Techniques
Psychochild's Blog
Scott Hartsman - Off the Record
T=Machine - MMOG development
Wolfshead Online

MMO Community Mgmt

Eating Bees
Emergent Future

Game Industry

Dernieres actualites business - JeuxOnLine
edge online keynotes
GamesIndustry.biz - News


Information Is Beautiful
The Big Picture

Mgmt and Marketing Games

Game Tycoon
MMO Tidbits
Virtual Goods Insider

Video Game Design Blogs

Applied Game Design
Click Nothing
Critical Gaming
Game Design Aspect of the Month
Game of Design
Lost Garden
Magical Wasteland
Mike Darga's Game Design Blog
Online Alchemy
Pixel Poppers
Raph's Website - Game talk
The Bottom Feeder

Academia CS and Game Design

Center for Computer Games & Virtual Worlds
Game Balance Concepts
IEEE Spectrum: Consumer Electronics
Teaching Game Design
The Ludologist
Virtual World Economics

Academia Psycho Socio

Game in Society
Games and Culture OnlineFirst Articles
Games and Culture recent issues
PARC PlayOn 2.0
Psy et Geek ;-)
Terra Nova
The Psychology of Video Games
Virtual Cultures

Academia Mess

Game Design Advance
Look In The Air
Metaverse Law
ScienceDaily: Video Game News
ScienceDaily: Virtual Reality News
Virtual Economy Research Network


Penny Arcade
Virtual Shackles

21 August 2011

MVC and game developers

MVC in software engineering

The model stores data, and runs domain-specific logic. An example of domain-specific logic in the banking domain is if customer's account is below zero, refuse withdrawals. The view gets data to display from the model. Some MVC have the view pull data from the model itself, others have the view notified by the model, and others have the controller tell the view to update itself. The controller receives and converts user inputs in actions understandable by the model. In web development, such as ASP.net or Java servlets, the controller picks which view is going to be displayed, and then the selected view is actually in charge of displaying information on the screen. If this description is not clear enough, the wikipedia page about MVC has a scenario that helps explain how the model, view and controller fit together.

MVC in games

Many amateur game developers say ideas from MVC can be applied to games but in general it is just a waste of time. For many, there is no such thing as game architecture: The only difference with classic MVC is that in a game, the graphics data, logic and game algorithm is fused together. Others argue that in a rapid prototyping context, where iterating is key, one should not waste time conceiving a modular/maintainable system, but rather focus on testing the game as fast as possible.

Many non-indie games are made with MVC in mind. Splitting data from presentation induces extra work on the code and managing slightly more objects in memory. However, this is exactly what allows an easier testing and debugging of mechanics, UI, and network components. In fact, MVC has been applied to game programming since at least 1998. A blogger at TigSource states that MVC can be applied in any part of a game. Taking the example of a network connection: The input view in this case is a network receiver running in it's own thread and listening for data from a socket. When the view receives data, it's translated into an internal class and sent to a controller for processing.

Middle ground

I find that explicitly implementing an MVC pattern for the network connection is a bit of an exaggeration. Heads-up displays and other UI input perfectly fit as controllers, and are naturally decoupled from the model. On the other hand, there is a strong tendency by many game developers to ignore software engineering practices. Some even put forward the Extreme Programming side of rapid prototyping to justify their ignorance of any architecture. Agile methods do not contradict the use of any architectural pattern.
That may explain why so many of pygame's projects contain a single file with thousands of lines of code ...

10 August 2011

[Literature] Fundamentals of Game Design, ch 12: Level Design

Level design = determine level's initial conditions, pacing (stressful or calm, genre-dependent) challenges, win/loss conditions, cut scene locations, aesthetics and mood (lighting, color palette, weather, special visual and audio effects, music, ambient audio), through tools.

Level design process

  1. Determine level features: events, objects, NPC
  2. Plan the gameplay: layout, challenge areas, win/lose conditions. Plan also the art: textures, styles, moods, ...
  3. Prototype: requires that the game engine is at least partially working. Use mockups to place triggers and document what sets triggers off (= rigging).
  4. Keep reviewing (with other people) and refining the level's size, pacing, objects, triggers, NPCs, and aesthetics.
  5. Hand off the level to the art team with requirements and documentation.
  6. Integrate visual and audio art assets, bug fix, and tune.


  • tutorial = included in the first levels of the actual game (not as a side) = hands-on learning. Start explaining the most used features one by one. Disable unused features to avoid confusing the player. Explain UI elements and point at them visually (blinking or glowing). Let player go back and try the tutorial examples again. Allow the tutorial to be skipped.
  • vary pacing within a level
  • after player surmounts resource-consuming challenges, player should be given resources to come back
  • avoid things that do not make sense/inconsistencies
  • scope: do not get too big, adapt levels to team's capacity
  • do not show all the challenges to in one level - introduce features gradually
  • know your audience
  • atypical levels should be optional: either they break suspension of disbelief or the challenges are foreign to the genre, and are therefore not exciting for players who like the genre. Atypical levels should be unlockable, hidden levels, or side missions, but not in the main progression.
  • inform player of short-term goals
  • be clear about risks, rewards, and consequences of decisions
  • reward for skill, imagination, intelligence and dedication
  • reward a lot, punish a little
  • The AI is here to lose
  • provide multiple difficulty settings
  • action games: vary the pace/players must be able to rest
  • strategy games: reward planning, give advantageous locations but let the player find them
  • RPG: allow character growth and player self-expression
  • sports: verisimilitude
  • vehicle: reward skillful maneuvers
  • construction and management sims: provide interesting variety of scenarios (= initial conditions and goals)
  • adventure: challenges consistent with their location and the story
  • artificial life: offer a lot of interactions between creature and environment
  • puzzle: give time to think

Layout patterns

Pattern Indications
open player's movement has no constraints
linear works well with linear stories
parallel works well with foldback stories, shortcuts possible
ring mostly only for racing games
network maze, good for explorers, hard to tell a story because the path is quite free. If all major spaces are connected, then exploration is easy: it's good for FPS deathmatches.
hub and spoke/star start at center, challenges and rewards in branches
combination many kinds of games!

01 August 2011

[Literature] Fundamentals of Game Design, ch 11: Balance

Balance deals with fairness as perceived by players, difficulty, and ensuring that skill (and not chance) is the main factor in player success. Players left-behind should be able to catch up. Stalemates should be avoided because they make some players feel like they played in vain (in other words, better players should always win). No sudden drops or peaks in difficulty. No sudden loss of the game without having previously given the player adequate information about his decisions. Respect genre: no logic puzzle inside a flight simulator.

Avoid dominant strategies

If entities are perfectly balanced and the player can see it obviously from the entities' external stats, then the game looks bland. Therefore, there should be shadow costs. Shadow costs are eventually learned by players after a while if they are not completely hidden. They should not be completely hidden, otherwise the player wonders why his performance fluctuates. More on shadow costs from Ian Schreiber.

Transitive relationships (A>B and B>C implies A>C) are good for player upgrades (sword A gives more atk than sword B). Intransitive relationships (rock paper scissors) are better with unequal costs and gains because players may take risks (and be rewarded for the risks taken). In fact, ideally, all units should be orthogonally different: they should differ in at least 2 dimensions, or have at least one capability that no other unit in the game has. Orthogonally different units prevent dominant strategies because all units are needed to reach the goal. Ex: in Chess, using the Queen only because she's the strongest is a losing strategy.


Chance can be used in frequent low risk and low-reward challenges. Allow the player to choose how much to risk. Skill is taking the good risks with enough information given: Poker players can decide to lose very little if they have a bad hand this turn: they do not bet much. Good luck cancels bad luck over time. In the end, skill makes the difference. Do not use chance for large issues unless the player knowingly takes the risk.


Symmetric PvP games can get boring: players end up using the same strategy. It can be hard for some symmetric games (Go or RTS) to have a non-cheating AI better than humans. Players accept a cheating AI (able to see units in fog of war, faster production, ...) in very hard mode, not in easy. Basically, the game becomes asymmetric when players accept a handicap.


See also Ian Schreiber's game balance class.

At least two factors are outside designer's control. Players have a previous experience acquired by playing similar games of the genre. Players have also a native talent (hand-eye coordination, reasoning, ...). Other factors that the designer can control to adjust the perceived difficulty are: intrinsic skill, stress, power provided and IG experience.

  • Absolute difficulty of a challenge = skill + stress required compared to the trivial case (static, harmless, one-shot-killed enemy in an FPS)
  • power provided = avatar's strength, subject to feedback loops. Ex: spell, powerful sword, HP, ...
  • relative difficulty = absolute difficulty - power provided.
  • IG experience = how often the player has been exposed to similar challenges throughout the game.
perceived difficulty = absolute difficulty - power provided - IG experience.

Problem with adaptive difficulty: player may learn to trick the AI in pretending to be bad throughout the game and play well at the very end to crush the AI. Moreover, finding a relevant success metric is sometimes hard. Adaptive difficulty should not be obvious to the player, otherwise it feels like patronizing. Adaptive difficulty can be used to make the game harder for players who choose it, though.

Positive feedback

Discourages stalemate and rewards success usefully (not just cosmetically). To control positive feedback,

  • Rewards should not be too big
  • increase absolute difficulty as player gains rewards, so that relative difficulty stays in control
  • allow players to team up against the leader
  • make victory conditions unrelated to player power
  • use chance to decrease player rewards (random loot, ...)


Stagnation happens when the player does not know what to do because she does not have enough information. Ex: finding a secret exit door hidden somewhere in a Doom level. To avoid stagnation, give hints.

Players should not have to waste time on trivialities (micromanagement) when they want to take higher-level decisions (strategic positioning of armies), unless they ask for it. Ideally, the game should let the player decide the levels she wants to be in charge of. Experts can choose to micromanage.

How to tune easily:

  • Factorize mechanics shared by multiple entities,
  • Modify one parameter at a time to see its effect,
  • To measure the effect of a parameter, double or halve it,
  • Keep track of the tuning done so far, so that you do not do the same tweak twice (saves time)