Background

In simple models of natural selection individuals are expected to be selfish and perform only those behaviors that benefit their fitness. Indeed, Darwin held similar ideas when he lamented that the altruistic and sterile workers of eusocial insects were his “one special difficulty” (Darwin [1859]). Despite the preliminary description of nature as ruthless, individuals such as Kropotkin ([1902]) recognized that cooperative behaviors, i.e. those behaviors that increase the fitness of other individuals (Lehmann and Keller [2006]), were common. Moreover, Maynard Smith and Szathmary ([1997]) argued that major evolutionary transitions such as multicellularity rely on cooperative behaviors between multiple entities. This commonness of cooperative behaviors challenged the assumptions of natural selection and necessitated a re-evaluation of the evolutionary framework. Using population genetics Hamilton ([1964]) formally defined the concept of inclusive fitness, demonstrating that individuals could reduce their own direct fitness so long as the fitness benefit to relatives compensated for the loss. Hamilton’s theory provided an explanation for how some cooperative behaviors can be maintained even though the behavior is relatively detrimental to their direct fitness.

Hamilton’s theoretical work was labeled ‘kin selection’ (Maynard Smith and Wynne-Edwards, [1964]), and has been invoked as an explanation for the maintenance of many cooperative behaviors (Sherman [1981]; Hughes et al. [2008]; Lukas and Clutton-Brock [2012]), including behaviors that maintain communal resources (Frank [1995]). Communal resources that benefit the entire group, yet can not be monopolized by one or a few individuals are known as `public goods’ (Rankin et al. [2007]). Since individuals can not exclude others from the public good, individuals who invest in the public good are at risk of having the investment exploited by uncooperative individuals (Rankin et al. [2007]; Bourke [2011]). The exploitation of public goods often leads to a collapse of the common resource resulting in a ‘tragedy of the commons’ (Hardin [1968]). The instability of public goods has generated considerable interest in delineating the mechanisms that can stabilize public goods, despite the risk of exploitation (Foster [2004]; Archetti and Scheuring [2010]). The maintenance of public goods has attracted researchers in biology, as well as in economics, sociology, and psychology (Hardin [1998]; Boyd et al. [2003]; Bowles [2006]). From this multidisciplinary research theoreticians have defined several mechanisms that can maintain the cooperative behaviors that maintain public goods, including kin selection, punishment, and generalized reciprocity (Boyd et al. [2010]; Barta et al. [2011]).

Public goods therefore represent an opportunity to teach students about behavior and evolution. Cooperative behavior is an especially useful topic to teach students because multiple evolutionary phenomena have been explored both theoretically and empirically in humans. Punishment (Fehr and Gachter [2002]), reciprocity/reputation mechanisms (Nowak and Sigmund [2005]; Jacquet et al. [2011]), and intergroup competition (Darwin [1871]; West et al. [2006]) are putative mechanisms that can maintain communal resources in human groups. This previous research therefore provides a framework that facilitates teaching students about how evolution can shape behavior, and specifically cooperative behavior. Students can learn about how the benefit of exploitation can erode cooperative behaviors, and subsequently how evolutionary mechanisms select for cooperation. I present here an interactive, public goods game that has been considerably modified from an interactive game provided by NetLogo (Wilensky [1999]). The original public goods game contained the framework for the game, but required a series of alterations before it was functional in the classroom. The redesigned program and the practices described below can help teach students about public goods phenomena and certain mechanisms that may maintain public goods (punishment and reputation). Thus, the interactive game can help expose students to basic concepts in behavior and evolution.

NetLogo is an open-source set of software that will run on Windows, Apple OS X, or Linux. The NetLogo software is designed with readable code and can be manipulated with ease. The NetLogo manual and other sources (Grimm and Railsback [2011]) provide an approachable introduction for using NetLogo. While there is other software that can run public goods games (see Z-tree, Fischbacher ([2007])), NetLogo has an active support community, is immediately downloadable, and is written for biologists. Therefore the programming commands are relevant to biologists and allow for modifications to the code that are useful for interactive biological games and simulations. NetLogo also provides additional interactive games and software that are relevant to biological phenomena in the basic download.

To run the interactive software, both the instructor and students need laptops or desktop computers that are connected to a WiFi network and running the same version of NetLogo. This interactive game was successfully implemented and tested using two sets of 25 students from an introductory animal behavior class (Additional file 1).

Game implementation

Appropriate student population

Students that participate in this exercise should have an understanding of certain concepts before beginning these exercises. Since this work relies on basic concepts of selection, students should understand the concepts of fitness and competition. Additionally, students should have at least a rudimentary background in talking about animal behavior and cooperative situations like the prisoner’s dilemma. Importantly, these public goods game exercises could be implemented at the end of an introductory course, or at any point in an upper-level animal behavior or evolution course. Therefore the range of usefulness of these games extends to students of many ages. Immediately before beginning the game, instructors should step the students through the basic mathematics of the game so that the students understand how the communal bank is divided during game play.

Game dynamics

The game presented here is similarly constructed to other public goods games where individuals invest money into a communal bank. In this game students have a certain amount of money in their bank. The student then decides what proportion of the bank to contribute to the public good (between 0 or 100%). The amount the student chooses to contribute will be entered into a communal cash pot of money and all of the investments into the communal cash pot are summed, and then doubled. After doubling the amount of cash in the communal pot, the communal pot is then divided evenly among all the participants, regardless of how much each participant had contributed. Thus, while it is best for the group if every participant invests 100% of their cash, it is always best for an individual to invest 0% since they will be relatively wealthier than the other participants. To gain a thorough understanding of the game dynamics, instructors may prefer to run a small-scale game by themselves using two to four laptops where the instructor controls each laptop and can explore the different scenarios (see below).

Incentives

For this practice to be effective students should try to acquire the most cash before the end of the simulation. To facilitate competition, the instructor may elect to give out a small amount of bonus points, or some other reward for the students that place near the top of the class (e.g. the top 1/3rd). The most useful system may be a payoff system with high resolution where the top scorer gets the maximum amount of bonus points, and students are then ranked and benefitted according to their final payoffs.

Setup

To begin, the instructor should download the latest version of NetLogo from the NetLogo website and install the software on the local hard drive. The instructor should then update Java© so that it is at least Java 6.0. The instructor can then download the public goods game and public goods client (described below) from either the author’s website (http://www.gavinmleighton.com/public-goods-interactive-game.html) or from the author’s page (GMLeighton) on the open agent-based modeling (ABM) consortium: www.openabm.org. After downloading the software, the public goods game file and the client file should be stored in the same folder on the local hard drive. The instructor should then open the downloaded game software using NetLogo. To have the data file from the game output to the desktop, the instructor should make a slight modification to the code so that the software prints the data to the correct location. Instructors should click on the “Code” button of the main screen (upper center), and find the line that begins with the file-open command. The file-open command is followed by the destination for the data file. For Mac OS users, instructors should type the following after the file-open command (including quotation marks), ““/Users/(user)/Desktop/PublicGoodsGameClassRoomData.txt”. Importantly, the (user) aspect should be replaced by the name of the user on the computer. Instructors will see "Leighton" listed in that slot in the basic download and can replace "Leighton" with their Mac OS username. For instructors operating Windows systems, the instructor would have to change the path to, "c:\Users\(user)\Desktop" and again change (user) to your local username on the computer.

Upon opening the downloaded software, the instructor will be given a prompt to start a session name, and should give a unique name to the session. The instructor should also click the box indicating that they would like to broadcast the game. After opening the simulation, the instructor should see a screen that contains multiple simulation outputs and a series of buttons that control game flow (Figure 1).

Figure 1
figure 1

The master screen that is displayed on the screen of the person hosting the simulation. The master screen controls game flow and helps visualize the dynamics of the game. A. Switch that removes the player names on the right hand display screen. B. Slider that sets the value of money punished individuals lose if punished by other players. C. Button that restarts the game and resets all values to initial values. D. Button that runs the entire step once (including Take Money and Give Money and Plotting) E. Button that retrieves money from students. F. Button to distribute money to students. Note, buttons associated with c and d are best used for demonstrating mathematics of game. G. Value of bank in previous step. H. Number of turns that have taken place. I. Plot of total punishment over time. Note that punishment is the cumulative punishment over time. J. Plot of communal bank over time. K. Plot of average investment of participants over time. L. Screen that lists all player names, their cash on hand, and how much they invested in the previous turn. A red square appears next to the richest player.

The instructor should either have the students to download NetLogo to their laptops or local computer, or have the students download NetLogo before the class begins. Alternatively, if the game is run in a computer lab the instructor may download NetLogo onto the computers for the students. Students will then open the "Hubnet" software that is found in the same folder as the NetLogo software.

Entering the public goods game environment

After the instructor has opened the game, students should open the "Hubnet" program on their laptops. Hubnet is a program that is downloaded with NetLogo and will allow the students to interact in the simulation. After opening Hubnet, students will be asked to enter a name they will have for themselves and they should also enter the IP address of the computer hosting the game. The IP address can be found on the screen that appears after the instructor successfully hosts the game. At this point, all of the students should be logged into the game that is being hosted by the instructor. The student screen will allow them to see how much cash they have accumulated, what the average amount of cash invested is, and the average proportion of cash invested in the communal bank (Figure 2). Additionally, the NetLogo screen portrayed in Figure 2 will display all participant's names, the amount of money the individual has, the proportion they invested in the previous turn, but will not display participant names if in the anonymous scenario (see below). In situations where the instructor has turned on labels, students will also be able to see the names of the other students and how much cash the other students have.

Figure 2
figure 2

The screen the participants will see after logging into the simulation being hosted. A. Player name. B. Button that allows player to punish the richest player. C. Average proportion invested by all participants in the simulation. D. The total bank from the previous turn. E. How much money the individual has. F. The slider the participant uses to dictate what proportion of their wealth to invest in the communal bank. G. The money the individual invested in the previous turn. H. The average cash invested by participants in the simulation. I. A screen showing other participants, their names, their total money, and how much they invested in the previous turn.

Suggested game scenarios

The suggested set of scenarios I present will step students through several mechanisms that are thought to maintain cooperation. Each of these scenarios will expose students to a concept in the evolution and maintenance of cooperative behavior. The instructor can visualize the findings two ways. First, the view from the instructor's screen can be projected onto a white board to show how cooperation changes in real time. Second, the instructor can cut and paste the values from the game that are output to the text file into an Excel spreadsheet and graph the investment in each of the three scenarios.

Scenario 1

Learning Goal: Demonstrate that anonymous interactions in public goods games hinder the maintenance of cooperative behavior.

Expected Outcome: As seen in other public goods games research, cooperative investment will start at relatively high values and will quickly erode as there is not a mechanism in place to enforce cooperation.

The first situation is the most basic, where there is total anonymity and no punishment. Here, the instructor will have to switch the "label’s-on?” switch to "off". When the game starts, only the amount of cash each of the students has will be displayed in the screen. This way, students can only compare the amount of cash they have and the amounts other students own without knowing which specific student has which specific dollar amount. The instructor can then run a certain number of steps (suggested is between 3-5 steps) where money is collected from the students, multiplied, and then redistributed. These three commands (collection, multiplication, and redistribution) can be performed by either: pressing the "Go" button once, or by pressing the "Take Money" and "Give money" buttons. After running the defined number of steps, the instructor can give students time to assess their relative standing and change the proportion of their cash they want to invest. While the instructor may choose to have students update the proportion they choose to invest while clicking through steps, providing a short amount of time would allow students to more accurately gauge their relative standing. Importantly, for this scenario and the following scenarios, the total number of steps, or iterations, should be known only to the instructor so as to avoid mass defection on the last step (Axelrod and Hamilton [1981]; Axelrod [1997]).

Scenario 2

Learning Goal: Demonstrate that introducing reputation can influence the maintenance of cooperative behavior.

Expected Outcome: Students will be able to visualize the names of other students on the screen and this will incorporate reputation effects. Since both the shame of not investing and the honor of investing a lot promote cooperation (Jacquet et al. [2011]), the average level of cooperation should be higher than in scenario 1.

In this scenario, the instructor can turn labels on from the main screen, so that students can now see the investment of other students in the group. This scenario will work best if students know each other before the simulation starts and can assign names to specific individuals. Scenario 2 is intended to teach how cooperation may be maintained by image scoring (Nowak and Sigmund [1998], [2005]). Additionally, if an instructor would like to focus on reputation and reciprocity, they may choose to allow students to form their own smaller groups after the entire population competes, as suggested in West et al. ([2006]). This would emphasize that students that want to attain the highest score would have to locate the most cooperative group members.

Scenario 3

Learning Goal: Demonstrate that self-policing can influence the maintenance of cooperative behavior.

Expected Outcome: The average level of cooperation will be higher than in scenario 1 because the richest student will be exposed to monetary punishment from peers. The high level of monetary punishment should induce higher levels of investment so as to avoid suffering punishment for extended periods of time from other players.

The third scenario can be implemented with or without names though the progression of scenarios listed here would suggest including names. At this point, the instructor can allow students to punish the richest player by clicking on the "Punish the richest player" button on the student's Hubnet windows (Figure 2). This scenario introduces self policing and may help stabilize some investment in the public good (Boyd et al. [2003]). As the game is set up now, the individual who punishes the richest player pays $1 to reduce the richest player's cash by the amount determined on the slider on the instructor's screen (Figure 1), though this can be changed in the code easily. Importantly, this button can be clicked multiple times and multiple individuals can punish the richest individual.

Scenario 4

Learning Goal: Demonstrate that a dedicated police force can influence the maintenance of cooperation.

Expected Outcome: Cooperation will be maintained at higher average levels than in scenario 1 and potentially scenario 3, as the instructor will definitely punish individuals that do not cooperate at specified levels. Since levels of punishment are unambiguous students will cooperatively invest more.

In the final scenario, the instructor can log into the simulation using Hubnet from their own computer to act as the dedicated police force. The instructor may set the rules, but an example is that the instructor will always contribute the average investment of the group so as to not outcompete the students. In contrast, the instructor may also vary their contribution to the group (i.e. invest 25% of the average proportion of students) so that the police force becomes costly for members, and observe this effect on the average levels of cooperation. The instructor can also specify the rule for when they will punish the richest player. For example, the instructor may state that they will punish the richest player only if the richest player contributed less than half of the group average investment. The goal of this scenario is to have a police force without having interacting individuals have to perform policing behaviors themselves.

Data output

Currently, the software will create an output file and place the file on the desktop given some minor code alterations (see Setup section above). After each step in the simulation, the software writes the average proportion of cash invested by the individuals in the simulation. This output allows the instructor to plot the average proportion invested after the simulation is over and use the data to potentially explain concepts to the students (see below).

Future directions

To help refine and improve the interactive game, a valuable next step would be to test if and how these games improved understanding of public goods and the maintenance of cooperation. Preliminary exercises using this software suggest that students are able to readily identify evolutionary mechanisms that can maintain cooperation (Leighton, unpublished data), though a more rigorous analysis is needed. Such analysis would allow instructors to further change how the game is implemented based on the intended learning goals. An additional and interesting test would be to perform these public goods games in classes of different sizes and examine the influence of punishment empirically. While variation in class size may yield insight into the effectiveness of punishment, instructors may also be interested in performing inter-group experiments within a single class. Intergroup competition has received both empirical support (West et al. [2006]) and theoretical support (Wilson and Wilson [2007]) as being able to support cooperation in humans. Therefore, instructors could perform the scenarios described above one day, and then break the class into groups of five students each and award points to the group that is able to acquire the largest communal bank after 10 rounds. The new balance between where within-group competition is reduced, along with increased group competition, should promote higher levels of cooperation in individuals (Bowles [2006]). Finally, instructors may be interested in varying the level of communication between students. For instance, communication in smaller groups may more effectively facilitate cooperation than allowing for communication between students in larger classes, i.e. 20+ students. Such scenarios would further underline the problem of trying to maintain public goods in large groups.

Given the myriad of public goods relevant to human society, e.g. CO2 emissions, vaccinations, group work in class, performance-enhancing drugs in major league sports, and group hunting, this set of games presents a tangible and relatable set of exercises for instructors to expose students to basic concepts in evolutionary biology.

Authors' contributions

GML conceived of the project, modified the agent-based model, and wrote the article.

Additional file