My CD Projekt RED story, part 2

Once the Blood and Wine expansion was wrapped up, the crunch period has ended for the majority of the teams at CDPR. Since there was quite a bit of downtime, the QA team started a series of internal trainings. These would cover many aspects of game development and were presented by embedded QA testers and designers alike.

Downtime learning

I signed up for as many of these trainings as I could and presented a lecture about audio myself. It was a blast, you could feel the dedication each of the lecturers had to help their peers grow as developers. Around the same time one of the gameplay designers started an internal C++ course, which I immediately signed up for. The concept of programming have always intrigued me. I made multiple attempts to learn how to code before, but would always give up sooner or later. In spite of me getting the syntax quite easily, I just couldn’t see how these skills I was learning could actually be used. When I enrolled on the internal C++ course, I hoped I would finally get the chance to learn how code can be used rather than how to write it. Unfortunately, after a couple of lessons I had to drop out because my everyday duties demanded too much of my time.

Catching the programming bug

Those first two lessons were not any different from the courses I tried before, so I felt like I wasn’t losing all that much anyway. It all changed, however, when one of the tech QA analysts gave a lecture on how he and his colleagues had used JavaScript to script up custom behaviors within the Google applications. Suddenly, it all clicked. I started seeing multiple areas where I could apply this new scripting knowledge. I would jump at every opportunity to script things up to improve the more tedious processes that I had to go through every single day, manually. One of those processes was managing a huge production spreadsheet that the Gwent production team used to track development progress of each card in the game. Multiple times a day, I would open this spreadsheet and based on various assets’ states I would mark the audio column as either ready for work, blocked or requiring fixes due to changes of already existing assets. I cannot think of a task more braindead than that, I felt terrible having to do this so often. So I wrote a script that would kick in on every edit of a cell in the spreadsheet and then send notifications to the audio team’s mailing group whenever a set of predefined conditions were met. This was such a time-saver I would end up being rewarded an Honor Point for my efforts. An Honor Point was at the time the highest award you could get in the studio. It directly influenced your share in the next yearly company profits sharing bonus.

Getting my hands dirty with development

The moment when I started solving actual problems with my newly acquired scripting skills marked a turning point in my career. At the same time, while some sound designers and I were assigned to help out on Gwent, I also got my hands dirty with audio implementation for the first time in my life. I already made some content commits for Blood and Wine expansion, where I placed sound occlusion volumes to prevent underground sounds from being audible on the surface, but this can hardly be called proper implementation work. I started off small, with fixing synchronization issues for premium card sounds, but quickly moved on to improving the behavior of sound while the cards were cycled quickly in the deck, and eventually I took on the implementation of audio triggers in Unity. Actually, I was the only person in the audio team to do this work, because none of the sound designers had the time to learn a new game editor.

HR issues brewing

While all of these great things kept happening, there was also a bleak foreshadowing of the troubles that were to come. It all started during Blood and Wine expansion, for which our junior sound designers had their first opportunity to create and implement assets of their own making. As can be expected, their work was vetted by the teams senior staff. Unfortunately one of the seniors was not the easiest guy to work with. I’d rather avoid going into details on just how miserable this guy made his colleagues feel, hoping that some of them will come forward in the future and tell their stories themselves. I can however share, that his feedback would very often boil down to ‘that’s shit’, without any guidelines on how to improve the work presented. Over time, the interactions inside the team became so dysfunctional and toxic that after the Blood and Wine internal post-mortem a sort of a group therapy session was called, held by the companies internal training officer. The only result of that meeting was that the conflict became even more heated. Some people threatened to leave the company if the toxic guy was not dealt with. In the end, the solution our producer went for was to delegate the guy full time to Gwent, while the rest of the core audio team was to get onto the preproduction phase of Cyberpunk 2077. This was definitely not the right way to deal with the issues, but it did mean the people who were hurt the most were afforded some respite from the constant stress. Sadly, a new audio team was soon formed specifically for Gwent, and some members of this new team became the troublemakers new victims.

The Witcher 3 Saviors

It might seem unbelievable at first that these sorts of problems do not get addressed properly in CDPR. The studio has a sizeable HR team and each development team has an HR partner assigned to it. In theory, this system seems fine, but my own experiences with HR paint a rather gloomy picture of how it works. It’s something I will elaborate more when describing my experiences in the audio programming team later on. In CD Projekt RED, there is a group of people who are literally untouchable. Regardless of their performance as developers or their behavior towards their colleagues, they are never the guilty ones. Me and some of my friends called these people ‘The Witcher 3 Saviours’. And that’s precisely who they are. Those are the people who survived the Witcher 3 crunch and are among the ones who are considered to have saved the project from collapsing. These people are untouchable today because of their past. Many among them are those who had crunched the most and got rewarded with lead or director position for it, regardless of the fact that they lack the basic skills required for these roles. These people were never trained properly to manage people, apart from an initiative called "The Managers Academy" that's generally considered as completely ineffective. Generally speaking, the Saviors live by the conviction that since they have shipped the Witcher 3, they know the recipe for success. They often refuse to consider development practices that differ from theirs, opposing workflow improvement ideas that could save people from crunching in the future. If something was done completely manually in the Witcher 3, the Saviors would counter any attempt at automating, redesigning or restructuring these solutions. These people are now the ones calling the shots in some of the departments. Their underwings, who very well realize that some processes have to change to avoid the crunch from happening again, have to fight for their ideas with all their grit. Whenever they lose one of those battles, they fear the consequences those defeats will have on their future. The memories of the Witcher 3 crunch come back to them. The company has lost a great deal of both former and promising, new developers due to these kinds of interactions. At some point, many people prefer to quit and move on to a place where their insight and ideas would be valued. After all, is it worth sacrificing so much energy trying to reason with people driven by personal convictions rather than data and actual feedback? Apart from crunch, many of the oldschool solutions were prone to certain issues and/or prevented the designers from fully realizing their vision. The fight for these antic practices to be left behind goes on every day in CD Projekt RED and in my personal opinion, this is a significant factor in the rate with which the company is bleeding talent. However, I do have to point out that there are teams lead by competent professionals. These teams have strong leaders who are not afraid to stand up and protect their team members. I would genuinely recommend them to any developer seeking employment at RED. There are also some that I would recommend people stay away from, for their own sake.

Yet another turning point ahead

Up until this point, my career at CDPR was an experience filled with constant improvements and discussions with people truly committed to make both the games and the process of making them easier and less chaotic. All of this was about to change once I joined the audio programming team. Part 3