5. The Most Painful Practices under “What Went Wrong”: Three Insights

Audio

Video

Voiceover: What Went Wrong: Remote Bodies

Text: What Went Wrong: Remote Bodies

Animation: cursor making a square around words

Voiceover:During the production stage of development, task management is a highly communicative practice,

Broll : Video by Pressmaster from Pexels

Voiceover: requiring teams to assign responsibilities and associated tasks to team members, keep track of time committed to each task, and, of course, hold those completing the tasks accountable.

Text : Task management/ project management/ time management / managing the workflow and bodies of an entire project.

Animation : arrow pointing

Graphics: document, statistics and down/uploading icons

Voiceover: When developers admitted that “communication” had gone wrong, they often related it to task management.

Text : Without the team in the same room, meetings went overlong , issues took more time to explain, and momentum/excitement  about progress was less tangible . (Mitsoda, 2015)

Animation : spinning wifi symbol

Voiceover: In these same spaces, developers spoke often of the challenges of remote communication.

B-roll : Video by Ketut Subiyanto from Pexels.

Voiceover: Perhaps due to unclear tasks faced by development teams, marketing and other public efforts fall to the wayside. Developers said marketing was another painful practice. Remote marketing practices simply didn’t gain enough traction with

Text: Live Streaming / Launching the final game / reaching out to press / engaging with players / marketing

Animation: arrow pointing

Graphic : people working at a desk and looking at a graph

press, professional streamers or players.

Graphic representing press, professional streamers or players.

Voiceover: Overall, these game developers recognized that marketing a game demands using both in-person and remote communication channels to talk development progress, updates, promotions, and more.

Text: these game developers recognized that marketing a game demands using both in-person and remote communication channels to talk development progress, updates, promotions, and more.

Animation: cursor making a square around words

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.

Missing throughout most of the project was a managing producer, someone who loves reading and writing schedules and charts, asking the tough questions and making tough decisions regarding scale, features, and deadlines. (Klose and Lange, 2015)
We found that good planning - keeping track of tasks - took a lot of time that none of us had the bandwidth for. As a result, we made short sprint plans that worked very well, but didn’t give us a full scope of the project overall, and as a result we were unable to accurately estimate how much work there was left to do. (Balm et al., 2015)

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:

Communication breakdown can happen even when everyone is under the same roof, but when you’ve got a team spread out over multiple time zones, the odds are pretty good that communication will break down.

And it did.

There was an inherent difficulty in tracking progress: Sometimes emails wouldn’t be answered for 24 hours, builds would hit a major snag and need to be reuploaded, or critical bugs wouldn’t be fixed for a day. Without the team in the same room, meetings went overlong, issues took more time to explain, and momentum/excitement about progress was less tangible. New builds would not always go out on a timetable that was helpful for the Seattle team, where the majority of DoubleBear team members were located. (Mitsoda, 2015; emphasis ours)

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.

There were other hurdles, as we could not decide the right date for the Steam release due to lack of familiarity with its inner workings. In the end, DG launched on November 24 on Steam—even though we expected it to launch there about a month later. (Surt, 2019)
Steam is not something you can tackle overnight, nor is it a platform that you can trust will work to your advantage. It’s a brilliant, dynamic creature that can act as either your ally or your enemy—it really depends on how well you read the documentation. (Diaconescu, 2017)
Steam Early Access hurts initial impressions …. No matter how clear you make the game [or] remind people in Early Access that not all the features are in and that the game will probably have bugs, there is a sufficient percentage of players who will download the game, play it for 10 minutes, find it “unfinished”, give it a negative review, and return it. (Wardell, 2016)

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.

As I was developing TILTitI focused completely on the development part, only showing the game to close friends as things progressed. I intended to start marketing the game and focus only on marketing two months before its release by setting up a steam page, contacting curators and streamers and mailing review keys to the press. (Berglund, 2020)
We didn’t engage with our fans through social networks until after our E3 showing, we focused primarily on the ‘major beats’ in our marketing campaign and had little to no time to engage with the crowds that aren’t reading forums like NeoGAF or visit sites like IGN, Gamespot, Gametrailers and the likes (Mahler, 2015)

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.

A glowing computer keyboard

Literature Review:
Situating Post-Mortems

A study of post-mortem articles would further amplify theories of feelings that limit and drive rhetorical activity.

Hands typing on a computer

What Went Right

A number of developers argued that collaboration, design and testing were critical to their development process.

Blue, green, and purple-coloured sketches of webpages

Concluding Ideas &
for Creators and Teachers

What would happen if writing scholars wrote more post-mortems? What does a post-mortem assignment look like in a writing classroom?

A red, glowing question mark at the end of a hallway

Methodology: Collecting & Analyzing Post-Mortems

We analyzed 60 articles through the lenses of rhetorical and affect theories to understand feelings.

A streak of light running across a road

What Went Wrong

A number of developers argued that management, design and marketing were difficult when working remotely.

A desktop computer with speakers and a coffee mug

Making Our Project: Our Post-Mortem & References

We make our rhetorical moves and affectively rich experiences visible and draw more parallels to game and webtext development.

About the Authors

Rich Shivener is an assistant professor in the Writing Department at York University in Toronto, Canada. His work has appeared or is forthcoming in enculturation, College English, and Technical Communication Quarterly.

Jessica Oliveira Da Silva is an undergraduate student double-majoring in professional writing and humanities at York University. Jessica is two-time recipient of York's Liberal Arts and Professional Studies Dean's Award for Research Excellence (DARE), which supported this research project.