This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Before beginning on an admittedly very long and dry essay, I feel that I should explain my motivation behind this paper. Beyond simply providing “solutions” to crunch, as a student in game design, hearing about the intense working conditions of the industry, to be frank, fills me with anxiety, and I suspect I’m not alone with this sentiment. I do not doubt that I will pursue game development professionally, not in the slightest. But, when I regularly hear about games that required incredible human costs, and there being a general acceptance that crunch is simply a part of game development, I can’t help but feel like a stupid child sprinting straight into a mine field. So, I do hope this paper helps the few developers that read it to make their working lives at least noticeably better, but I also hope this paper helps to give students like me some agency over their futures, which can be an incredible power to have during their formative years.
Video game development is seen, first and foremost, as a creative endeavor. Game developers are passionate people, who were lucky enough to find work they enjoy. They create and play games in an ever growing industry worth billions, and express themselves through the efforts they put in. This is the mainstream understanding of game development, and its delusions are evident to any who dares to peer further into the industry. Yes, video game development is a passion fueled industry, but it is not the “play” that many imagine it as. Regardless of how enjoyable a developer’s work is, it is still work for money to pay their bills and eat food. So, if their manager gives them two, ten, or twenty more tasks to do, then they have to finish them. Otherwise, nothing is stopping a new, actually passionate applicant from taking their place; if someone is not getting their work done, then they must not be passionate, after all. So then what happens if, by the end of the day, they have not finished all of their tasks? They keep working. They sleep in the office. They don’t stop until the job is done. Behind the romanticized depiction of game development lies a hard truth of deadlines, often toxic company culture, and overworking.
It is a common occurrence within the games industry for development teams to labor for extraordinary hours, and under intense pressure, to complete a video game. Working unpaid overtime to reach looming deadlines is so frequent, that it has even spawned a shorthand term for it: crunch. Among many developers within the industry, crunch is considered a necessary part of development, or at least unavoidable. However, crunch has serious implications for the physical, mental, and social health of developers. It serves to compromise team productivity, results in a hemorrhaging of talent and experience as burnt-out developers escape, and breeds a workplace environment that reinforces crunch as an expectation for developers, referred to as “crunch culture”. In the past few years, games whose development were defined by intense and extended periods of crunch have come under scrutiny, and have left the industry with the lingering questions “why?” and “what do we do?”.
While some developers and gamers would argue that crunch is simply a part of game development, in this paper I approach it as a problem that must be solved for the well-being of developers, and the longevity of the industry. I will explore the causes of crunch, splitting them between two classifications: sources that are the circumstances and practices that motivate crunch, and methods that are the cultural contexts and perspectives that instruct developers to crunch in response to the sources. I then compile solutions to address the causes outlined, separating them into three levels: team, project, and individual, which target their respective scale within a games studio. These classifications provide a useful system for future appraisal of causes and solutions to crunch that are not addressed in this paper. The goal of this paper is, by the end, to have a detailed set of suggestions such that no matter the circumstance or position a developer may be in (from manager to contractor), they can immediately act to at least minimize crunch, and at most eliminate it.
The unadulterated incentive to crunch for many teams is to accelerate progress on a project that is behind schedule; although, the causes of crunch are significantly more complex than that, which will be shown in the next section. On the surface, it seems like a reasonable conclusion that working longer and harder will complete more tasks. However, this has proven to be a logical fallacy. While crunch tends to improve productivity in the short term, sustained crunch, found to be of about four weeks or more, actually decreases productivity compared to working regular 40-hour weeks (Take This, 2016, p. 6; Keith, 2020, 33:28). Edholm and Lidström (2016, p. 9) define a separation between types of crunch, pointing out that the only category that results in improved productivity is “mini crunch”: a period that lasts at most two weeks.
It would be easy to say that shorter periods of crunch are worth pursuing, but a team’s situation is often more complex. Despite their boon to productivity, mini crunches are a minority compared to longer sustained, or more intense, crunch (Edholm & Lidström, 2016, fig. 5). If it was as simple as choosing to crunch in short spurts, developers would already be doing that. Regardless of whether shorter periods are beneficial to the project, the decision of how long to crunch for is not made in a vacuum. Rather, it’s informed by factors within the project to a degree where it could hardly even be considered a choice at all. The lack of control over what type of crunch a team will engage in, if pressured to do so, makes targeting mini crunch as the sole form used simply unrealistic.
Even if a team is given the freedom to choose mini crunch, the risks to their well-being outweighs any benefits it may have to the project. Across all types of crunch, Edholm and Lidström (2016) observed a consistent increase in stress and fatigue among developers. Developers under crunch tend to be sleep deprived, have a poor diet, have unhealthy habits, and are more likely to have depression and anxiety (Take This, 2016, p. 8-9). Crunch is also notorious for its effects on developers’ work-life balance. Being at work, rather than at home, tends to strain relationships with family and loved ones, and the adverse health effects lead to stress and anxiety among those close to developers (Take This, 2016, p. 9). The incredibly damaging effects crunch has on health are the root cause of all other problems related to it. If even the shortest periods of crunch can result in such complications, there is no way to reasonably enforce crunch and expect developers not to experience these effects, and all other detriments that stem from the degradation of their health.
The most common solution individual developers find to avoid such a situation is simply to leave the industry. The effect this has for development teams is a severe lack of experienced personnel. Due to the constant stress endured during crunch, burn-out is a regular occurrence. This, combined with older developers with families wanting greater work-life balance, can push those with the most experience to quit (Take This, 2016, p. 11). As Seth Coster (2020, 0:08) notes, those who have been in the games industry for long enough are called “veterans”, and not “experts”. The mark of long-time developers is not expertise and knowledge, it’s survival. Coster points to crunch being the reason for this. As video games grow in scale, complexity, and cost, the need for a reliable and large body of experienced developers will grow, as well. The lack of the latter warns of an extremely unsustainable industry environment. This puts projects at a higher risk of failure since they may lack enough experienced production leads to successfully navigate development, and increases costs since onboarding new developers requires resources that would not be spent otherwise.
Punctuating all of this, is crunch’s often self-perpetuating behavior. As developers become fatigued from crunch, they become more likely to make mistakes, leading to more work. This inadvertent increase in tasks then pushes developers to crunch even more (Edholm & Lidström, 2016, p. 11-12; GDC & Coster, 2020, 23:35). This is the reason for the aforementioned drop in productivity, as well as a source of decreased quality in the final build of a game (Take This, 2016, p. 10). On top of this, those with experience still remaining in the industry will likely have one of three views on crunch; either supporting its use since that’s what they expected of themselves, accepting it as a part of game development, or adamantly against it. The state of the industry suggests the first two are more common, which follows the reasoning that those who oppose crunch are more likely to be among those that leave because of it. As a result, as experienced developers get promoted to managers, there’s a greater likelihood that they will expect their teams to crunch just as they did, or be unfamiliar with effective ways to prevent it.
Crunch causes severe health risks for those it’s imposed on, can compromise the quality of a game, results in a loss of experience and talent, and fails at achieving what it was intended to be used for. Encompassing all of this is its nature of being self-perpetuating through the very problems it causes, and by creating a toxic workplace environment. Crunch has no consistent benefits, and even when it does contribute to a project, the negative effects are monumental compared to it. To quote Coster (2020), who refers to crunch as “heroics”:
Heroics are the signature thing that the games industry is known for…[and] are a signal that all of your systems have failed. This means that our industry is best known for being really bad at our jobs. And we’re stuck. (24:14)
It’s worth mentioning that there are other causes of crunch beyond what will be detailed here. One could argue that the segment of the gaming community supporting crunch, labor laws allowing unpaid overtime, or the capitalist incentive to publish more games quicker are all contributing factors of crunch. However, all of these problems are at a societal scale where development teams, or even the industry as whole have little to no control. The goal of this section is to highlight causes that exist at the local scale within development teams, and between projects, which can then be realistically, and directly addressed. There is one exception to this, with NDAs, and the purpose for which will become apparent later on. The causes of crunch are deeply interconnected, so to better understand their relationship they will be split between sources: the circumstances and practices that motivate crunch, and methods: the cultural environment and perspectives that instruct developers to crunch in response to the sources.
Sources of Crunch
The most common source of crunch, according to developers, is deadlines (Edholm & Lidström, 2016, p. 9). Seeing as reaching deadlines is part of the core motive to crunch, the frequency of blame being placed on them is to be expected. Among Edholm and Lidström’s (2016, fig. 5) classifications of crunch, “continuous crunch” which lasts the entirety, or for a large portion of development, and “final crunch” that occurs at the end of a project, are the most common types utilized. Such a result agrees that the final release date of a game is the highest priority deadline for a team, that this deadline is treated as immovable, and that it regularly motivates crunch. However, lacking ample time to complete necessary tasks is only one half of the original incentive to crunch, with the other being actually having enough tasks to warrant it. This imbalance can be viewed as the ultimate source of crunch, as all other sources act as upstream to it, influencing the task to time ratio development teams are confined within. Each of these upstream sources can be split into the different stages of development (pre-production, production, and post-production) they reside in, which further demonstrates the cascading effect each of them has on each other.
The goal of the first stage of development, pre-production, is to establish the scope (the features and assets implemented in the game) and timeline of development, where failure to do so accurately sends ripples throughout the entire project. In other words, it initially defines the task to time ratio. Among the most common issues faced that lead to crunch are a poorly defined, or inaccurate timeline and scope (Edholm & Lidström, 2016, fig. 3). Leaving a project plan in such a state opens development up to a series of challenges and complications. A central theory to project management is the adherence to the “iron-triangle” of scope, time, cost, and quality (Caccamese & Bragantini, 2013, p. 4). The iron-triangle posits that these four constraints are necessary to remain within for a project’s success. The goal of a project manager is then to maintain a project’s scope and timeline to not exceed costs, and maintain quality. So, beginning a project without a properly defined iron-triangle will inevitably place strain on development. Having a “realistic schedule is seen as a critical success factor” (Kuutila, et. al., 2020, p. 9) because of the difficulties that ensue without one.
During production, the effects of inaccurate estimations, combined with inefficient and ineffective management, result in the bulk of the sources of crunch. One of the most common is “feature-creep” (Edholm & Lidström, 2016, fig. 3); where features are added mid-production to a degree where the originally planned scope is no longer accurate. This is usually the result of irresponsible management allowing unmitigated implementation of unplanned features (Edholm & Lidström, 2016, p. 9-10). Remaining steadfast to the original plan can be difficult, especially if stakeholders are pressuring the team to add features, but it will be near impossible if the original plan is not properly defined to begin with. Feature-creep is seen populating the “chaos” that Keith (2020, 12:40) mentions as characteristic of production, the final crunch classified by Edholm and Lidström (2016, p. 9), and the iteration (repeating production processes until a sufficient result is achieved) Archontakis (2019, p. 52) points to as a key source of crunch. Chaos, final crunch, and iteration all stem from the lack of a defined plan to guide production. Since pre-production failed to identify the goals and limitations of the project, the team engages in chaos and iteration mid-production to “find the fun”. The time they consume results in a severe upheaval within the schedule, regardless of how poorly defined it is, sending the team into final crunch. The severe, and unresolved technical debt typically incurred by final crunch then pushes developers to crunch further. Coster (2020, 16:00) describes the ways wasting resources occur during production, punctuating that crunch perpetuates waste, and Edholm and Lidström (2016, fig. 3) indicate that the largest percentage of that waste is in bug fixing, as “technical issues” are among the most common causes of crunch.
Now in post-production, there is still a final source of crunch that can appear: a lack of publicized records. A significant part of why estimation may be inaccurate during pre-production is the lack of experience to pull from. One of the primary contributing factors to failed projects, not just in game development, is a lack of “historical data from similar projects” (Kuutila, et. al., 2020, p. 8). The games industry is particularly notorious for limiting the access of knowledge and experience through NDAs (Non-Disclosure Agreements), as O’Donnell (2014) argues:
Estimation in particular requires experience...If estimations are routinely ignored because they are either dramatically under- or overestimated, how does that affect project deadlines?...The (in)ability for game developers to learn and share information about game production practices severely limits the capacity for the industry to mature. (p. 42)
The reluctance to add records and postmortems to a public pool of knowledge eliminates any purpose experience can have. The cascading effect between sources of crunch is not simply isolated to singular projects, but also influences future projects, exacerbating the likelihood of encountering the same challenges again. However, a team facing such problems is not enough to explain crunch’s prevalence in the industry. The methods, or the cultural context, by which teams reach the conclusion that crunch is their best solution must also be accounted for.
Methods to Crunch
The method at the forefront of the industry’s consciousness is crunch culture. This is a company or team culture where crunch is expected of developers, and regular or constant crunching is viewed as a good practice. Not all development teams have a crunch culture, per this definition. However, there still exists a general sentiment within the industry that crunch is an unavoidable part of development (Cote & Harris, 2020; Edholm & Lidström, 2016; Peticca-Harris et. al., 2015), which is a passive manifestation of crunch culture. The factors that lead to the development of such an environment are deeply ingrained within the industry, and culminate in a similar relationship as the sources of crunch and the imbalance of tasks and time. In this way, crunch culture can be viewed as the downstream method to all other methods that inform developers to crunch. The methods that do so: employment pressures, the image of the passionate worker, the unmanageability of development, and the resistance to management processes, act in a multi-pronged approach by both normalizing crunch, and preventing resistance.
The first two methods, employment pressures and the image of the passionate worker, go hand in hand. Peticca-Harris (2015) argues that the project-based nature of the industry, and thus the portfolio-based nature of employment, places developers as solely responsible for maintaining their own employability. In this environment, developers are pitted against each other in maintaining “their peer and portfolio-based reputations” for favorable employment and promotion opportunities (Peticca-Harris et. al., 2015, p. 573). This drives developers to adamantly pursue what is perceived as the best employee. Cote and Harris (2020) identify this image as one detailing a developer who is “passionate and dedicated to the industry ‘because they love the work’” (p. 170). Edholm and Lidström (2016) note that “colleagues staying late can be a big influence” (p. 10) on whether a developer stays late themselves, and that crunching is considered part of the industry’s “hard work ethic” (p. 12). The idealized image of a developer without the need for rest serves as a principle goal within the industry, prompting developers to behave as such in the pursuit of perfection, typically expressed through an “over-indulgence” in their work, which justifies crunch as an expression of their passion.
This should not distract from the honest passion individual developers have, though. Edholm and Lidström (2016, p. 10) clarify that this is not uncommon for developers, and they will purposely push themselves for the betterment of the project on their own accord. Such a decision is still “constrained by the social context, institutional conditions, and social rights involved” (Peticca-Harris, 2015, p. 576), but that does not negate developers’ intrinsic motivation. Such a distinction between the expectations put on developers, and their own drive is important to make. While their outwardly appearance is similar, if not the same, their origins are fundamentally different, and must be approached differently as a result. And, regardless of its origin, the individual passions of developers are still a method to crunch, making them a target of this paper.
The last two methods, the belief development is unmanageable and a resistance against management frameworks, serve to prevent developers from searching for alternatives to crunch. These two methods are observed by Cote and Harris (2020) within the rhetoric used among developers, and by O’Donnell (2014) as they physically manifest within the industry. The perspective that games are unmanageable is pinned to them being a creative project, not simply one of software development, and the lack of control developers have over their own projects, particularly due to publisher influence (Cote & Harris, 2020, p. 167; O’Donnell, 2014, p. 139-140). This works in tandem with what Cote and Harris (2020, p. 169) refer to as an “anti-corporate ethos”, a nostalgic preference to games’ indie history of garage development, to effectively dissuade developers from pursuing management frameworks and development practices that can mitigate crunch. Seeing as development is treated as unmanageable, attempts to manage it can be expected to be met with resistance, either out of challenging a status-quo, or from perceived futility. However, O’Donnell (2014) further elaborates that this perception is informed by the circumstances developers find themselves in, particularly the “norms of secrecy” (p. 140) caused by NDAs, clarifying that rhetoric is not the only factor contributing to their construction.
This separation of causes between sources and methods is valuable, as it communicates that crunch is not the “natural” solution to challenges faced in development. The sources are inherent risks and challenges of project-based work. However, the decision to crunch is not purely caused by these. Rather, the cultural context a project and its developers exist in informs which solutions they pursue. In a different context from the one dominant in the games industry, the typical response to such problems could be to immediately delay the project, or to cancel it outright. However, while this classification does make a conveniently simple narrative, where developers encounter difficulties and are then influenced towards crunch as the solution, it should not distract from the complex interconnections the two have. For example, NDAs create a “culture of secrecy” (O’Donnell, 2014) that perpetuates both the sources of crunch by restricting the spread of knowledge, and reinforces the methods of resistance against crunch mitigation by creating an environment that justifies them. The reality of game development is messy, and so too are the causes of crunch. However, unravelling them, and understanding them is key to finding their solutions.
Unlike the causes of crunch, the solutions will be divided into three levels: team, project, and individual. The departure from sources and methods is due to that classification only being a theoretical framework. While this classification will be useful for identifying appropriate approaches for addressing individual causes, the jump from theory to reality can often be inelegant, and defeat its own purpose. So, solutions will instead be organized based on the scales they should be deployed at. This way, they are directed with intention, and lead to action within a real context. This also provides “layers of defense” against crunch, rather than simply presenting a disorganized collection of practices. Depending on the environment developers find themselves, it may be unrealistic to use certain solutions from certain levels. If, for example, solutions meant to be deployed on the team level are not possible due the team being brand new, or unfamiliar with each other, then the project and individual levels can still remain. Of course, as levels get removed, the likelihood of crunch increases. If only the individual level remains, then crunch will probably only be mitigated, not prevented.
The first level, the team, is meant to target long lasting practices and culture within a development team. These practices should be employed by either production leads, or held as core pillars of development by the studio. The intention of these principles is to both reduce sources through organizing development, and combat methods by building an environment with clear expectations and goals. This level is especially important since it is utilized over a long period of time, and at a large scale.
Measure success by efficiency, and not hours. Take This (2016) suggests “promoting those who are doing the best work in the least hours” (p. 14), and Keith (2020) notes how using efficiency as a metric deters crunch since overworked developers have reduced efficiency.
Expect developers NOT to crunch. This is expressed through speech. As a manager, the words used to describe developers inform others what’s expected of them (Take This, 2016, p. 13-14). View crunching negatively, either as a failure of management (which includes taking accountability for one's own failures), or as an unfortunate but avoidable circumstance. A toxic environment, where crunching is seen as stupid or repulsive, should not exist since some situations will mandate it, but it should be regarded as unquestionably unhealthy. This practice, combined with measuring efficiency, tells developers that crunch is not how passion should be expressed.
Support a clear division between work and life. Take This (2016) recommends a multitude of practices that can achieve this. Managers can support developers to spend time with family, recommend healthier life-style choices (e.g. exercise to remove developers from their work habitually, and healthy sleep patterns to prevent working at midnight), or simply tell developers to leave the office at the end of the day.
Lead by example. Developers will act according to how their management suggests they should, both through language and actions (Take This, 2016, p. 13). If their manager is telling them to avoid crunch, but is also crunching at the same time, conflicting messages will be sent.
Have clear goals for each stage of production, and keep them consistent across projects:
1) Produce a game development document (GDD). This document is responsible for detailing the “ideal game concept and design” (Godoy & Barbosa, 2010, p. 293). Every desired feature, and the timeline should be clearly laid out here. In short, the GDD is responsible for outlining the project’s iron-triangle. This is often achieved through iteration and “chaos” (Keith, 2020), which is useful for “finding the fun”, but should remain in pre-production. In fact, “figuring out the game” in this phase is the single most beneficial practice any team can use to limit crunch.
2) Outline “pillars” to maintain focus during production. Pillars are the essential design principles or goals of a game. They are a summarization of the GDD to help developers quickly discern whether their work is contributing to the project (GDC & Tomandl, 2020). Achieving a clearly outlined direction will help prevent feature-creep, both from passionate developers and demanding stakeholders.
1) Remain flexible to change and new ideas. As development proceeds, other developers may come up with new ideas. These should not be ignored, but should be appraised against the game’s pillars, and the constraints of the project. There will also be unplanned changes throughout production. Keith (2020, 16:58) suggests having regular risk assessments where potential risks are identified, and mitigation strategies are prepared. This way, the team can quickly respond without wasting resources, or potentially falling into crunch.
2) Stay within the constraints of the project. It is extremely important that production remains within the timeline outlined by the GDD. While innovation should be welcome, focus needs to remain on what is realistically possible. This can take the form of timeboxing (GDC & Tomandl, 2020) which is setting a limit on how long an idea will be entertained if it isn’t proven, or regular meetings to decide whether proposed ideas are worth pursuing (GDC & Coster, 2020).
3) Maintain continuous deployment. Technical debt and feature-creep imposed by stakeholders are two of the most important sources of crunch to prevent. The goal of continuous deployment is to regularly produce a working demo to keep development focused, and the bug count low (Keith, 2020, 24:35). This demo will be presented to stakeholders in order to gather feedback, and ensure the project won’t be unexpectedly overturned. The challenge with this approach is effectively breaking the game into working chunks that can be played (Ebert et. al., 2016, p. 99). So, planning what will be in each demo should be done during pre-production, and be a part of the GDD.
1) Focus on recording infrastructure and collecting postmortems. These should be published, if possible. Otherwise, keeping a catalog of automation and development tools, and revising processes based on feedback can only make the team more resilient against crunch.
The second level, the project, accepts that no one process will work across all games’ development, and so focuses on adjusting to each project in order to minimize crunch caused by the unexpected. These can be used at a multitude of scales within a team. Preferably, the project manager will enforce their usage across all departments, but if need be, individual groups within the team can integrate these into their own pipeline to minimize crunching they would otherwise do. These solutions target inefficiencies within processes that may not necessarily fit perfectly into the context of the current project. What could be considered jerry-rigging is seen as typical within development, but this level aims to systemize this process to eliminate ambiguity and waste.
Automate processes. Any process that is regularly done the same way every time should be automated since doing them manually takes up time, and adds human error (GDC & Coster, 2020).
Reduce iteration. Any work that requires qualitative assessment before it is approved can create iteration since there is no exact criteria to assess with, which wastes time (Archontakis, 2018, p. 29). Refer to the GDD and pillars regularly to give clear expectations to developers so they know what should be made before they start. If there is no GDD, production leads have to provide the best approximation they can, since a guess is still better than no direction at all.
Remove bottlenecks. A bottleneck is any step in a team’s production pipeline that is “receiving more work than it can handle” (GDC & Coster, 2020, 30:10). A bottleneck is, by definition, overtasked, which causes resources to be wasted, and developers who work inside that bottleneck to crunch. The most effective method to remove a bottleneck is to simply move some of its responsibilities to other parts of the pipeline (GDC & Coster, 2020, 30:30).
Stay focused on the essentials. As developers get into flow, it can become easy to start adding features that seem like a good idea. Developers, and group leaders, need to spot for each other to prevent unintended feature-creep. Any ideas, regardless of size, need to be assessed against the GDD and pillars. A developer may think that adding one idea won’t affect scope by much, but they may not be aware that many other developers are adding their own ideas, as well.
Escape crunch by stopping production. If the team falls into a continuous crunch, then the processes that have been used so far clearly do not work. It is not effective for a team to assess itself while it is working, so production must be paused so that the project can be reorganized, and the team can properly revise its processes to achieve the five solutions stated above (GDC & Coster, 2020, 25:00).
The third level, the individual, consists of personal management practices and advice for developers in order to help them stay out of crunch as much as possible in their day to day work. Admittedly, these solutions will likely not eliminate crunch for any one developer, bar for maybe solo indie projects. The sources of crunch within a larger development team are simply too much to be completely stopped by individual developers acting alone. However, if permitted, even a 1-2 hour reduction of daily crunch is worthwhile once the weekly, monthly, or total hour count is tallied. These solutions prioritize getting work done as effectively as possible while maintaining the developer’s health.
Manage their own passion. Developers will be tempted to crunch because they want to contribute new ideas to the project. Developers should recognize the risks crunch poses to themselves. Regardless of how passionate they feel, developers will be able to do better work on the project they care about if they are well rested and healthy (Take This, 2016, p. 14).
Plan the day. Before beginning work, “spend time getting ready to execute” (GDC & Gardner, 2019, 6:35) by planning what will be done, and how it will be done. Spend a considerable amount of time on this to put as much detail as possible into what the day should look like.
Categorize tasks based on importance. Gardner (2019, 10:00) suggests dividing work into four quadrants: fire-fighting (urgent and important), quality-time (not urgent and important), delegate (urgent and not important), and time-wasting (not urgent and not important). Quality-time is the most important quadrant, as its priority is preparing for fire-fighting, which includes planning the work day. Fire-fighting is done most effectively when developers are ready to handle it. Gardner’s (2019) recommended response to the remaining two quadrants is to simply say “no”.
Conserve willpower. Willpower is limited, and is what is consumed over the course of a work day (GDC & Gardner, 2019, 7:38). This can be conserved by making habits out of daily decisions. Regardless of how minute--Gardner (2019) gives the example of choosing clothes--removing choices that take energy to make gives developers more energy to use at work.
If necessary, leave the team. If intense crunch is being mandated without any way to mitigate it, then the best way for a developer to stay out of crunch is to leave. This can be an unpleasant affair, but their situation is likely to improve by doing so. White (2019) provides a series of interviews showing the outcomes of leaving a studio, intending to convince those on the fence about their current working conditions. In summary, indie development can offer sustainable and fulfilling work, and the skills used in game development often carry over into other industries. While developers can feel a deep commitment to the project, They need to remember that nothing takes priority over their health.
Stay informed. Information sharing is severely limited in the industry, but that makes anything developers can get even more valuable. Building a catalog of others’ experiences for one’s own use can be extremely beneficial for handling difficult situations during development. Watching GDC presentations, reading postmortems, and researching development practices are all useful ways to gather knowledge.
One cause of crunch that has not been addressed here so far is the usage of NDAs. It is an exception among the causes, since NDAs are largely outside developers’ control. NDAs are a problem enforced by publishers, and can only be ended by publishers. The purpose these contracts serve in the games industry is to “control information flows” on in-progress games to manage advertising, and prevent competitors from stealing cutting-edge technology (O’Donnell, 2014, p. 206). However, an automated functionality tester for texture files is neither ground-breaking nor reputation-defining. O’Donnell (2014) calls on publishers to “differentiate between talking...about making games and ‘giving away’ a game” (p. 207).
Two changes must be made to NDAs within the games industry. The first is that, at a minimum, automation and specialized tools must be excluded from the NDA’s confidential information. This includes tools for exporting, testing asset functionality, documentation, and asset development (e.g. Maya and Photoshop plug-ins). The repeated construction of tools is a considerable waste of resources when a development team could simply collect what they need from git repositories, which were published during past projects. Many studios already maintain their own internal wikis of such tools, which should be released to the public (O’Donnell, 2014, p. 208). The second is for the length of obligation to be defined by project life-times. Currently, NDAs are typically set to last for a number of years, and developers can only release information once their agreement expires. While the contract should have an ultimate expiration date, the publisher must also agree that once a game is released, the development processes designed during production will no longer be considered a trade secret. This prevents any spoilers or critical knowledge from leaking when it matters, and allows information to enter the public domain as soon as possible, where it can be most useful. This includes postmortems of development, management strategies, pipeline descriptions, and architecture for commonly seen features. The exceptions to this should be future plans, and the source code of the released build of the game. These are especially important not to release for multiplayer games, or games-as-a-service models.
While publishers have the final say in the matter, indie studios may be the catalyst needed for change. Indie studios, especially those who self publish, enjoy much more freedom in terms of how much information they can share. If indie developers begin normalizing the release of tools and development strategies en masse, their reinvention of open-source development culture may make its way to AAA studios, and eventually influence publishers to release their choke hold. O’Donnell (2014, p. 209) points out that many developers believe that their experiences in development are wholly unique, suggesting that no one else could use them. This should not deter developers in such an incredibly powerful position from publishing their tools anyway. Their use may be surprising.
If one thing should be apparent, it is that crunch is not an easy problem to solve. Often, management strategies like Agile, Scrum, and DevOps are framed as the solution to prevent overtime. However, if addressing crunch was as simple as adopting a framework, it would not be as big of a problem. Even still, most companies either don’t completely implement frameworks (Bishop, 2019, p. 9), or don’t fulfill their criteria effectively (Edholm & Lidström, 2016, p. 13). A management approach intended to improve productivity and ensure quality does not entail that it will also prevent crunch. As a result, the solutions I compiled here do not make a management framework, although they do borrow from implementations of others. The reason they are listed here is because they are specific practices that directly address the causes of crunch. Since these solutions do not make any sort of closed system, they are in no means complete. There are undoubtedly many other solutions that I did not find, or have not been described yet. The same can be said about the causes.
Should other causes or solutions be brought to light, the classifications proposed in this paper can be utilized. Causes can be appraised for whether they are a source or a method, which will inform developers how they should be approached. Sources are tangible challenges that must be addressed directly through management strategies and action. The difficulty sources present is that they cannot be simply stopped forever, but will require constant diligence as they are faced in every project. On the other hand, methods are perspectives and thoughts that require a long period of time to reverse through constant exposure to contradicting evidence. The challenge these pose is maintaining habits long enough so that a team’s culture can be effectively reconstructed. Newly identified causes can then be addressed with solutions at either the team, project, or individual level. Placing a solution into a level tells the team who is responsible for its implementation, how long the practice will last, and what the fallback solution will be if a level fails.
I hope that the solutions I’ve found are sufficient, and perform well when integrated. However, I did not collect any empirical evidence to support their success, but rather relied on others’ experience and secondary research. Just as Keith (2020) makes clear for his advice, not everything that’s suggested in this paper can be applied within a team, depending on the situation they find themselves in. While being able to use all of the solutions presented here would be optimal, different contexts may negate the viability of certain solutions, or require them to be augmented. These cases are what the level stratification is meant to account for, but developers need to remain aware of whether certain solutions will be beneficial to them, or simply unproductive. Forcing a solution that can’t be implemented due to the team’s resistance, or from having conflicting practices will likely cause crunch instead of prevent it.
Crunch will always be a challenge within the games industry, but just because it cannot be eliminated completely, does not mean it shouldn’t be mitigated to the highest degree. Developers, studios, and publishers alike must approach crunch with the intention to remove it from any project they are involved in. The threat crunch presents to developers, the games they make, and the industry as a whole is simply too great to ignore.
Archontakis, I. S. (2019). Agile development in the video game industry : Examining the effects of iteration and methods of limiting it. Umeå universitet, Företagsekonomi.
Bishop, D. A. (2019). Part 1 - The need for metagility. In Metagility : Managing agile development for competitive advantage. J. Ross Publishing. This was used primarily to gain a better understanding of Agile principles and implementations.
Caccamese, A., Bragantini, D. (2013). Beyond The Iron Triangle: Year Zero. PM World Journal, 2(12). https://pmworldlibrary.net/wp-content/uploads/2013/12/pmwj17-dec2013-caccamese-bragantini-beyond-iron-triangle-year-zero-ipma-SecondEdition.pdf.
Cote, A. C., Harris, B. C. (2021). “Weekends became something other people did”: Understanding and intervening in the habitus of video game crunch. Convergence (London, England), 27(1), 161–176. https://doi.org/10.1177/1354856520913865.
Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. IEEE Software, 33(3), 94–100. https://doi.org/10.1109/MS.2016.68.
Edholm, H., Lidström, M. (2016). Crunch time: The causes and effects of overtime in the games industry. University of Gothenburg. https://gupea.ub.gu.se/bitstream/2077/44655/1/gupea_2077_44655_1.pdf.
European Innovation Council and SMEs Executive Agency. (2021). Non-disclosure agreement: a business tool. Publications Office of the European Union. https://op.europa.eu/en/publication-detail/-/publication/e412838c-f015-11eb-a71c-01aa75ed71a1. This was used to get a better grasp on NDAs as a practice, and how they are typically deployed.
GDC, Coster, S. (2020, April 3). Stress-free game development: Powering up your studio with DevOps [video]. Youtube. https://www.youtube.com/watch?v=t9HRzE7_2Xc.
GDC, Gardner, A. (2019, December 30). Time IS on your side: Personal time management strategies for crunch [video]. Youtube. https://www.youtube.com/watch?v=iRrcH3BuKfE.
GDC, Keith, C. (2020, September 4). Taming the chaos: Lessons in project management [video]. Youtube. https://www.youtube.com/watch?v=M0uuDsjy4b0.
GDC, Tomandl, R. (2020, December 18). Embracing ambiguity: How to do good work when you don't know what to do [video]. Youtube. https://www.youtube.com/watch?v=4DWdnoLosZ8.
Godoy, A., Barbosa E. F. (2010). Game-scrum: An approach to agile game development. Instituto de Ciências Matemáticas e de Computação (São Carlos, Brazil). http://www.sbgames.org/papers/sbgames10/computing/short/Computing_short19.pdf.
Kuutila, M., Mäntylä, M., Farooq, U., & Claes, M. (2020). Time pressure in software engineering: A systematic review. Information and Software Technology, 121, 106257–. https://doi.org/10.1016/j.infsof.2020.106257.
O’Donnell, C. (2014). Developer’s dilemma : the secret world of videogame creators. The MIT Press.
Peticca-Harris, A., Weststar, J., & McKenna, S. (2015). The perils of project-based work: Attempting resistance to extreme work practices in video game development. Organization (London, England), 22(4), 570–587. https://doi.org/10.1177/1350508415572509.
Take This. (2016). Crunch hurts: How unmitigated overwork harms employee health, productivity, and your studio’s bottom line. Take This. https://www.takethis.org/wp-content/uploads/2016/08/CrunchHurts-TakeThis.pdf.
White, M. M. (2019). Breaking Out of the Games Industry (1st ed.). CRC Press. https://doi.org/10.1201/9781351119306.