Early work on disciplinary-integrated games (DIGs) focused on Cartesian time-series analyses as the formal representations through which the game communicates challenges and opportunities to the players as well as the formal representations through which the players control the game. In our earlier work, we explored the potential generalizability of the DIG genre in terms of hypothetical examples in physics, biology, chemistry, and the social sciences as well as in terms of multiple model types including constraint-system analyses, system dynamics models, situation-action models, and agent-based models. In particular, Sengupta and Clark and Krinks, Sengupta, and Clark explored the integration of computational modeling, physical models, and Cartesian models. Building on that work, we began outlining theoretical frameworks and arguments highlighting the affordances of moving DIG design more deeply into agent-based modeling. In the current paper, we present the actual design process and rationale through which we developed prototypes of two multiplayer DIG prototypes with agent-based models as the mode of control wherein players create, trade, and elaborate on one another’s code as part of gameplay. We close with a discussion of implications for the design of disciplinary-integrated games leveraging agent-based modeling as the focal formal representation for communication and control.
- science education
- science as practice
- agent-based modeling
- disciplinary-integrated games
- digital games
Over the past decade, digital games have been the object of substantial research and interest for approaching the difficult task of reorganizing students’ conceptual resources [1, 2, 3]. Developing environments from Science as Practice perspectives [4, 5, 6, 7] that engage students in modeling would seem to hold great promise. Toward these goals, we have proposed Disciplinarily-Integrated Games as one such approach [8, 9]. As proposed in Clark et al. , disciplinary integration is an approach to designing games in terms of a science as practice perspective. More specifically, disciplinary integration can be thought of in terms of “model types” and “modeling strategies” , which Collins and colleagues have termed “epistemic forms” and “epistemic games” in earlier work [11, 12, 13]. Collins and colleagues argue that the professional work of scientists can be understood in terms of model types (epistemic forms) that are the target structures guiding scientific inquiry and modeling strategies (epistemic games) that are the sets of rules and strategies for creating, manipulating, and refining those model types.
DIGs are designed to engage students more deeply in specific modeling and representational practices of developing, interpreting, manipulating, and translating across specific model types. Essentially, all DIGs have the following characteristics: (a) formal representations for controlling the game, (b) formal representations for communicating challenges and opportunities, (c) a phenomenological representation presenting the phenomenon being modeled, (d) an intermediate aggregating representation, and (e) game mechanics and goals focused on engaging the player in interpreting, creating, modifying, and translating across these formal and phenomenological representations.
Early work on DIGs focused on Cartesian time-series analyses as the formal representations for communicating challenges and opportunities as well as the formal representations through which players control the game [8, 9]. To have value, the proposed DIG genre must be generalizable. In our earlier work, we explored this claim of generalizability in terms of hypothetical examples of DIGs in physics, biology, chemistry, and the social sciences as well as in terms of multiple model types including time-series analyses with Cartesian formal representations, constraint-system analyses with Cartesian formal representations, and other model types and non-Cartesian formal representations such as system dynamics models, situation-action models, and agent-based models . In particular, Sengupta and Clark  and Krinks et al.  explored the integration of computational modeling, physical models, and Cartesian models. Clark et al. [17, 18, 19] outlined theoretical frameworks and arguments highlighting the affordances of moving DIG design more deeply into agent-based modeling as the formal representational form through which the game communicates challenges and goals to players as well as the formal representational system through which players control the game. In the current paper, we present the actual design process through which we developed prototypes aligning with those ideas for SURGE Gameblox. More specifically, we introduce and describe the design process through which we developed two multiplayer DIG prototypes with agent-based models as the mode of communication and control wherein players create, trade, and elaborate on one another’s code as part of gameplay.
2. Technical design
2.1. Gameblox and Starlogo integration to create hybrid SURGE Gameblox
The current project, which we call SURGE Gameblox, is built upon the integration of two pre-existing robust programming environments for students. This process of integration to create the hybrid SURGE Gameblox environment was funded by the SURGE grant from the US National Science Foundation. Essentially, when the project began, there were two preexisting platforms that each had pieces of functionality that were required for the creating the models that we wanted students to modify. These two environments, Gameblox and Starlogo Nova, had been created under prior funding by the MIT Scheller Teacher Education Program. Gameblox is a blocks-based programming language that makes it easy to create 2D multiplayer games. Gameblox is targeted toward making games with a moderate number of sprites, often using a physics engine for games like platformers and mobile experiences including scavenger hunts and participatory models. Gameblox was not built to handle large models with hundreds of agents running simultaneously. Gameblox, however, already has a robust infrastructure for creating multiplayer games. There are blocks that allow for variables to be shared across multiple computers and updated in real time, procedures that can be called on a remote machine, and the ability to create separate instances of a game, allowing independent games to occur between multiple computers.
Starlogo Nova allows students to create 3D agent-based models by programming breeds using a blocks-based language. These agent-based models allow hundreds or thousands of agents to move simultaneously, with each following its own sets of programming instructions. While Starlogo Nova provides a system for handling the complex systems well, it did not have a way to easily connect two models together over a network.
After evaluating the complexity of integrating the two platforms, it was decided to take the 3D renderer from Starlogo and integrate it into the multiplayer framework of Gameblox to allow models to work across multiple computers.
When the project began, neither Gameblox nor Starlogo had support for allowing more than one user to edit a project at a time. Through a separate funding source, Gameblox was already working on multi-user collaboration in the editor, where two people can edit a project simultaneously, like Google docs. For the SURGE Gameblox project, we set up a separate server that contains this code, which allows users to work on only one block page. Gameblox projects are organized into block pages, similar to how large coding projects are separated into multiple files. The collaboration code is set up so that all editors can view the code on all of the block pages, but each editor can modify only one block page. The projects are set up in such a way that Player 1 can edit only Player 1’s code, but can view Player 2’s code as it is being changed. This functionality is central to how both the complex systems and physics model activities work.
3. Ecology complex system prototype design
When building this model, we wanted to build on the complex system models that have been developed over the years with Starlogo and to have the model include elements where students are reading data from graphs, using code to modify the model, and having the model meaningfully work across multiple devices.
3.1. Existing Starlogo models
We started by looking at Starlogo models that are used now for complex systems, with two exemplars being the colored butterflies and the fish and algae model. In both of these models, students are able to modify how the models run by changing the values on sliders that affect particular breeds and their environment. In the butterflies model, the sliders are used to set the initial conditions for the model. For the SURGE Gameblox project, however, the variability achieved in the models needs to occur through manipulation of code when the model is designed instead of through the on-screen widgets while the model is being run. In addition, given that many of the graphs students are reading occur over time, unlike the existing Starlogo models, it is important that values change throughout the running of the model as opposed to only during the setting of initial conditions.
An important functionality that we carried over from more complex models, like the fish and algae model, is the use of traits, properties that are associated with the instances of classes of objects that are used to store information about the agents as the model runs.
3.2. Prototype #1: Positioning plants to maximize animals on a farm
Players compete to get as many animals living on their farms as possible (Figure 1). The animals roam between the two farms, pause to eat grass, and get varying levels of energy from each type of grass. Each player programs how much grass of each type to add to his or her farm by reading graphs that inform the user how much energy each animal gets, and the percentage of type of animals in each level. Players have graphs of the seasonal changes in sunlight and rainfall. Each type of grass does better in different climate conditions. Players need to account for the seasonal changes represented in these graphs to maximize their populations. In our initial version of the prototype, we focused on a competitive structure for this prototype so that we could compare competitive and collaborative structures. The player who maintains the largest number of animals on his or her side wins (Figures 2 and 3).
The two largest pieces of feedback we received were that it was hard to know what location was best and that you could not react dynamically to weather changes.
3.3. Prototype #2: Generalizing rules from the graphs
The two main changes that occurred for the second version of the prototype were to (a) remove the position selection from the plant block, so all plants would generate in random locations and (b) include a block that would allow the player to get data from the graph about a particular point in time, as shown in Figure 4.
The addition of these changes allows the activity to be broken up into two parts. The first part of the activity is run similar to the first prototype, where different colored grass is placed randomly on the ground by choosing specific times to plant. The second part of the activity, however, allows for more complicated coding strategies, enabling the user to decide what to plant based on the values of the rainfall and sunlight instead of simply choosing static times.
3.4. Prototype #2: Next steps
The next iteration of the prototype will focus on revising features of the game activity structure to focus on a collaborative game rather than a competitive game. Our initial goals involved creating one competitive prototype (ecosystems) and one collaborative prototype (kinematics) to be able to explore the affordances and trade-offs between competition and collaboration. We therefore created the competition version of ecosystems first, but our ultimate commitments are toward building collaborative environments. Recent meta-analyses of digital games and learning suggest that collaborative structures tend to be more effective for learning [20, 21], and collaborative structures align very well with perspectives framing students as modelers [4, 5] and computational thinkers [22, 23]. As Kafai et al.  articulate, CT can and should be framed in terms collaborative design and production within communities. Therefore, while we believe that comparison analyses between competition and collaboration are of value, we ultimately think that the research and theoretical foundations around games for learning as well as computational participation and science as practice provide greater support for collaborative approaches.
4. Newtonian kinematics prototype design
We chose Newtonian kinematics as the domain for the second prototype, and we chose a collaborative structure. We made these choices so that we could compare differences in collaborative versus collaborative structures as well as compare across domains. When creating the physics model, we had three goals in mind: 1) students should use code to collaboratively modify the model based on reading graphs, 2) the model spans the screens on two computers, and 3) the graphs should describe a phenomenon in physics that students would study in class.
4.1. Prototype #1: Coloring cubes
Our first prototype had cubes moving based on speed vs. time graphs given to the player. The player needs to predict the location of the cube at a particular point in time.
Players work collaboratively to turn all of the moving cubes purple. Each of the cubes moves based on position or velocity graphs given to the students. Students then need to predict when the cubes will cross the center of screen. When the cube reaches the right side of one player’s screen, it will appear on the left-hand side of the other player’s screen. Player 1 uses the blocks to fire the red laser, which turns cubes red, and player 2 controls the blue laser. When a cube is already red and is hit by the blue laser, it turns purple. Players win by turning all of the cubes purple in the most efficient way (Figures 5–7).
The two largest problems that we noticed through testing this prototype were that (a) the prototype did not incentivize collaboration sufficiently, depending on the pairs working on it, and (b) the absence of numbers on the 3D renderer caused confusion.
4.2. Prototype #2: Moving across a marked line
Given that the underlying gameplay was not collaborative, we shifted to creating paper prototypes that would lead to better dynamics within the model. After several rounds of designing and playtesting various prototypes, the one described below became the starting point for the next digital version of the project.
Each player has a timeline and a graph. At the beginning of the game, the player learns where the ball should land at a particular time. In the figures, for example, the ball should be at x = 10 when t = 10. Player 1’s speed vs. time graph applies only when the ball starts moving on the line controlled by player 1 (when x is between 1 and 5). The same is true for player 2 (when x is between 6 and 10). Players can choose to add a “Speed Up” or a “Slow Down” when the ball starts moving on their part of the line. The “Speed Up” or “Slow Down” will increase or decrease the speed of the ball by 2 (Figures 8 and 9).
When testing the game, the three pieces of feedback we consistently saw were that (1) collaboration naturally occurred as both players were trying to solve the problem, (2) the game was harder than expected, and (3) there was confusion on how to read the graphs (Figure 10).
4.2.3. Moving to a digital prototype
While we were originally expecting to use the paper prototypes to simply test the interactions before moving to a digital version, testing demonstrated that working and coordinating on paper first was important to the learning experience, especially given the difficulty of the challenge. After the students believed they had found a solution of “speeds ups” and “slow downs,” we would provide them a sheet where each player would write his or her solution, like the one in Figure 12.
The students would then see a Gameblox model like the one below, which simulates the same scenario that they saw on paper (Figure 13).
Each player would then be presented with a limited set of blocks to program the “speed ups” and “slow downs” that they discovered from solving the paper version. If the students got the answer correct, then the dinosaur would arrive at the desired location after 10 seconds had passed. If not, then the students would know that their solutions were incorrect (Figure 14).
4.2.4. Expanding the game
After we had the basic mechanic of getting the ball to go to a particular location at a particular time, there were several changes we made to expand the work the players had already done, including graphing how the ball moves, and calculating the distance it covered.
4.2.5. Simplifying the experience
Finding the solution to the original problem we proposed took too long for all of our original testing teams and was discouraging to some teams. In order to create an easier on-ramp to the activity, we created a “Level 0,” which helps the students understand the mechanics of the problem though an easier set of graphs as shown in Figure 16.
The graphs are notable not only for having constant speed but also for having speeds that are two and above. Speeds that are two and greater mean that if a player uses a “Slow down,” then the speed will not be negative, which will eliminate possible confusion when calculating distance. Students would go through the entire process of the game with these simpler graphs (finding a solution, programming the solution, creating a combined speed graph, calculating the distance, and programming the distance), before doing the same activity with the more complex graphs.
4.2.6. Next steps for the kinematics prototype
Our sense is that the current structure of this prototype potentially focuses more heavily on a specific solution than we might like. Another related perspective on designing games for science education is the constructible authentic representations (CARs) perspective . CARs is highly related to the DIG perspective in that CARs focuses on (a) meaningful construction, (b) conceptually integrated primitives, and (c) authentic representations. One aspect that the CAR perspective emphasizes very heavily is the “sandbox” aspects of the game, in the sense of incentivizing more open-ended experimentation, than sometimes results in DIGs, where the puzzles at the heart of a level or game can be more focused. We would like for future versions of this prototype to be more “CARs-like” and we will explore structures that incentivize open-ended exploration to a greater degree than in the current prototype, and structures that may feel more game-like than the current prototype.
5. Implications and conclusions
To have value, the proposed DIG genre must be generalizable. As described in the introduction, our earlier work has discussed this claim of generalizability in terms of hypothetical examples of DIGs in physics, biology, chemistry, and the social sciences as well as in terms of multiple model types including time-series analyses with Cartesian formal representations, constraint-system analyses with Cartesian formal representations, and other model types and non-Cartesian formal representations such as system dynamics models, situation-action models, and agent-based models . Sengupta and Clark  and Krinks et al.  conducted our foundational work on integrating agent-based modeling into DIGs, and Clark et al. [17, 18, 19] have outlined theoretical frameworks and arguments highlighting the affordances of moving DIG design more deeply into agent-based modeling. In this current paper, we have presented the actual design process through which we developed prototypes aligning with those ideas for SURGE Gameblox. More specifically, we introduced and described the design process through which we developed two multiplayer DIG prototypes with agent-based modeling as the formal representational form through which the game communicates challenges and goals to players as well as the formal representational system through which players control the game.
We would argue that there are five main implications to draw from our work developing these two prototypes and the SURGE Gameblox environment. Each of these five implications focuses on different aspects and kinds of generalizability.
First, at the most basic level, these prototypes serve as proofs of concept that such games and environments are indeed technically possible. We certainly would not argue that these prototypes represent the only way that such games or environments might be structured, but these prototypes show the potential viability and possibilities of such games and environments.
Second, these prototypes demonstrate the generalizability of the multiplayer agent-based modeling DIG approach pedagogically. Ecosystems and kinematics as domains hail from different disciplines and represent very different kinds of agent-based models in the sense that the ecosystems models focus on complex system dynamics whereas the kinematics model focuses more on discrete systems of single agents. These two prototypes therefore suggest that pedagogically this approach can be generalized across multiple domains and types of systems.
Third, these prototypes demonstrate the generalizability of such an approach economically and pragmatically in the sense that both of these prototypes are built on top of the same core SURGE Gameblox environment. It is certainly true that SURGE Gameblox is built upon the robust infrastructure of MIT’s Gameblox and Starlogo Nova software environments, but the resulting hybrid SURGE Gameblox environment is indeed capable of supporting cost-effective and time-effective development of similar DIGs across multiple domains and topics.
Fourth, while the development of DIGs for new topics in disciplines can be cost-effective and time-effective, such development will still always require iterative refinement and testing through the design and development phases. Neither of the two prototypes was completed in the first round of development. Both prototypes required multiple rounds of development from their initial conceptualization to their current structure. Furthermore, the designs will benefit from multiple additional iterative rounds of design, testing, and refinement. This is more than just refining the software code. This iterative development and testing and refinement are also requisite parts of the design process for the activity structures themselves. As discussed in our recent meta-analysis of digital games for learning , this implication highlights the fact that design, rather than medium alone, determines the efficacy of a learning environment, whether it be a classroom lab, a textbook, a lecture, or a recreational digital game or a disciplinary-integrated game.
Fifth, and finally, these prototypes provide proof of concept for the broader DIG genre in terms of generalizability. While early work on DIGs focused on Newtonian kinematics with Cartesian timeseries analyses as the formal representations of control and communication, we have argued in our earlier work for the generalizability to other topics and formal representational systems [8, 14, 15]. These prototypes provide proofs of concept of such generalizability of the broader DIG conception of developing disciplinary-integrated games wherein manipulation and translation across formal representational systems provide the means of communication and control within the game as players engage in modeling and computational thinking from a science as practice perspective.
This material is based upon work supported by the National Science Foundation under Grant No. 1119290. Earlier development of Starlogo Nova was supported by the National Science Foundation under Grant No. 1508911 and 1639069. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.