tapSquares is a game and ABM engine built to simplify the process of building a particular kind of game, and if of interest, generating an agent-based model from the behavioral data collected from gameplay.  

​

tapSquares games use a relatively well-bounded grammar, describing most game elements in short .csv files, with a dedicated space for more elaborate NetLogo code as necessary.  The broader structure of the game is baked into the interpreter - shared spaces that groups of players can interact with by tapping on patches to cycle through available actions.  A complete builder guide, along with examples, is available at our GitHub repository, linked below.

​

​​

​

​

​

​

​

​

​

​

​

​​

​

​

​​

​​

The tapSquares workflow - a simple grammar describes a world with actions; together with observed behaviors, that same grammar describes the ABM​

​​

​

The thinking behind tapSquares, and its place

​

tapSquares sits adjacent to, but is distinct from, the companion modelling (ComMod) tradition of participatory RPG–ABM coupling (Barreteau, Bousquet, and colleagues; commod.org). ComMod treats the process of co-constructing a role-playing game and its paired agent-based model with stakeholders as itself the primary output — each model is built anew, case by case, through iterative fieldwork, with the RPG and ABM refined against one another and against stakeholder input over repeated cycles. The model is a means to structure collective learning and negotiation, not a reusable artifact.

​

tapSquares instead standardizes and automates the infrastructure underneath that kind of work. One shared, config-driven game engine lets a researcher stand up a new multiplayer RPG across very different dilemmas without writing NetLogo code, and a paired R and ABM pipeline mechanically fits a behavioral model to logged play and generates an autonomous-agent version of the same game — collapsing what's usually a slow, bespoke RPG-to-ABM translation step into a repeatable one. It's a toolkit, not a participatory methodology in itself; it says nothing about how a game should be designed with stakeholders, only how quickly one can be built and turned into a working ABM once designed. Co-construction of the game itself with multiple actors is entirely possible within tapSquares — filling in its CSVs and rules is no less amenable to a participatory process than any other game design exercise — it just isn't the driver of the tool the way it is definitionally for ComMod, where co-construction with stakeholders is the method's central mechanism rather than an option alongside it.

​

One plausible extension is toward policy labs — higher-order games played among a different set of actors (officials or institutional representatives, say, rather than resource users), operating at a different scale than the underlying resource-use game. In CropRaider, for instance, game treatments varying the cost farmers face for non-lethal elephant deterrents generate behavioral evidence on deterrent uptake at different price points; that evidence could in principle calibrate a landscape-scale experiment — a policy lab — on the consequences of subsidizing deterrents at varying levels across a whole landscape, played by a different set of actors than the household-level game itself. tapSquares' infrastructure could support building shared understanding across actors working a problem at different scales this way, but that's a speculative use, not a designed-in feature of the pipeline as it stands.

​

Visit the tapSquares GitHub Repository

​

Sources

• The Companion Modelling approach

• Introduction to companion modeling and multi agent systems for INRM (Bousquet & Trébuil)

• Companion Modelling an introduction — ETH Zürich course notes (Anne Dray)