Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Table of Contents
ConG allows for complex matching and grouping configurations and population games.
- Every subject in ConG is assigned to a single group. In arbitrary matching and grouping (see bottom of the page) this assigned group is one's "population".
- Subjects have a "matched" group.
- The payoff function for a given subject uses as input:
- The strategy set of the subject's group.
- The strategy set of the "matched" group.
- groupSize - If this field is set, groups are formed with N = groupSize individuals in each group. Note that this requires the number of subjects participating in a session to be evenly divisible by the groupSize number (e.g. a groupSize of 4 supports 4, 8, 12, etc. subjects in the session - and will fail with 11 subjects).
numGroups - As an alternative to groupSize one may choose a setting for numGroup. If set, N = numGroups are formed. For example, if 12 subjects are connected and N = 2, 2 groups of 6 subjects each will be created.
- Important Note - groupSize & numGroups may NEVER be used in the SAME period definition row. [confusion#Grouping|See]]
- matchType (either "self" or "pair") - this field defines how groups (which are defined by the fields above) are matched with one another.
- self - With matchType=self the "matched" group will be the same as one's own group. Subjects in a group will play against the actions of players in their own group in a manner defined by the payoff function. This is used in (e.g.) Public Goods games, where all subjects in a given group compete against the actions of counterpart subjects in that group.
- pair - Matchings will be assigned in bi-directional pairs, for example group A matched with group B and group B matched with group A. This is used in (e.g.) the Hawk-Dove game to create two populations matched against each other.
Pairs (E.g. Prisoner's Dilemma)
Below is an html table abstraction of the portion of your .CSV config file needed for the pairs grouping.
|... preceding config file fields ...||groupSize||matchType||...additional config file columns...|
|.... preceding config file fields ....||1||pair||...additional config file columns...|
The payoff for player 1 is a function of player 1's group strategy set and player 6's group strategy set.
Number of Subjects Participating in an Experiment, and Group Size. Here, your experiment needs to have an even number of subjects (with an odd number, one subject will be groupless and/or some error will occur). Each subject will be placed into a one-person group, and matched with another individual. Subjects are paired off into two-player games. One's payoffs are a function of one's own action choice, and the choice of the player they are matched with. One example of this type of game is the two-person bi-matrix Prisoner's Dilemma game.
Randomization of Subjects. Between periods, subjects will be randomly assigned to new pair matchings. ConG does this automatically before each period. If needed, the experiment output Ticks file will log to which group and matching subjects were assigned. Should an experimenter have a specific matching/grouping requirement (e.g. a block randomization, or a need to keep subjects in the same group), they are able to do so via the "Arbitrary Grouping and Matching" configuration file settings noted below.
Below is an html table abstraction of the portion of your CSV config file needed for the following grouping.
|... preceding config file fields ...||numGroups||matchType||...additional config file columns...|
|... preceding config file fields ...||1||self||...additional config file columns...|
The payoff for player 1 is a function of the action profile of player 1's group
Here, all subjects in the experiment are placed in one large group. They choose a strategy, but their payoffs are a function of all player's action choice. This is a one-population game ala this hawk-dove's treatment.
Two Population (E.g. Hawk-Dove)
Below is an html table abstraction of the portion of your .CSV config file needed for the following grouping.
|... preceding config file fields ...||numGroups||matchType||...additional config file columns...|
|... preceding config file fields ...||2||pair||...additional config file columns...|
The payoff for player 1 is a function of both group strategy sets.
The full functional form depends on the payoff function used. (For example, the hawk-dove two-players-paired game starts with the symmetric 2x2 matrix payoffs in which payoffs are a function of two actions, one's own action and the action of one's match -- in the two-population setting, an individual's flow payoffs are calculated as one's own action choice against the average of the other matched group's action. That is, own vs. average of matched group. But another payoff function may have some different arrangement.)
Should you want full control over how subjects are matched, (e.g. ensuring subjects are matched with another once, or allowing for randomization of subjects blocks or silos of subjects), ConG also allows for arbitrary grouping and matching. Via ConG's configuration file, an experimenter can finely detail subject-by-subject, period-by-period group and matching assignments. The figure below is a screen capture of a .CSV file from an experiment using the arbitrary matching and grouping feature.
Discussion of Screen Capture - The file above is borrowed and modified from a Hotelling spatial competition game using the scripted payoff function feature (note the "payoffFunction" and "source" columns), but you can apply this example to other games as well.
This configuration file is for a six player game. First, note that the first four rows reflect the basic use of the configuration file discussed throughout this documentation website - without any odd group and matching assignment. (In fact, if the configuration file were limited to the first four rows - and assuming the script payoff function the config file uses were implemented correctly - then the config file would run an experiment just fine by itself.)
- "assignedGroups" - Note that in the top period definition rows, there is an "assignedGroups" column, set to TRUE.
Note the other glaring difference between basic configuration and this one starting at row 5, which has the single cell "#SUBJECTS". Given the configuration file has this row following the basic per period experiment definition, then when ConG reads the configuration file it will look to the rows and columns below for period-by-period, subject-by-subject definitions.
Periods 1 & 2. - Looking at rows 7-18, subjects 1 through 3 are placed into a group (population=1) and matched with their own group (match=1) - making a single population, match-type: self game (discussed above). Similarly, subjects 4-6 are placed into a different self-matched group.
Period 3. - Subjects 1-3 do not interact with subjects 4-6 until period three. Period three is a two population game, note that subjects 1 through 3 are placed in one group (population=1) and matched with group 2. Group 2 (population=2) is formed by players 4-6, and matched with group 1.
Whether or not a particular grouping and matching of players makes sense (or works at all) depends on the game, and the payoff function informing player payoffs. For example, this config file is borrowed and modified from a Hotelling spatial competition game -- this period would set one's action choices against the three player's of the other group. While at the same time, players in the second group are playing indivually against the three players of group one. While period three's grouping and matching setting is certainly interesting and fun to watch, it doesn't make much sense in the context of typical Hotelling games.
Which terminal is "Subject 1", who is "Subject 2"? - Subject numbers are assigned to actual experiment participants by the order in which subjects log into their client window. That is, when an experimenter starts a ConG session, their first step is to select the number of subjects (this must match the number of subjects in the configuration file) and start up their client windows. When subjects are seated at their terminal, as the ConG session is initiated, client windows will query a username (a username linked to the payoffs log produced at the end of the session). The first user to log in is given the assignment of subject 1. The second to log in is subject 2, and so forth.
Should the subject-by-subject definitions (of rows 7-24) contradict the period definitions (of rows 2-4), then the lower per-subject row definitions override those above. For example, the column "name" (column M) is labeled "foo" in rows 2-4, but certain periods and subjects have different text under the "name" column. Period 3 has the text "3p-2pop" under the name column, therefore the ticks experimental output file will list under the "name" for period 3 "3p-2pop". Again, when arbitrary matching and grouping is used, the subject-by-subject column fields take precedence over the field entries above.
Experimenters may also use the configuration file to do block randomization of subjects. In the screen capture below, note the "name" column, and how subjects are matched with one another. Subjects 1-4 are assigned to the first block in the name column, and randomly matched into pairs each period. Similarly, subjects 5-8 are placed into another block, and randomly reassigned into pairs each period.
- Block randomization must be done manually. The experimenter must choose how subjects are "randomly assigned" - the config file below simply cycles through possible permutations. But note that subjects 1-4 never interact with subjects 5-8. - Note also that the specific matching and grouping assignments you'll need will depend on the payoff function used in the experiment. For example, the symmetric 2x2 matrix prisoner's dilemma game below has subjects placed into one-person groups, and matched with other individuals. Thus randomization here requires permutations of a group of four into pairs. However, other payoff functions may require a different methodology, which will depend entirely on the game you are implementing. - The "name" column offers an excellent way to organize your Ticks file output data when using arbitrarily matching and grouping of subjects. The field under the "name" column may contain any string (though, do not use commas in the name column, since these will interfere with reading the .csv file). If you are careful that you "name" each group, period, and block in a systematic way (for example below), then sub-setting your data based on the name column becomes a good way to keep your output data - the ticks file - well organized.