Constructive Criticism Isn't Constructive
Critics Aren't Developers, Nor Should They Be
There’s an awful lot of game development advice floating around these days, of wildly variably quality. I’m going to write about that, but before I do I thought I’d address why I don’t offer much advice myself.
I occasionally get asked why my criticism isn’t “constructive” - why I criticize games but rarely broach how to improve them. My answer: that question reflects confusion about what “constructive” criticism is and what function critics serve.
The Meaning of “Constructive”, Real and Imagined
If you replace “writer” above with “game developer” you get a real sentiment rather than a joke one: that “constructive criticism” is when someone says “I’m not a game developer but….do that.”
One example of this mindset is this misguided ResetEra forum post.
Many people make the mistake of pointing out a flaw in a game, and explaining in detail why it is a problem, and leaving it at that. That is not constructive. Constructive criticism must explain how something can improve, not just where it falls short.
For some reason “constructive” has come to mean “possessing suggestions.” But suggestions are usually less useful than a well-articulated explanation of a problem. Even at game development studios a spot-on description of a problem isn’t common. A programmer is just as likely to say “this animation looks wonky” as “this would look better if the initial frames used hand-tweaked tangents.” An artist might complain that the camera is “sluggish” without pegging the culprit as frame rate, inertia, or input lag. A detailed explanation of a problem is extremely useful. It’s often more useful when it’s not mixed in with a specific suggestion for a fix, since that shifts the focus to debating a likely ill-considered solution.
If players tell developers exactly what they dislike that serves a useful purpose - it’s “constructive.” The developer can come up with the solution - that’s what they get paid for.
Critics Aren’t Game Developers
Critics don’t make games1. It’s not their job to improve them, nor is that a job they’re good at. As a purely technical point, most criticism is post-release. If your review of Mario Wonder includes “constructive” comments like “I think the game would be better if Mario could jump twice as high” you aren’t constructing anything beyond an idle musing. There’s almost no chance the dev team is going to patch the jumping to please you, and your off-the-cuff suggestion is probably bad anyway. Criticism in aggregate can improve a live service game or inform a sequel, and criticism can in theory improve the medium as a whole over time, but criticism of a particular game is unlikely to “construct” anything.
It’s commonly understood that players and playtesters are good at identifying problems but bad at identifying solutions - or really are good at identifying the symptoms of problems. But some people expect critics to excel at identifying solutions. That’s not their job and not something they have practice in or training for.
On GameDeveloper.com I have an older blog titled Ostensible Improvements: When Better Isn't. It includes this anecdote:
I once worked on a game that was sent out for a mock review / analysis. It came back with a list of suggested improvements, and when we made all the improvements and resubmitted it the response was “you did everything we wanted but ultimately the game isn’t any better.” Which was disappointing but unsurprising — if mock reviewers knew which specific changes to make to improve a game they’d probably be game designers.
In that case it is the job of ex-media consultants to offer suggestions, but I think that’s a job with limited usefulness. Doing mock reviews to predict critical reception makes sense, it’s a logical extension of doing game reviews. But an ex-reviewer offering design consultation is like a movie critic offering script consultation - it could work I guess, but I wouldn’t pay for it. At least the reviewer-turned-consultant is learning game design or has some affinity for it - there’s no reason to expect a currently-working reviewer to have special design insights. (Though game reviewers might on average make better game designers than a person plucked at random)
None of this is a knock on games media. Media members can successfully transition to game development - Insomniac’s creative director used to write for EGM, for example. But reviewing games and making them are separate skills. There’s no reason someone who writes about Apple products couldn’t become an electrical engineer, but there’s also no reason to expect them to have meaningful electrical engineering insights.
Of course some critics are game developers - myself, for example. But that I could play someone else’s game, think about it for a few hours, then articulate exactly how to fix it is far-fetched - I can’t reliably do that for the games I’m paid to work on! Fixing up up games is a job, not a one-off essay.
I’ll close out this section with an exchange between film-maker Sidney Lumet and film critic Pauline Kael.
The real rift between Lumet and Kael came on "a very difficult evening" when the two of them got involved in one of those boring conversations about the function of a critic. "There were two other people present," Lumet recalls, "and she said to them, 'My job is to show him' -- pointing to me -- 'which direction to go in.' I looked at her and said, 'You've got to be kidding.' She said, 'No, I'm not.' I said, 'In other words, you want the creative experience without the creative risk.'
“Here’s How I’d Fix that Starfield Rain”
Above is a photo-mode Starfield screenshot - as you can see it’s a bit borked. The rain only falls in a visibly small area around the player, and most noticeably the squiggly distortion effect is also constrained to that area.
There was a discussion of this on Reddit with many people saying “they could easily fix this by parenting the rain to the camera instead of the player” as an “industry-standard” solution. In particular, one person who claimed to be a developer argued it was an easily-fixed unforgiveable error that exposed the developers as clueless.
It takes a certain arrogance to play a game for 10 hours, think about it for 1, then write “here’s how I’d fix it.” This guy looked at a single screenshot and immediately knew how to fix it and that the people responsible for the error were incompetent.
The Redditor who claimed the Starfield rain was an unforgiveable sin worked on Battlefield.
According to the Washington Post
“Battlefield 2042,” its developers at Dice and publisher, EA, have been harshly criticized by players for its buggy state and lack of industry standard features since its November 2021 release.
Oh.
Fundamental attribution error is, more or less, the belief that when other people screw up it’s because they suck, but when you screw up there’s a reasonable explanation that lets you off the hook. If you asked this Battlefield dev why their games are buggy their answer wouldn’t be “my own fundamental incompetence.” It would be lack of time and budget, unrealistic expectations, maybe bad management or bosses, a flawed process (at a different org level than this guy occupies, of course), etc etc.
When a Battlefield dev on Twitter (side note: it’s so often Battlefield devs - what’s going on guys?) complained about the Elden Ring UI people pointed out that a) Battlefield 2042 didn’t ship with a functional scoreboard, something that’s been standard for decades and b) the design of checkboxes made it impossible to tell if an option was on or off.
If you asked this dev why their game shipped in that state their answer wouldn’t be “I’m just bad at my job.” So it doesn’t seem fair to assume that the Starfield or Elden Ring devs are bad at theirs.
Here are a few points I’d make about the Starfield rain:
First, virtually every AAA game ships with more severe bugs - crash bugs, progress blockers, falling through the floor, quests refusing to unlock, framerate issues, etc. To pretend that this is an extraordinary failing is absurd.
Second, there are a dozen plausible explanations for why this problem exists and why an “industry standard” solution wasn’t used. The photo mode could have been a late addition. The rain may correctly be parented to the camera, but the photo mode uses a second camera. Parenting the rain to the camera may have been tricky due to engine and workflow-specific reasons. The photo mode may have been given to a junior dev without much oversight. It could have been a quick implementation that was always going to be improved later, but other issues became more pressing.
Or it could just have been an oopsie.
That’s not to make excuses. The rain is a problem and ideally would be fixed. But the game devs saying “here’s how I’d easily fix it” have, without question, shipped games with bugs as bad or worse, including bugs they’re personally responsible for. So a natural rejoinder to “here’s how I’d fix your game” is “why not fix your own?”
Improving Games is Hard
The gist of Ostensible Improvements: When Better Isn't is that sometimes “objective” improvements don’t make games appreciably better. Adding more mechanical depth in Tacoma didn’t make it better than Gone Home. Improving the combat of Silent Hill with Homecoming resulted in one of the worst games in the series.
In Why Artifact Failed I wrote what I consider the definitive2 examination of the problems with Valve’s Artifact. Now here’s the shocking follow-up: Valve released Artifact 2.0, which fixed many of the problems I identified - and was a worse game.
“Fixing” the game stripped away some of the character and replaced it with effectively crowdsourced content. Some of the solutions were worse than the problems - a big issue in 1.0 was that the board was spread out over three screens. The solution - cramming it all into one screen - made the game harder to parse visually and significantly uglier. A standout feature of Artifact 1.0 was strong production value; it wasn’t that fun but it looked well-crafted. Artifact 2.0 looks pedestrian by comparison. In some cases Artifact 2.0 fixed problems only to repeat variations on them. Confusing card text was removed then replaced with different confusing card text. Overly-complicated systems were simplified only for an overly-complicated shop to be added.
The Artifact 2.0 changes were close to what I would have suggested, but that didn’t result in a better game. Which is why I don’t often make suggestions about games I’m not working on. When I am working on a game a suggestion is the first step of a process.
How I’d Fix: The Callisto Protocol
As a refresher, here’s what I wrote about The Callisto Protocol:
Here’s how I’d fix the game: I wouldn’t.
There’s low-hanging fruit to pluck: improve the misleading tutorial flow and text. Allow for players to dodge just-in-time instead of requiring well-in-advance inputs. But I don’t think fixing the tutorials would do much, because as I often argue, tutorialization can’t fix flawed systems, and often can’t even make them more understandable. The game is a conceptual miss with a low ceiling - hard to greatly improve without redoing at least the combat.
How I’d fix: Lies of P
Here’s what I wrote about Lies of P:
One of the issues with dodging in the game is that when you dodge into an enemy you don’t collide-and-slide off of them, instead you get awkwardly stuck on them. So my solution would be…fix that.
Now how to fix that: no idea. Maybe the character controller has no ability to collide-and-slide off of other character controllers, so that would have to be added. Maybe collide-and-slide is turned off because it made the character feel too slippery, and should be turned back on in certain cases. Maybe it’s an issue with the character controller interacting with limbs, and the solution depends on the exact physics implementation, depenetration logic, etc.
“It’s bad that you get stuck on guys when you roll so make that not happen” is the best I can do - as an outsider I could phrase that to sound more sophisticated I can’t come up with a more sophisticated solution. Nor do I need to - the team that made Lies of P was competent enough to make the game, so they’re probably competent enough to figure out a solution to this particular problem.3
A Series of Disclaimers and a Conclusion
Advice and suggestions aren’t always bad. Sometimes teams can become blind to serious issues. When developing a game you become saddled with a complicated history - maybe you tried something two years ago, it didn’t work, and you mentally filed it away as a bad idea, but circumstances have changed. In that case an outsider suggesting even an “obvious” old idea is helpful.
While game development is hard and often takes specialized knowledge or training, I don’t want to give the impression that everyone who isn’t a certified professional is an unsophisticated rube who should keep their mouth shut. It’s not impossible for players or critics to have genuinely useful suggestions, they just don’t have a high hit rate. And personally I find critique that focuses on “here’s what I’d have done instead” is often more ego-driven than interesting.
There’s nothing wrong with offering suggestions, if it’s not done in a sneering style. But there is something wrong with expecting suggestions, or dismissing criticism that doesn’t come with them as “not constructive.” The majority of players and critics are better served focusing on clearly identifying issues rather than brainstorming solutions and new features. Some critics write “poor level design” or “unengaging combat” and leave it at that.4 If you can’t say why the combat is unengaging your proposed changes are almost certainly underbaked.
As a critic it’s fine to say “it’s flawed and here’s why” and leave it at that. And as a developer you have to swallow your ego and consider that feedback, rather than reject it as impolite.
Present company excluded
This sounds haughty but try to find a better one!
I have no idea if this was actually fixed in the final version
Sometimes due to length constraints I suppose