This piece is very much the opinion of Leigh Harris and does not reflect the opinions of his employer.
When I was a game design teacher, my students would often declare with all the pomposity of a judge: “that game sucked!”
“Oh?” I’d ask. “And what do you mean by sucked?”
As game designers, I wanted them to be interrogating the reasons why they felt something was good or bad. We could then use them as learning opportunities – discuss them as a group and see what possible solutions they might’ve instigated if they could.
Then phase two, where I changed my question.
“That game’s strategy mini-games were awful, just so slow and unrewarding!” they’d say, somewhat improved.
“Oh?” I’d ask. “And why do you think that happened?”
This part confused them. I was asking them was to come up with hypothetical scenarios where some of the above clashes might have occurred.
Anyone can look at a game and point to a flaw. But my argument to my students was: if you can see this flaw, then likely so can the developers. Games often ship with problems the developers wish they had more time to fix.
So… a section of a game sucks / is buggy / looks rough? Ok, let’s assume the developers were aware of the issues and ask ourselves why they might’ve left it that way?
- Maybe the target market for the game mostly cared about the action, so the strategic elements were considered acceptable areas where the game could be rough.
- Maybe the platform the bugs were occurring on was the minority of that game’s player base and it was deemed ok to fix those bugs later on.
- Maybe the problem was too complicated to fix, it would push the game by many months to fix it AND could only be worked on by a handful of devs, causing unacceptable economic inefficiencies in the tail end of development.
We weren’t actually dissecting the problems of course. We were discussing what hypothetical problems MIGHT exist in game dev to prepare them for an environment where they have to make regular compromises.
It was to simultaneously get my students away from “this game is crap / this game rules” talk and into “I’m going to have to make some hard decisions in my chosen career”.
Cyberpunk 2077’s release will live in infamy one way or another, but what astonished me when the backlash started pouring in was the lack of information almost everyone on Twitter or in the media was working with.
“It just needed another six months!”
How do you know the problems didn’t stem from technical issues which would require a full re-work of some fundamental architecture?
“It was the fault of managers forcing it out the door!”
You got a source for that?
“It was the journalists somehow!”
Yeah, I’m not even gonna touch that one.
When the dust had (somewhat) settled, I found myself taking to Twitter. Not to weigh in on what MY diagnosis of Cyberpunk’s woes was (I haven’t even played it, so there was no value in my two cents there), but to argue that the only way we’ll know what may or may not have caused its issues is with a post-mortem from CD Projekt Red itself.
This is highly unlikely, of course. It’s not common practise for the launch of a Triple A game to be followed immediately by a bunch of executives and directors humbly discussing what might have been. I wasn’t and am not expecting that we’ll see anything like that any time soon.
My point was more that none of us know how this all went down. At least, not for a good long while until the pressure is off and people have moved on with their careers and are willing to reminisce.
It got me thinking of this incredible videogame history blog post (a big 45 minute read or so) about SimRefinery and the Maxis Business Simulations division that had a short lived run following the mind-blowing success of SimCity.
It’s a fascinating read which describes in great detail who the key figures were around the period when this division was operating. It goes into who was pulling the strings, what their agendas were, what decisions they each made and why, and what led to what. It’s the kind of in-depth reporting I’d love to see more of in games in general.
I’m also reminded of Vice’s less lengthy piece about the origins of the now infamous BMX XXX game. It painted a portrait of a time, a place, a chess board of players and a confluence of events which led to the tip of the iceberg: the one part the public gets to see.
So here we are again. Staring at a chaotic launch for Cyberpunk 2077, seeing the tip of the iceberg. But I find I’m watching countless people describe the whole iceberg without being able to present us with any of the key decisions that were being made, by whom, at what time, and for what reasons.
My local IGDA Facebook Group had several posts from even other developers trying to argue one thing or another.
One alleged that because they ‘had eight years’, where another dev from a different studio had had ‘only five’.
Who really knows?
I now work for a Triple A developer and I couldn’t tell you how many people are assigned to any other project than mine inside our company. I have a rough idea of how many are working on the game I’m working on right now, but would be going off a hazy memory if I were asked to state how many people had been involved each step of the way.
For all we know, the team on Cyberpunk 2077 was a skeleton crew for the first few years. We can’t assume that one year of time means the same amount of effort has gone into the project for this or any game.
One article tried to blamed game reviewers for the dashed expectations at launch by pointing to the flawed systems in which journalists have to operate, but misdiagnosed the journalists stuck in those conditions as the problem, rather than the conditions themselves.
It was this Twitter thread which eventually prompted me to write my own. In it, Damion Schubert argues that at various points throughout development, you’re going to have to throw out large chunks of your game. It may be a feature, it may be some architecture, it may be a heap of assets, but one thing’s for sure: removing stuff isn’t free.
It may take longer to build things than it does to take them out, but it’s not flipping a switch. Games often rely on the existence of other features to keep functioning, so even stripping a game for parts as it approaches launch ADDS to your workload.
The way Schubert spoke about games struck a chord with me: he was taking this moment with Cyberpunk 2077 as an opportunity to educate people – to get them to see that with complex things like games: nothing is as easy or straightforward as you think it is.
And that’s why when Byteside asked me to embellish a little on my own thoughts, I agreed to write this piece: to ask everyone to consider how little any of us really know about what may or may not have caused Cyberpunk’s various faults.
We know what ended up being broken at launch.
We don’t know what caused it.
We don’t know what it would have taken to fix it.
We don’t know what other problems those fixes might have caused.
We don’t know who made the call to ship with X problems but not Y.
We don’t know what kind of pressure they were under.
We don’t know what systems might have been in place which caused that pressure.
We don’t know how much they really understood about the state of the game or when.
These things are impossible to diagnose from outside a studio. Heck, even from inside one most people don’t have full context on every decision that gets made. Most people just know the part of this gigantic, moving beast that they’re working on.
Could Cyberpunk 2077 have been fixed, given more time and money? Probably! I don’t think the causes of its woes were so deeply ingrained that they were genuinely unfixable.
But if the time it’ll take to get your game out the door will date your game to the extent that it doesn’t hold up against its competitors? You might find you have to launch anyway. The assets you’ve made aren’t going to look better next year than they do now, and you’re not likely to be remaking all those assets each year you remain in development.
Perhaps the one big unknown which makes this launch so frustrating for so many people is a desire to know who, what, when and where.
How could someone not have seen these problems? Why did they ship knowing the problems existed? Well, to that I’d ask: did they know? I’d heartily suggest this podcast about a British airship race as a portrait for how massive complex projects can be deemed prematurely ready to launch.
As a final thought, here’s an exercise: when games ship with obvious issues, challenge yourself to try and wonder what may have happened to reach that point. See how many hypothetical scenarios you can come up with. The more you can think of, the more you’ll realise you really don’t have enough information to know what really happened.
At least, not yet.
Some Byteside outbound links may include affiliate programs to support Byteside’s operations. Our recommendations and review commentary remain independent of any potential revenue that may come through including such links.