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: http://game.ComplexLab.org. Keep in mind that this is a first prototype. It will be evolving constantly and there is no guaranty of service.
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:
The main loop of the server program would look like this:
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.
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:
There are several issues with this type of architecture that need to be adressed:
Most gaming architectures are hybrids of client-server and peer-to-peer.
Farmer at all  proposed a number of gaming scenarios:
To be continued.