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

Scalability for Virtual Worlds - Gupta 2009

Scalability for Virtual Worlds, Gupta 2009

• Clients run the logic. Since server is only used for persistence and message forwarding, it can handle more clients.
• Problem: weak clients may not be able to execute all the updates they receive in a timely manner. Solution: action-based server-side IM: find the read/write sets each action impacts (transitive closure of the following actions), and notify concerned clients to rollback.
• Clients apply local actions to an optimistic model, and apply remote actions to a stable model. When applying the same action to optimistic and stable models, and the resulting models differ, need to rollback: the client asks the server to broadcast a fix it proposes. All other clients execute the fix, and if they conflict, send their own fix.
• Problem: solving long chains of conflict resolutions takes bandwidth and time. Solution: reject fix messages that cause a chain longer than a certain threshold.
• Experiment: 64 client machines running 1 bot each, moving every 300ms. When a bot collides into walls or another bot, it switches direction (more walls = more time to execute collision detection, more bots = more frequent conflicts). 1 server machine. Emulab with average latency between 2 machines of 238ms. Java.
• Good: Collision detection takes 7ms per action, while computing an action closure takes 0.04ms. Hence, a traditional server executing the logic lags after 30 bots, while the simply-forwarding server lags after 3000 bots.
• Bad: at least 20% extra bandwidth compared to server with logic. Drop 10% of actions to break long closure chains if bots are clustered together and move fast.