Sharing Pain and Pleasure by Shivener and Oliveira Da Silva

Video Transcript (Click to Open)

In this next section of results, we discuss three of the most painful areas of practice under “what went wrong,” as described in post-mortem articles. Reflecting our approach in the previous section, we start with a brief table outlining three areas of practice and the numbers of times referenced by developers. We discuss three areas of practice related to the production and post-production stages of development: management, design, and marketing. From the commentary of developers, management and marketing have painful ripple effects on practices such as level design, programming and overall team morale.

Practice	References
Management (includes references to time, task, and personnel management)	60 references across 38 developers
Design (includes overall design discussions, level design, mechanics)	48 references across 32 developers
Marketing (reaching out to press and streamers; engaging audiences on social media)	39 references across 26 developers

5.1 Management Fails

In this results section, more interesting to us are the developers’ discussions on management because they narrate more immediate feelings between bodies, whether in-person or remote. For 38 developers who described their feelings, management was a “wrong” area of practice. By management, we mean time and task management, for both involve managing the workflow and bodies of an entire project. During the production stage of development, task management is a highly communicative practice, requiring teams to assign responsibilities and associated tasks to team members, keep track of time committed to each task, and hold those completing the tasks accountable. Most telling about feelings in relation to time and task management are the 10 developers who referenced “crunch,” those overtime and long, strenuous scenes of development. The term “crunch” holds negative connotations, referring to “labor practices that commonly force developers, artists, programmers, and others working on a software project to work extensive, unpaid overtime” (Cote & Harris, 2021; emphasis ours). From an affective point of view, crunch often demands forces of encounter––that is, it demands bodies to be present and working voraciously, even remotely, in the final months of development. Gregg and Seigworth (2010) have argued that affect is “once intimate and impersonal, [and] affect accumulates across both relatedness and interruptions in relatedness, becoming a palimpsest of force-encounters traversing the ebbs and swells of intensities that pass between 'bodies'" (p. 2). The stories of crunch are ones of rampant intensities that pass forcefully through bodies. Feelings of psychological swelling and pain are tethered to the word.

The game development industry generally acknowledges that crunch is a mainstay among teams, many beyond those who discussed in post-mortems (Thomsen, 2021). As Thomas Mahler concedes about crunch, “the problem the industry faces is that game development is almost impossible to properly plan. There is just no way of knowing exactly which issues you'll run into, how many resources exactly will be needed to finish the production, etc., especially if the production time is a rather lengthy one” (2015). For some emblematic discussions, we turn to Jan Klose and Thorsten Lange’s (2015) reflections on action role-playing game Lords of the Fallen, and Michael Balm et al.’s (2015) reflections on the flying game Heroki.

Words by Jan Klose and Thorsten Lange, and Michael Balm et al.

Furthermore, 10 developers also admitted that “communication” had gone wrong among team members, and they related it to task management, describing hours that were wasted on development. A small sub-group of four under “communication” noted remote challenges (well before the pandemic, it should be noted). As Balm et al. (2015) wrote about Heroki, much of the game’s production stage was communicated via Skype, which resulted in miscommunication. “From time to time, team members would be confused about certain gameplay elements because they had interpreted something in another way than it had been intended.” They added, “Toward the end of the project we were able to work from the same location more often, and during these times we found that we worked more efficiently. Working together made creating and testing builds a faster process and development sped up.” For Balm and many others, bodies in proximity resulted in better task management, better communication, and better feelings between team members. We drive this point further by quoting generously from Brian Mitsoda’s (2015) post-mortem for the survival-horror game Dead State, about which he discusses the challenges of remote work:

Words by Brian Mitsoda

Mitsoda’s passage indicates that remote communication had direct implications for time-sensitive tasks and how those tasks were received. We’d like to pause for a moment on Mitsoda’s comment that “momentum/excitement about progress was less tangible.” He couldn’t feel that progress. Watching a game build materialize, in shared time and space, was more pleasurable for Mitsoda than sitting, say, on a Zoom call and sharing screens, let alone screens and communicative media that are at the will of internet connections. For Mitsoda and aforementioned developers, tasks and pleasurable feelings are more immediate when teams work in physical proximity. And this insight has gravity in our current, pandemic-strained times, as developers have been reflecting on the challenges of remote work. As one anonymous developer told Tom Power (2020) about completing tasks remotely, “Design discussions have taken a huge blow too. Everyone is in meetings all the time, so I can't just go and find the right people to communicate with.”

5.2 More Design Feels

While design “went right” for 22 developers in our corpus (see our previous section), 32 developers referenced design as something that “went wrong.” Again, this finding makes sense because design is a player-centred part of game development; it has to feel right and playable before it goes public. And if the public dislikes their game, developers refer back to design flaws and various challenges.

But what are developers referring to more specifically in the “wrong” discussions of design that might tell us about feelings, especially of pain? The discussions run the gamut. In the corpus, five developers referenced narrative design and writing elements. Reflecting on their game 80 Days, Jon Ingold and Joseph Humfrey (2015) offered that their narrative contained “passive, simple interactions, but they felt pointless––we tried a complex mini-game of collecting and playing strategic facts, only to take it out less than three weeks before the game shipped because, quite simply, no-one enjoyed it.” By no-one, they were referring to people who tested the game before its official release. Another development team, Henrik Fåhraeus and Rikard Åslund (2016), noted that while “other types of scripted content was conceptualized, with our near-sighted focus on the early and late game we neglected to properly flesh out the mid-game content.” This isn’t the first reference, by the way, to flesh and other bodily language in relation to design (see our previous section).

Five more developers reflected on the overall difficulty (or lack thereof) of their games. Most emblematic of this sub-group is Dave Toulouse’s writings about his space combat game Human Extinction Simulator, in which he reflects on how to reconcile the game’s noted difficulty and his approach to designing artificial intelligence.

Looking back I think it might have been a good idea to compromise on the difficulty level on enough content to give a chance to people to actually get the spirit of the game before letting them face the frustration of defeat. But how do you exactly make a game like chess easier? You make the AI dumber ... I always refused to do that and it was probably a mistake to be so stubborn about it.

These examples once again demonstrate that design discussions can tell us a good deal about feelings that differ and form between developers and players. It’s as if design is a confluence of pain and pleasure and associated things in circulation that imbue developers and players.

5.3 Remote Marketing Challenges

Perhaps due to unclear tasks and timing issues faced by development teams, marketing and other public efforts fall to the wayside. Cited by 26 developers, marketing was another painful practice. Marketing includes remote and in-person communication practices such as livestreaming games (e.g., on Twitch), reaching press through email, engaging with players, and launching the final product. For at least 14 developers, remote marketing practices through social media and email simply didn’t gain enough traction with press, professional streamers or players. Reflecting on marketing his team’s game Sydney Hunter and the Curse of the Mayan, John Lester (2019) admitted to leaning, remotely, on streamers and his contacts “to help push and promote the game—but I quickly realized that it wouldn’t be enough.” Also reflecting on streaming, Lisa Brown (2015) wrote that informal, in-person settings are crucial to determining audiences for Twitch streams, email messaging, and the like. “Finding these people isn’t the same as running a focus test, but rather finding them involves getting the game out there—showing it at game festivals but perhaps non-games events as well, and talking about the game early in as many outlets as you can” (Brown, 2015).

Some notable pain stemmed from remote marketing in relation to the Steam distribution platform. Steam is a primary distribution platform for many game developers, and it allows developers to sell early iterations of their game to public audiences under the “Steam Early Access” program, a kind of proving ground for their work. Several developers spoke about the crowded market of games on Steam, feeling the pressures of algorithms (i.e., that affect the visibility of the game) and player reviews on a platform that distributes thousands of games. Notice how Romanus Surt (2019), Cristian Diaconescu (2017) and Brad Wardell (2016) describe Steam with some bodily metaphors—hurdle jumping, tackling and hurting.

Words by Romanus Surt, Cristian Diaconescu, and Brad Wardell

Such metaphors, including others in the corpus but not mentioned here, suggest that remote marketing is still full of feeling. Metaphors illuminate the feelings between developers, players, and platforms. Even if someone leaves a negative review on a platform like Steam, that review parlays into a game developer’s felt experiences behind a screen, in a meeting, etc.

Of less concern but worth discussion here is the pain of marketing that stemmed from keeping a game too close to a team rather than also distributing it far and wide. Mathias Berglund, the solo dev behind the puzzler TILTit, wrote that he didn’t tell the world about it soon enough, while Thomas Mahler, of the team behind the platformer Ori and the Blind Forest, wrote that the team didn’t do far enough with its remote marketing.

Words by Mathias Berglund and Thomas Mahler

Overall, the aforementioned game developers recognized that marketing a game demands using both in-person and remote communication channels to talk development progress, updates, promotions, and more. Positive energies might run high at a convention, but they ought to continue pulsing through and accumulating in remote contexts.