14 April 2012

FPS, RTS, and fighting playstyles

Summaries of player types from gamerdna.com. Even though there is no scientific basis in those types, they show various types of gameplay and players to keep in mind when designing a game.

Multiplayer FPS playstyles

Support sniper protecting critical places or healer/supplier.
Commander strategist, guide.
Recon strike when least expected. Crafty, fast, sneaky, behind enemy lines.
Shock Trooper frontal attack

RTS playstyles

Rusher fast, micromanagement, keyboard shortcuts, predict and counter-attack opponent
Strategist thinker more than a doer, big picture, game knowledge
Turtle build a fortress/maze. Max out the tech tree and prepare a big explosion to win.
Commander playful curiosity over optimality.

Fighting playstyles

Tactician thinking, mastering characters, out-maneuvering the opponent
Speed Demon quick, keep out of harm's way
Brute massive force
Loose Cannon unpredictable, go with the flow, take advantage of openings

13 April 2012

Using Social Psychology to Motivate Contributions to Online Communities - Beenen 2004

Notes from Using Social Psychology to Motivate Contributions to Online Communities, by Beenen et al. 2004

  • 830 respondents who rated rare movies on a movie recommendation website.
  • Theoretical framing: social loafing/free riding
  • Findings: the contribution of an individual may increase if:
    • his contribution seems unique to the group
    • specific benefits (ie individual-only or group-only) are not mentioned. The best is to not mention the benefits at all.
    • goals are specific
    • goals are framed for the group rather than for the individual
    • goals are challenging (but still within reach)


  • reasonable goals echoes intersubjective flow from Celia Pearce
  • In MMOs, tank, DPS, and healer are unique roles. Does that make them play more/better towards the group?

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].

08 April 2012

Gold buying patterns

Picks from a paper I wrote about gold buying patterns for FDG 2012. The data comes from an online questionnaire completed from March to May 2010 by 2800+ WoW players from around the world. Unless mentioned, all results are significant with a p-value below 0.01.

  • Overall, 14% of people have ever bought gold.
  • Men are twice more likely to buy gold than women (17% vs 8%), but there is no difference between Asians and Westerners.
  • Achievement increases the likelihood to buy gold, while immersion decreases it. The effect of achievement is stronger on men.
  • 12% of people who only play with people they know IRL have bought gold. This ratio increases to 15% for people who play with both RL relatives and friends made IG, and to 21% for people who play only with friends they made IG.
  • Overall, people who have taken longer breaks from the game are more likely to buy gold.
  • But really, it's a big mess to know which variables influence gold buying: in the correlation graph below, vertices represent variables, and edges bearing positive/negative values indicate positive/negative correlations between two variables. Values closer to 1 in absolute value indicate higher correlations.
  • That's where GLM come in handy: they account for interactions between variables in regressions from multiple variables.
  • Controlling for all other variables, the odds of buying gold increase when playing on a private server, being a man, having frozen one's subscription, having made friends IG, playing for achievement, and having played the game for a long time. On the other hand, the odds
  • Controlling for all other variables, the odds of buying gold decrease when having had a college education, playing for immersion or socializing, and playing with cousins, siblings, or spouse.

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.


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.

04 April 2012

Quests - Howard 2008

Quests: Design, Theory, and History in Games and Narratives by Jeff Howard, in 2008.

History of quest games
Year Game Innovations
1974 DnD GM as referee, quests taken from Celtic, Norse, and Arthurian mythologies.
1976 Adventure on computer, first RPG, network play
1983 King's Quest series cut scenes, music, multiple endings, optional puzzles, and side-quests.
1985 Ultima IV series virtues, colors, and classes are related
1986 Zelda series quest status screen shows the player's progress, first action-adventure game.
1999 EQ proliferating tasks rather than a single main quest
2004 WoW lore quests, the never-ending war theme is a bleak scenario not particularly conductive to meaningful gameplay: failing a quest is not problematic.


Campbell's "Hero's Journey" consists of separation, initiation, and return. The individual builds himself, as found in medieval romances. In games, the initiation phase is lengthened and repeated, since it has most action.

A quest is an action that is meaningful to a player. It's also called a "mission" in games with a modern setting.

Ludologically, a quest has goals and consists of searching a functional meaning: a key opens a door, therefore the player should look for a door. A sword kills monsters, therefore the player is expecting to encounter enemies soon. Once meaning is found, the quest is over.

Narratologically, a quest has a story. The story and the lore motivate and immerse the player in the task.

But actually, meaningful quests come from striking a balance between too much action and too much narrative, while keeping in mind the big picture of the game's meaning. Except for XP and loot, why is that quest important to the player? What satisfaction does the player get by doing that quest? Here are some clues:

  • Impact on the world: achievement, gaining power, learning about the lore, altering political or moral balance, or changing relationships with NPCs
  • Back story: motivation to learn what happened before or what is going to happen after the quest is over.
  • Lore: themes and ideas encoded within the world, such as religion, politics, landscape, objects, or challenges. "The world itself is the puzzle", and the player shows his opinions by playing the game.

Symbols should be tied to game mechanics. For example, in Ultima, completing a quest requires understanding the world's allegorical meanings: some colors are associated to a class and a quality (red = warrior = valor). Obtaining a part of a relic should open a door or provide a new power

In the end, the player may quest to make the plot progress, improve his avatar, or to try out fun gameplay. Ideally, a quest should combine the three, but it gets tricky in games where the player is allowed to pursue quests in the order he wants.


Both macro and micro levels should guide the player towards the general direction to go to. Both should create a sense of progression and convey a meaning by their layout.

Micro level: balancing exploration and challenge. Tiered spaces such as towers or crypts are easy to navigate: traveling towards the highest or lowest level ensures challenges and rewards. Mazes with a sort of structure also work. There should also be disorientation elements such as traps, secret doors, or dead-ends, as well as obstacles standing between the player and his goal.

Macro level: quest hubs. Hubs are known and relatively safe places such as cities or campgrounds where the player is given quests and has to return to complete them. Hubs are surrounded by several quest locations. WoW has breadcrumb quests to encourage exploration, but no main quest; that makes the world seem disconnected and episodic. See the Morrowind map: the player starts on the periphery of the world, and travels clockwise from hub to hub until Ghostgate at the center of the map for the final encounter.

Dreams within games create initiatory spaces: the avatar can be changed into an animal, a ghost, or an older self, but remains controlled by the player, increasing the sense of immersion in the non-dream game world.


Cf Propp's dramatis personae at the beginning of theater scripts: characters are not defined by their traits, but by their actions: villain, donor, helper, or hero.

Dialog: keep it short, and let players have choices. yes/no selections are too simple: add a reason to add meaning. Example: NPC says "Take this money as a reward to save my kids". Player should not simply be given "OK", or "accept"/"refuse", but rather "I don't need money to save kids" (which shifts the player's alignment to lawful good) or "You don't have to give me the money - I'm going to kill you myself" (evil, and eventually summons the guards).

One quest per NPC is rare in modern RPGs.

Quest types
Name Description
fetch find an object and return it to an NPC
delivery give an object to an NPC
dungeon crawl go to certain points of a dungeon - and get loot on the way
escort/protect usually an NPC, but could be a fellow player too
kill/combat the most loaded with meaning: killing a peasant is very different from killing a demon. Opponents have to be obstacles to the plot


Most objects that the player collects are useless (sold to NPCs for money) or functional (healing potion, armor). But certain objects can motivate quests if they are:

  • needed but missing,
  • loaded with symbols,
  • relatively powerful,
  • fun to use (eg cast a random skill),
  • with a distinct appearance (eg the Tatoos of Planescape Torment)

Sometimes, these objects only are MacGuffins: they are unimportant in themselves but motivate and unfold the plot.

The rod of seven parts: make a story from the whole and powerful artifact, break it apart, and spread the pieces around the world. The story follows naturally, and the players discover the meaning of the quest gradually. It also encourages exploration. Micro-level example: the 3-headed flail from the De'Arnise Hold in Baldur's Gate 2 requires the player to fully investigate the whole castle, and not just go directly to the boss.

There are varieties of ways the player can get an object: looted, forged, stolen, summoned by a sacrifice, or found in a chest at the bottom of a cave. But the way the player gets in possession of an object should give clues about using that object. Examples: a mace loot from a giant should require lots of strength. Frostmourne, given by the Lich King to trick Arthas the paladin, is obviously cursed.


Tie the quest presentation to the world map and the log book. The logs of completed quests must give clues about the next quests or where to find them.

Conflicting goals make interesting choices. For example, in Ultima IV, the avatar gains compassion points by not killing 'good' characters, and gain valor points by never backing down from a fight. Interesting choice arises when the player is attacked by a 'good' character. [But what the player chooses (ie the player's opinion) differs from why he was given the choice in the first place (ie the meaning of the game).]

See also: hero's journey.