The client, the server and the controller

CT Architecture

Colored Trails follows a client-server architecture. The server is a Java process that is responsible for centrally hosting the experiment's data and processes, and facilitate communication between the clients. Clients are GUI (for humans) or non-GUI (for computer agents) processes that can run on the same or on different machines on the network or over the internet. Each client needs to connect to a running instance of a server, by using the server machine's hostname or IP address.

Every experiment, no matter how different, is basically using the same client-server architecture. However, each experiment is different---the structure and special functionality for a particular experiment is defined in the configuration file. This is a Java class that defines (a) what the roles of the players represented by the connected clients will be, (b) how resources (chips) will be assigned to each player, (c) what the phases of the game will be and their duration, (d) how many rounds there will be in a game, (e) which moves (e.g., transferring chips, moving) are allowed in each phase, etc. CT thus allows the researcher to reuse the vast majority of the platform's functionality and limit his/her parameterization to a short configuration file. Moreover, since the configuration file is a Java class itself, it can easily connect to custom code that the researcher will develop for the needs of his/her experiment. For a detailed discussion of the structure of a typical configuration file, see here.

The controller is the final piece of the CT architecture and its usage is optional. It is however useful when a large pool of subjects needs to participate in an experiment. More specifically, if only a predefined set of people are going to play a game, the researcher can load the configuration file after the clients have connected to a running server instance. Many times, however, the researcher wants to pair groups (or triads, etc.) of people in random, and then possibly randomly re-pair them several times. This would require the researcher to monitor all clients, wait for them to finish, then manually re-pair them and start new games between the new pairs. The controller is an add-on function that automates this process. Moreover, the researcher has the option of pre-recording games with particular settings and have the controller feed the configuration file with specific parameters, so that all subjects are guaranteed to play the exact same sequence of games.