Articulating Social Issues with Open Data: Exploring a Game Jam Approach

Open data is any data can be freely accessed, shared, and reused [25]. In recent years, governments have made an effort to increase the amount of available datasets. Commonly available open datasets include public transport routes and timetables, maps (e.g. OpenStreetMaps), Wikipedia articles and images, air quality measurements, and election results, among others. However, releasing open data does not automatically yield benefits [16]. Reusing an open dataset requires technical knowledge - to clean the dataset and process it - as well as domain knowledge - to know which questions to ask and to extract valuable information. To realise the benefits of open data, someone needs to reuse the dataset in a meaningful way. In recent years, governments and other organisations have organised hackathons to incentivise the reuse of open data [28]. The term hackathon stands for hacking marathon [4], because participants hack (i.e. assemble) together a prototype in one to two days. The events usually end with a presentation of the prototypes, and selection of the winners. Open data hackathons have been identified as an approach to introduce available datasets to the public, and to find new ways of reusing them. The prototypes made at hackathons range from business model ideas, to app mockups, and product concepts. Hackathons usually end with a presentation of the results from each team, and a jury selecting the winners. Open data hackathons have started to shift from being tech-focused events designed around software development, to more open get-togethers welcoming the contributions of non-expert users [9]. Previous research found that the main value of hackathons is in creating communities, rather than in the technical solutions produced [4, 19]. Hackathon participants not only build and test new solutions, but also test new ways of collaborating together around shared ideas, providing a “unique networking opportunity” [4, p. 11]. Jaskiewicz et al. [17] similarly found that open data hackathons can contribute to community capacity building, with participants developing shared mental models around common issues. Hackathon participants interviewed by Jaskiewicz et al. [17, p. 23] stated that the most valuable outcome were “learning about other participants’ views, improving their ability to work in a diverse team, and gaining new perspectives on the city’s problems”. However, hackathons have also been criticised for being a solutionist approach, as we explain in the subsection that follows.

Solutionism is the oversimplification of an issue in order to justify a technological intervention [22]. Clary [6] argues that university hackathons are inevitably subjugated to neoliberal forces, with participants spending most of their efforts on creating captivating demos to impress the judges, in order to sell a product or a business idea. As observed by Lodato and DiSalvo [19, pp. 552-553], “the underlying controversies that comprise issues are, more often than not, simply not made present in hackathons”. This problem is convergent with the wider critique of solutionism in the design thinking approach. Design thinking often privileges social issues that “can at least be presented as ‘fixable’ on the surface” [29, p. 10], and avoids confronting wicked problems which cannot be solved with technology alone [29]. Another critique is that hackathons end up exploiting the free labour of participants [33]. Hackathons often have corporate sponsors, which offer participants using their software the possibility to win a monetary prize. With this type of sponsorship, businesses can benefit from the free labour of dozens of developers [33], who create an ecosystem around the sponsored product, learn how to use it, and showcase its potential. In summary, hackathons have a tendency to presume that problems are technological, which flattens the complexity of those problems, and prevents people from engaging in a deeper exploration. We acknowledge that open data hackathons have a variety of formats, objectives, and participants, and that not all of them can be considered solutionist. At the same time, the value of a hackathon also depends on the outcome being measured. The same hackathon could be considered solutionist if judged by the prototypes produced by participants, or not if judged by the networking and peer learning outcomes. As argued by Lodato and DiSalvo [19], in order to understand hackathons, we need to judge the opportunities they offer for “collective issue articulation” [19, p. 553], and look at processes such as “how groups are structured to accomplish tasks” or “who and what is present to enable work to be accomplished” [19, p. 555]. Still, asking participants to produce a solution seems to limit the space for issue articulation, and rather favours tinkering with technology. In developing our new approach, we looked for a different kind of objective, which can open up a wider space for issue articulation.

In looking for processes that can favour issue articulation in the context of hackathons, we found game-making (the process of making a game) as a possible way forward. As argued by Bogost [3, p. 119], video games can express procedural rhetoric, meaning they can “make claims about the world, which players can understand, evaluate, and deliberate”. Because of this, “when kids program, just as when they write, they can learn to make their own claims about the world in the form of processes” [3, p. 137], thus making video game development a rhetorical rather than technical practice [3]. Changing the main activity of open data events from app-making to game-making could open up more possibilities for issue articulation throughout an event. In the context of urban-scale issues, Schouten et al. [31, p. 28] argue that “making games about complex systems (e.g., urban environments) requires exploration and reflection, which in turn allows for a better understanding of the problem space” and call for further research into game jams. Game jams are in many ways similar to hackathons [7], with the key difference that participants make game prototypes together. In fact, they are sometimes referred to as “hackathons for video game development” [4, p. 3]. Falk [10, p. 12] similarly considers both hackathons and game jams as “accelerated design processes” which can be studied together, rather than separately. Other scholars, however, argue that game jams and hackathons are fundamentally different. Grace [12] argues that, while game jams emphasize “a state and process”, hackathons focus on “a measurable result standardized by a shared sense of competition” [12, p. 45]. To understand whether game jams can be an effective approach to articulate societal issues with open data, we developed and conducted three open data game jams. At the jams, we invited participants to brainstorm a social issue, find available data about the issue, and make a video game about it. The objective of the jams was to articulate these social problems, in the sense of connecting the actors, factors, and consequences implicated in the issue [19]. Using open data about the social issues was one of the main themes of the jams, and we invited participants to take inspiration from available datasets about the issue they intended to address. In the subsection that follows, we give an overview of data-inspired games described in previous literature.

Several open data games have been studied in the literature; Friberger and Togelius [11] created a way to generate bespoke monopoly boards based on open data. The tool automatically generates street prices based on available open data on indicators like “Participation in regular volunteering”, or “Perceptions of drunk and rowdy behaviour as a problem”. Friberger and Togelius [11] propose a categorisation of data-inspired games based on three different criteria: genre (board game, arcade, first person 3D game, etc.), type of data used, and way in which data is translated into game content (game maps, items, etc.). Barros et al. [2, p. 5] argue that games can act “as a form of highly interactive data visualization” and stimulate lateral thinking. Barros et al. [2] propose a categorisation of data games on two axes: data fidelity - how much a game sticks to the original data it is based on - and data functionality - the extent to which gameplay is based on data, rather than data playing a purely decorative role. For example in WikiRace [24], players are dropped onto a random Wikipedia page, and need to get to another random Wikipedia page using hyperlinks. The game has high data fidelity, because the Wikipedia pages are left untouched, and high data functionality, because the player has to read the articles to find the right hyperlinks to click.

We conducted three game jams over the course of seven months, with each jam having a duration of 7 to 8 hr. One of the game jams involved civil servants, and the other two involved Master’s students. Table 2 shows a summary of the events we conducted to collect data for this study. Game jam participants were not pre-selected. For the game jam involving civil servants, we shared an open invitation on professional channels such as mailing lists. The remaining events were organised as part of a Master’s course. Participants could earn credits by participating to a number of different workshops. The game jam was one of the workshops available for Master’s students to freely attend. In total, about 101 people attended one of the events. Of these, 73 filled at least the pretest survey. Of those who filled the pretest survey, 62% described themselves as male, 36% as female, and 1% chose not to say, and 1% described themselves as non-binary. The most common nationalities among participants were Dutch (83%), and Chinese (3%). Regarding participants’ background, 69% agreed that they like video games, 49 % agreed that know how to analyse datasets, and 19% agreed that they know how to make video games.

The game jams followed a similar format, with some slight variations, as summarized in Table 3. A few days before each game jam, we distributed via email basic information about the event together with three example games to play: Spent [20], The McDonald’s Videogame [21], and Coming Out Simulator [5]. The game jam format takes 1 day to complete (9:00 a.m. to 5:00 p.m. with a lunch break). Game jam B was split in two days, with 7 hr of total work time. The morning section was dedicated to brainstorming the game ideas, and the afternoon to actually coding the games.

We started the event with an introductory presentation, and showed different ways and purposes of making games about social issues. We opened a discussion about the differences between The McDonald’s Videogame and Zamzee [13], and highlighted that games can be made to depict the complexities of an issue, or to incentivise positive behaviour change, sometimes blurring the line with gamification. This discussion was inspired by Morozov’s [22] comparison of Fatworld [26] and Zamzee. After an ice breaker, we distributed issue pitch sheets with a guided reflection on the issue to be addressed through the game. Participants could either pitch as a group, or pitch individually and invite others to form a team. This is similar to the capitalist group formation process [1]. Once the teams were formed, we distributed the following guided brainstorming sheets: (1) inspiration sheet, (2) game doc sheets, (3) screenshot sheets. The inspiration sheet was intended to think through existing games that the team is familiar with, and get inspiration for a new game. The game doc sheets were intended to produce a game design document, containing details such as the the story-line, environment, and art style, as well three data insights about the issue, and corresponding game mechanics. Examples on how to fill the sheets included: “Data insight 1: McDonald’s spends $650m per year on marketing (The Guardian); Game mechanic 1: Purchase marketing campaigns. The more money you spend on marketing, the more customers you get”. The screenshot sheet simply contained empty spaces where participants could freely sketch how the final game should look like. Most groups spent almost the entire morning brainstorming, and were ready to move to coding after the lunch break. Participants were introduced to Construct 3 [32], a game engine based on visual coding, and were given starter tutorials with instructions on how to code basic game mechanics, and make game art.

The first hypothesis is that the game jam results in greater knowledge about the social issue for participants. From the observations, it became apparent that most users possess a lot of information about the issues they decided to work on, and that game-making did not necessarily increase their knowledge. This is convergent with the findings from our surveys. Only 47% (24/51) of respondents agreed that “Because I had to make a game, I learned something new about the issue”, 62% (34/54) agreed they learned more about a social issue, and 53% (29/54) agreed that “I discovered this issue is more complex than I initially thought”. Finally, only 22% (12/54) agreed that “I realised I had faulty assumptions about the issue”. We conducted a debriefing interview with a game jam team who made a game about the housing crisis in The Netherlands. The group was surprised about how quickly you can prototype a game. While brainstorming, they all agreed that student housing is “miserable”, that it is often covered in the news, and that it was an issue they were familiar with. They found statistics on the issue, but did not manage to incorporate them in their game. They were surprised by the difference in cost of housing between different municipalities, and one team member was not aware of the high cost of housing in their municipality. The game was a cookie-clicker, where the player needs to tap the screen as quickly as possible to earn money. With this basic mechanic in place, they were able to reflect on real world scenarios and transfer them into the game. The team initially wanted to describe the issue from the perspective of the affected people. They then pivoted to a concept where the player is responsible for the issue and rewarded for causing it, as the game would be more fun and they could show that “money can make more money”. The team divided into two pairs: coders and artists. One person who was knowledgeable about the issue took the lead. Overall the group was happy with the workshop and their game idea, which shows how difficult it has become to buy a house. They stated they would like to finish the game and continue learning game development.

The second hypothesis is that the game jam motivated participants to collectively explore a social issue. Participants seemed highly satisfied with the workshop, 96% (52/54) agreed that they had fun during the workshop (the rest were undecided), 98% (53/54) agreed that they felt included in their group, 72% (37/51) agreed that “I could express my ideas through game-making”, and 66% (34/51) agreed that “The format of the workshop allowed me to express my thoughts on the issue”. We observed very high levels of motivation and engagement during the brainstorming section of the workshop, prior to coding the game prototypes. The capitalist group forming process was well received, and in all game jams, more than enough participants stood up to present an idea and look for others to join their team. While each pitch was brief (around 2 min), this was a moment of social learning, as participants in the room could learn about other participants’ issues and priorities. However, groups became visibly quieter during the coding section of the workshop, after being introduced to the game engine. From the observations, there appear to be multiple reasons for this: (1) the switch to digital work on a laptop inevitably leads to distraction (such as work emails and other work related tasks), (2) the steep learning curve of approaching a game engine for the first time, and (3) the difficulty of structuring simultaneous collaborative work.

The third hypothesis is that the game prototypes connect the causes (actors, factors), and consequences of a social issue (issue articulation). While participants had very limited time, they still managed to produce playable game prototypes. We counted 27 different game prototypes across the three game jams. The prototypes produced had the aesthetic of early Flash games playable in the browser. Almost all games had 2D graphics, and often contained a mix of original and third-party game art. We distinguished two themes in the games made by participants: (1) managerial games, where the player is in charge of managing a system and making choices that affect other people, and (2) protagonist games, where the player is acting as an individual affected by the issue, and makes decisions mostly affecting themselves. At the same time, three further categories could be identified: (1) games rewarding unethical behaviour, (2) games rewarding ethical behaviour, and (3) ethically neutral games. It was clear from the observations that Master’s students coped better than civil servants with the steep learning curve of learning how to use a game engine, and managed to produce more complex game prototypes. In the surveys, 60% (31/51) of respondents agreed that “The prototype reflects my understanding of the issue”, 56% (29/51) agreed that “The prototype shows why the issue is problematic”, and 70% (38/54) agreed that “I am satisfied with the game produced by my team”.

We found four main successful features of the game jams: (1) the group forming process, (2) the broad theme and freedom to pick any social issue, (3) the examples shared before the event, and (4) the limited duration.

Capitalist group forming process - At the beginning of the event, in order to form a team, participants had to pitch the social issue they chose in front of others. We found this to be successful as, during the pitches, participants could learn about social issues they were not familiar with.

Broad theme - The theme of the game jams was to simply use open data to make a game about a social issue, leaving participants free to pick a specific issue of their liking. This meant participants could pick social issues they were already familiar with and share their knowledge with other team members, leading to deeper discussions.

Sharing example games before the event - We shared with participants links to The McDonald’s Videogame, Spent, and Coming Out Simulator. This provided a common ground for participants to discuss how games can be used to depict and reflect on social issues.

Limited duration - Conducting the jam in 7 hr meant it could be easily integrated into coursework or conducted as a team building event for civil servants, who might be unable to dedicate more time. A reduced duration makes the event accessible to a wider audience, which extends beyond passionate game developers. While not all teams were able to produce working game prototypes, we were surprised by the results achieved in just a few hours of game-making with novice participants, who for the most part had never written computer code before.

Beginner-friendly game engine - We introduced participants to Construct 3, which does not require installation, and allows games to be exported almost instantly and played in the browser. While being somewhat easy to use, Construct 3 is commercial software, and offers a free trial with limited functionality, which might limit participants from continuing their development efforts. The only game prototype that was finished and published a few weeks after the jam had use all of Construct 3’s events included in the free trial and cannot be extended further unless a licensing fee is paid. Some participants did not find the game engine intuitive and struggled to work with it.

The three unsuccessful features we found caused some level of frustration to participants, and were: (1) wrong expectation of what could be achieved at the jam, (2) lack of references for game mechanics, and (3) lack of teamwork during actual coding of the games.

Wrong expectations - We observed many novice participants expecting to make fairly polished prototypes over the game jam, which proved very difficult in reality. In order to reduce frustrations, game jam organisers should provide clear guidance about what is achievable through the jam. This issue is convergent with the difficulties and frustration observed by Pontual Falcão et al. [27].

Lack of references - Some of the participants had never played a video game before, lacked any references to make their new game, and were unfamiliar with the concept of game mechanic. This issue could be addressed by providing a set of game mechanics (e.g. in the form of cards) that participants can pick from during the brainstorming phase.

Insufficient teamwork during game development - Only some of the teams were able to divide tasks across the group, and work in parallel on coding the game and producing art assets (drawings, music, etc.). This led to many games using third party art, which limited participants capacity to express the social issues through their games. Effectively, game development revolves around a single person owning the laptop used to code the game. This issue is hard to solve, as setting up collaborative software development is technically challenging.

The validity of our results is limited as it relies on participants self reporting their learning outcomes, motivations, and satisfaction. One of the authors of this study was both facilitated the game jam and also administered the surveys, which can lead to acquiescence bias in the surveys, as well as courtesy bias during the observations. One of the three game jams was somewhat different. Game jam B was split in two days, two weeks apart (the pretest survey was administered on the first day, and posttest survey was administered two weeks later). This difference limits the comparability of the events and validity of our results.

This study is not sufficient to establish whether the outcomes related to issue articulation were due to game-making, or due to the different objective presented to participants, when compared to a traditional hackathon. Further research could compare hackathons and game jams in an experimental setting, to validate whether game jamming, with all other conditions being equal, is more conductive to issue articulation. During the jams, which lasted less than 8 hr, participants had to both learn technical skills and articulate the issues. Future research should test whether more experienced jammers spend less time on learning technical skills, and therefore gain a better understanding of the issues. In future research, the game prototypes made by game jam participants could be further analysed. It is still unclear what pushed certain teams to make games that reward ethical behaviour as opposed to unethical behaviour.