Announcements‎ > ‎

Econometric Multiplayer Game

posted Jun 24, 2011, 1:40 AM by Olaf Bochmann   [ updated Aug 8, 2011, 8:19 AM ]
In order to harvest behavioral patterns of market participants Doyne Farmer came up with the idea to use an agent based economic model in a gaming mode. The idea is to replace some or all of the artificial agents by real people. In a "war-gaming style" user of a multiplayer game will be able to develop an intuition for consequences of individual economic decisions in a dynamic interconnected gaming environment. The data can be used to understand human decision making. Behavioral information can be useful in calibrating econometric agent based models.
Clearly, it will be quite challenging to design a game engaging enough to draw the attention of the gaming community. Also there are serious doubts that the data can be used for a real world model, because behavioral patterns in a game environment seem to be quite different to behavior in reality. Nevertheless, I think the idea is interesting enough to give it a try. Below I will outline some architectural considerations of such a game. If you are just interested in playing the game you can go right here: Keep in mind that this is a first prototype. It will be evolving constantly and there is no guaranty of service.

Architecture of Multiplayer Games

At some point of the game the outcome of individual actions need to be synchronized among different computers/processes. In general, there are two common architectures for resolving arbitration: (1) client-server and (2) peer-to-peer. Client-server is conceptual simpler, easier to implement and better suited to generate game data. 


Each user of the game and each artificial agent runs a local client program. The client programs are connected to a central machine - the server program. The server program is maintaining the state of the game and is broadcasting this information to the individual clients. 
This design makes the server the bottleneck, both computational- and bandwidth-wise and it may turn out to be a serious scaling problem. On the other hand it is easy to maintain game state and access control.
The minimal example of a client program is a terminal. It transmits user inputs to the server and reports server messages to the user. The main loop of the client program would look like this:

while not done

   if user has typed any text

      send typed text to server

   if output from server exists

      print output

The main loop of the server program would look like this:

while not done

   for each user in world

      if input exists

         get user command

         execute user command

         log user command and world state

         tell user of the results

   simulate the world

   broadcast to all users

This is as simple as it can get. The client does not perform any simulation. It just performs input/output. MUD is a classic example of a client-server multiplayer game. You can connect to a MUD server using your local telnet program, a unix client or a Java applet.

Realtime Push Notification 

Ajax Push Engine (APE) is an open source realtime push notification system for streaming data to any browser using web standards only (Asynchronous JavaScript and XML (AJAX)). It includes a comet server and a Javascript Framework. Here is a demo that shows how APE can handle massive multi-user moving on a web page in real-time.
In a pear-to-pear system (P2P) each user of the game runs the same peer program, or at least groups of users run the same program. The peer program maintains the local state e.g. the position of the player. When moving, the peer program is also responsible for collision avoidance. Therefore, peers need to broadcast their state to other peers. A minimalistic example of a peer loop would look like this:

while not done

   collect player input

   collect network input about other player

   simulate player

      update player's state if informed it's been hit

      inform other peers if they've been hit

      move player

      log local state

      update other player state (ammo, armor, etc.)

   report player state to other clients

There are several issues with this type of architecture that need to be adressed:
  • connectivity: how to find and connect to nodes that are running peer programs somewhere in the network?
  • instability: nodes may go on and off all the time.
  • message routing: how to route messages between nodes, even if they are not directly known to each other?
  • searching: how to find information on other nodes?
  • security: peer programs can be hacked to report false states to other nodes.
Most gaming architectures are hybrids of client-server and peer-to-peer. 

Possible Gaming Scenarios

Farmer at all [1] proposed a number of gaming scenarios:
  • inter bank lending game: players represent banks that can borrow and lend to each other to cover their balance sheets (study the role of trust).
  • leverage cycle game: [Geanakoplos, 2009] design a more stable market (study role of leverage in generating financial crisis)
  • financial network game: design a financial feedback system
To be continued.