2020 has been one hell of a year, and as we reach its final stretch, a topic on lots of folks’ collective minds is crunch in game development. While it is not a particularly new topic (see LA Noire, The Last of Us (Original & Part 2), Doom (1993), etc), the catalyst for the current outburst regarding this prickly subject is the looming release of CD Projekt Red’s Cyberpunk 2077—a massive open-world game from the acclaimed developers of The Witcher 3. It should also be noted that the release of The Witcher 3 had also been plagued by reports of toxic crunch culture, which is ultimately what led to CDPR saying “Cyberpunk 2077 won’t have crunch.”
And then Jason Schrier reported, “well, yes, actually it will—for 6 weeks.”
This report showcasing the dichotomy of words to actions lit social media aflame, and there have been many takes from multiple angles. Folks lamenting the cruel nature of crunch, the human cost, the willingness for developer participation, et cetera.
And then they delayed it again.
This has led to a lot more social media discourse and outrage questioning how genuine CDPR is with their PR, the necessity (or lack thereof) of crunch, if delays actually help, etc. It is a tough subject, and one which people have a lot of feelings on.
With all of that being said, an angle I’ve not seen being given much light is that of a working developer. So… Hi.
I’ve been a professional software developer for the past 7 years, and a hobbyist developer well before that. I currently hold a senior development role with a large company, and spend the majority of my working week tapping buttons on my keyboard and making programs come out. On top of my everyday development roles, I have also been a project manager, hiring manager, and software architect. While my current position is not in games, the first few years of my working career were, and I have also made games as personal projects.
That’s the short version. The even shorter version is that I’m a developer, and have thoughts on dev cycles, mental health, burnout, and crunch both in the game industry, as well as outside of it.
I would like to preface all of this by saying that, from here on out, this is largely my opinion based on experience, as well as consulting with other professional software developers. I will do my best to link to concrete examples where applicable, but because a lot of things I’ve worked on are NDA’d, any specific examples I give will likely have been abstracted, or have their details changed. If you are reading this and have feelings, I urge you to tweet at us, leave comments on this article, or generally get in touch with me—feedback and criticism both are very welcome here.
Development 101 – What it means to be a dev
Before jumping straight into my thoughts on crunch, I’d like to try and contextualize what it’s like to work as a developer—at least at a high level. If you are already familiar and comfortable with development terms, please feel free to click here and jump directly to my thoughts on crunch.
In an idyllic society, everyone would be able to work as much as they want within the hours during which they feel able. Their needs would be met, there would be no looming anxieties due to lack of health insurance, lodging, nor salary. Deadlines would be fluid, and whatever project is being made would only come out when the creators are satisfied. This theoretical world applies to software/game developers, musicians, authors, artists, or those working in any other creative medium.
For a lot of solo creators, this can be reality! (Well… The deadline part, at least…)
If it is your own project (for the sake of this post, let’s stick within the coding world and say it’s making a game), you set the pace, goals, and standards. If you feel that you need an extra few months to polish up one of the core mechanics, or add a new level, or fix this one part that’s broken and crashes the game—all of that is wholly at your discretion. Of course, there are always going to be tradeoffs to any of these decisions. While we are currently ignoring any kind of monetary obligations, there is one resource which every human has a finite amount of—time.
After several months of development, perhaps you come to the realization that you’ll need to implement a new feature which requires expertise you don’t currently have. In order to do it yourself, you’ll need to spend a few weeks or months learning how to do that. Is that time well spent to you? Maybe, but what if your best friend is already an expert on it and is willing to help? Great! Let’s invite them to the project.
So now your project has a team of two! One is the loneliest number, after all—so thank you, friend. This change comes with a problem, though. The moment a project adds any amount of people beyond the solo creator, the dynamic changes immediately. No longer are you able to be as fluid and freeform as before because you now have certain inherent responsibilities to which you’re beholden.
For example, if whatever part you’re currently working on blocks the progress of your other teammate(s), they are left waiting until you’re done—and vice versa. This brings us to one of our core tenets in software development—accountability.
Accountability is arguably one of the most crucial parts of any team. Without getting too didactic, it ultimately boils down to knowing you can trust your team to accomplish a goal which has been set. A programmer is accountable for creating code which works. An artist is accountable for creating assets which fit the aesthetic. A sound designer is accountable for making high-quality audio. A narrative designer is accountable for writing a story which makes sense for the characters involved. Et cetera.
This accountability is a core part of development because, on top of making sure you’re getting things done, working on a team is an extremely social activity. Communication is paramount because you need to interact with your teammates, clearly and confidently make decisions, and describe the ideas for what will be created in a way which will be understood and executed upon. For the last point, there is a big difference between “make that character jump real cool” and “give the character a double jump, wall run, the ability to grab ledges, and do backflips.”
This naturally brings us to the concept of tasking. When it comes to code, you rarely implement a full feature such as “character movement” all at once. It gets broken down into smaller, more digestible tasks. One could be tuning the walk and run (speed, how long it takes to start/stop, etc), another could be adjusting the jump (height, velocity, etc), another could be figuring out how a character lands (fall damage, etc), and so on. It’s best to take care of these tasks discretely because then you can tune each part individually, and have the codebase reflect it. After all, it’s much easier to have multiple smaller files/classes/methods to make changes within rather than one giant monstrosity which is impossible to traverse. It is also much harder to fix a bug if everything is all in one blob.
To think of it another way, consider what happens with strands of old Christmas lights versus more modern ones. Lights which are wired up in parallel give you a clear indication of which bulb is burnt out because it’s the only one which is dark; but if they’re wired in series, one bulb knocks out the whole strand and then you have to go through the whole thing just to find the culprit. The more modular approach is how most teams choose to approach coding because it is the one which facilitates both accountability and communication the most.
Okay, that’s probably low level enough. To bring us back to speed, we now have a team, and we are aware of the concept of tasking. By creating tasks, this helps us communicate which exact part of the game or code someone will be working on, and that ultimately means it will be easier for that team member to be able to tackle the task with accountability.
Being organized and tasking with clear intent alleviates a lot of problems which can quickly become overwhelming as a team’s size increases (though, honestly, also for solo devs). While our initial example had a team with 2 members, let’s bump that up a bit. If we are now in a team with 15 members, communication is huge because small changes have much broader impact.
If we are working on an action game, maybe our character can use multiple weapons. If our player starts with the ability to use a sword and a bow, let’s also give them an axe. Easy, right? We have a weapon system in place, no problemo. Except… Maybe problemo.
There are multiple decisions which need to be made. How big is the axe? How fast does it swing? How wide is the swing? Do the enemies get knocked back? How much damage do they take? Does it ignore armor? What does it look like? What does it sound like? While “giving the player an axe” seems like a pretty small task on paper, it’s actually pretty big because now this will be radiating through multiple members of the team. Our artist, coder, sound designer at the very least—and if the team is big enough to have a gameplay designer, then it will include them too. Extrapolated a bit further, any future changes you make to the axe will also radiate. If it’s decided that the swing was too fast and now it needs to slow down, there will need to be changes to the code, animation, and sound.
As a game gets bigger, these seemingly small changes radiate further and further. It is what makes the best RPGs so impressive, the multitude of systems which interact with one another and the ways in which they are balanced. However, without some kind of direction, things can quickly get out of hand and become confusing for team members—especially if their particular purview is relatively limited in scope. Again, this brings us back to accountability and communication; but this time, a step higher.
There are a multitude of ways to manage a team of developers. Generally, in modern software development, the two most common methodologies are that of Waterfall and Agile. These days, it is safe to say that Agile is the methodology of choice, and one of its major benefits is that accountability comes along for the ride. So what does it mean for a team to use Agile?
Agile splits work up into “sprints.” Rather than running one extremely long marathon where we have a final product at the end, by breaking it up into smaller sprints, we cover the same distance but have iterations of our game all along the way. Each sprint typically lasts anywhere between 1-4 weeks (the most common among places I’ve worked at being 2 week sprints), and within each of these you are bringing in a certain number of tasks which a project manager feels the team can reasonably complete. Team members are able to judge how big or small a task might be, and ultimately voice their opinions for whether they think the amount of work assigned is possible in the amount of time allotted.
Hey, remember time from 15 paragraphs ago? Welcome back, old friend.
By breaking our tasks up into sprints we are no longer looking at a macro timeline with one big scary deadline right at the end, and instead are looking at one with multiple smaller deadlines along the way. This helps us predict how much work is feasible based on the bandwidth of each individual team member, as well as what milestones we aim to hit by the end of each sprint. Maybe the first milestone would be “having good character control,” then the second is “adding a weapon system,” the third is “adding the sword and bow,” et cetera. This gives our teams direction, and we can start to have a clearer vision for when our game will come out!
But remember back when we were a solo developer? Wasn’t it great having the freedom to kinda take however long we wanted? Well.. Maybe for some people; but in my opinion, I’d say no. The best work I’ve ever done has been when there are deadlines attached to it. An idiom you start to clash with without deadlines is that “perfect is the enemy of good.” Something you’re working on might already be good, but if you keep tweaking because you want it to be perfect, you may never actually finish it and focus way too hard on the minor details (even though “good” is often good enough). Without deadlines, without accountability, without communication, without tasks, a lot of amazing ideas end up never seeing the light of day because the scope gets too huge, the developer sees no end in sight, and they burn out while trying to chase perfection. Again, said from experience.
As mentioned, the moment a team grows to have more than one member, we as developers need to trust and respect our teammate(s), just as much as having them trust and respect us. This applies horizontally (with other members of our team), and vertically (those managing our team, and those we manage).
So what about crunch?
Crunch is a difficult topic because multiple people might have multiple interpretations for what it means in practice. The broad interpretation I most often see conveyed on social media is that it’s working hours well beyond your expected workload. In other words, if you’re supposed to work 40 hours in a week, but you’re routinely working 60, 80, or even 100 then that is crunch.
There is validity to this interpretation, but as a developer I see it a bit differently.
To me, crunch is somewhat comparable to the feeling of cramming the day before a test. It is the looming stress you feel with a rapidly approaching deadline, and the internalized anxiety that if you don’t put in a bunch of extra effort, you might not be ready in time. It is a very negative, and not overly productive feeling. However, crunch isn’t something you can boil down just to that feeling, it’s also a question of responsibility. Let’s say the online service I manage goes down and none of our 500 000 users can access our application. It’s 7:00 PM on a Saturday, which is well outside of work hours. Do you address this issue on Monday morning, or do you fix it now?
If you are the only one who knows how to fix it, chances that are you’re going to fix it as soon and as fast as possible. That spike of effort and anxiety, that looming urgency—that is crunch.
Spikes like that are pretty much impossible to avoid, and they are largely unpredictable. For the most part, that’s not what people seem to be talking about when crunch enters the dialogue. They are usually talking about a more sustained crunch. In the case of CDPR, a crunch of six weeks. Or, at this point, likely more.
While the “spike” version of crunch can be extraordinarily stressful, it is also fairly short lived. The fix could take a couple dozen minutes, maybe a day or two at the most, and then it’s over. Sustained crunch is far worse. Sustained crunch subjects you to that level of stress and pressure for weeks, sometimes months at a time. This is the kind of stress which makes people quit, leave the industry, burn out, and tragically, take their own lives. It is an extremely serious topic, and a systemic issue which disproportionately plagues the game development industry.
To speak relatively coldly, sustained crunch is a symptom. Respect and trust amongst teams go both horizontally and vertically. Oftentimes, sustained crunch is due to a break in this chain from the vertical direction. In the case of CDPR, it is impossible to say where this break is due to it being a black box.
For context, in the development world we have what is known as “black-box testing” and “white-box testing.” Consider a black box to be like your TV. You push the power button and the screen turns on, but you aren’t really expected to pay attention to how the electricity is crossing the circuit board, capacitors, resistors, and ultimately making the LEDs (or OLEDs or whatever) create images on your screen. If you ever run into a time where the TV doesn’t power on, chances are that you will black box test for the reason. If we can deduce that it isn’t the power cable, then we have to assume it is because of something inside which we cannot see. Due to that, we likely can’t guess at which stage it is breaking, and will have an expert inspect it. White box testing would be the opposite, where we know all about the internals in question and are testing it with full knowledge. Basically, whoever you call as the TV repair person can pull the back off of it, and with their tools do some white box testing with a combination of expertise and tools available.
So to the majority of us, CDPR is a black box. I cannot reasonably assume at which level the failure is happening, but I feel strongly about two things regarding their instance(s) of crunch and delays:
- It is likely a failure in some level of management, not in those directly working on the game
- It is a systemic problem in the games industry
To start, let’s address our first point and also reference back to some of our key terms.
Firstly, it is a matter of time. The original release date was a set deadline, a deadline which has now been moved back multiple times. If proper time and sprint management is in play, signs of this should have shown up early—for example, if milestones were being missed or pushed back (However, to play devil’s advocate, it can be quite difficult to properly estimate complex software from an early stage, and the act of consistently underestimating the complexity of tasks can lead to what’s called “scope creep,” which can snowball into delays down the road). To compensate for that, sprints can be used to build in a small spike of crunch in predictable ways. For example, if Milestone 3 missed its due date at the end of its associated sprint, maybe Milestone 4’s sprint requires the team to put in a bit of extra effort to fulfill both milestones 3 & 4 by the end of it. That might mean some team members will have to put in a bit of extra time during that sprint, which is certainly not ideal, but it happens (and a good company will compensate that time by either being flexible with future time off, or fiscal compensation).
It is also a matter of accountability. Just like a programmer needs to be accountable to an animator, and an animator needs to be accountable to a sound designer, etc, the managers need to be accountable to their teams. The game’s director is the one who has the highest level view of everything, including timelines. This should be passed down the chain. I do not have any idea what the internal structure is like at CDPR, but let’s say that there is a manager for each team (code/programming, audio, animation, modelling, story, quest design, etc). So each of those managers report to the game director. Then each of those managers might have project managers below them managing sub-teams (maybe the code teams have subteams for combat systems, character ability systems, dialogue, UI, audio integration, animation integration, etc). Each team is given their tasks, and they trust that their managers are respecting their available bandwidth, while also being mindful of milestones and deadlines.
Evidently, there is a failure somewhere within that chain because there is a history of sustained crunch, a current period of sustained crunch, and numerous missed deadlines. Again, due to CDPR being a black box, I can only speculate. Maybe it is tech debt, maybe it is scope creep, maybe it is perfection being the enemy of good. I don’t know. I can’t say why the TV isn’t turning on, but I can say that it is absolutely a failure on some link in the management chain.
Now for the second point, and this one sucks.
The video game industry is extremely volatile, and has little to no respect for its developers.
This is said as a fact, not an opinion.
There are indeed exceptions to this rule, companies like Iron Galaxy are extremely respectful to their employees; however the exception unfortunately does not define the rule.
The game industry is wholly unique among software development because it has normalized (and, in some cases, glorified) crunch culture, which is the expectation that sustained crunch will be a part of every project. It is exhausting, and as mentioned at the very start of this article, it is not new. I recommend reading Masters of Doom, and reading about the “death march” crunches which Id Software went through all the way back in the early to mid-90s. It is very, very difficult to convey just how taxing this is on one’s mind.
The thing is, there’s always fresh talent. Students dream of breaking into the game industry, working for giants like EA or Activision become people’s goals. They may have heard about how crunch exists there, but they imagine that it won’t affect them—they are passionate, driven, and they can’t give up on their dream. Then they make it. They get the job, and they’re living their dream life. Congratulations to them! They have reached their Valhalla, and they are going to prove to everyone around them that they’re worthy to be there. They work hard, they put in dozens of hours beyond their salaried time, and they push themselves to their limits. Again, said from experience.
The games industry chews these people up and spits them out. These workers set their intense pace, and the moment they falter from it, they will trip and they will fall. This leads to burnout. This leads to exhaustion. This leads to reconsidering their goals. This leads to them realizing their wage doesn’t reflect their work. This leads to looking at what it would be like to be a developer in a less volatile industry. And so after a year or two, they leave the game industry altogether with an acrid taste lingering in their mouth, and a few more bags under their eyes.
But you know what? There’s always another passionate kid out of college who is eager to gobble up the position they left behind.
It is a brutal industry. The deadlines are harsh. The time management is bad. The respect for the developers is oftentimes non-existent (with some exceptions, love you Dave Lang). There are no unions. In fact, the people slinging code and generating assets and providing their voices and writing stories cannot unionize, and this is mandated from the top down.
However, while I am and will remain adamantly critical of the crunch culture perpetuated by the game development industry, as a player I am of the opinion that you should not avoid or dismiss a game simply because crunch was involved in its creation. While burnout of the devs involved is something we ought to address, and bearing in mind that those working on the game may have been exhausted during its development, they likely put so much time and effort into the finished game due to being wholeheartedly passionate about what they were working on. We need to change these practices for the health of the humans behind these games, but we shouldn’t let their passion go to waste.
There’s a reason I no longer work in games. It’s the same reason I know very few people who have continued working in games (of course this is not to cast shade on those I know who have stuck it out, much respect to you all). CDPR are not the first to do this, and most unfortunately, they certainly will not be the last.
As we reach the end of this journey, I’m left pondering a question. “How do we fix it?”
I don’t know. I sincerely don’t know.
One thing I do know is that “giving them an extra six months / year / other arbitrary amount of time” is very likely not the solution. This issue will not be resolved with extra time alone, it will continue happening again and again. Teams will continue being worked to the bone because of poorly thought out timelines, and young devs will continue to burn out only to be replaced by a revolving door of new devs. It is a fundamental problem which needs to be addressed which requires a deeper solution.
That being said, the public facing “it’s done when it’s done” mentality is much healthier, and one I can certainly advocate for. While that would have the downside of keeping their audience (but hopefully not investors) in the dark, it at least alleviates a bit of pressure. I would still encourage devs to set internal deadlines (via sprints, milestones, whatever they like to keep them on some form of track) so they don’t run into the perfection/good problem, but sure, it’s a potential way to make things a bit better. Another option might be that of early access, getting out the MVP (Minimum Viable Product) as soon as possible, and iterate on it in response to fan demands.
Other industries centered around software development have evolved. They provide great benefits, fair wages, respect for employees’ time, accountability from the top down, and the peace of mind in knowing crunch for them will at most be a spike—not an expectation to be sustained for the length of their tenure. The games industry needs to stop wreaking havoc on the wellbeing of their employees, and this change needs to start with management stepping up and taking this issue seriously. Iron Galaxy did it, and we should learn from them. We need to work towards making the exception the rule.
Until then, follow your passions. Do what you love. Make your game as a solo developer. Invite a friend while having both trust and respect for each other. Take as much time as you or your team need while keeping that relationship healthy. Be accountable. Respect yourself enough to recognize if the trust and respect you show to yourself is or is not being reciprocated by those around you. Communicate with care. Find reasons to smile. Neuter and spay your pets. Drink water. Vote for Joe Biden.
You can listen to the Gaming Fyx podcast at https://fyx.space. We discuss this article in detail on Episode 145 (timestamps in the description)
