Good enough.
Via KnowYourMeme.
You might be familiar with the classic quote from Paul Valéry that goes something along the lines of “A work of art is never completed, only abandoned.”
It’s a quote that resonates widely because pretty much all disciplines can relate to it one way or another - one my favorite variations on it came from a friend back in college lamenting before sitting for an exam that “studying is never completed, only abandoned”.
It’s a phrase I think about often. Game development is complex and requires multiple discipline experts working on individual elements that eventually come together to become something greater than the sum of their parts. Most developers are passionate about their work and want to do the best job possible before moving on to the next piece.
But the best job possible takes a long, long time! And there is so, so much to do. How do you know when to stop working on something?
It usually falls upon producers to help navigate the conundrum between giving developers the time and space to do their best work while also making sure the project does not go over schedule or over budget. Here are some different lens I’ve used to think and talk about this topic with others.
Diminishing Returns
Diminishing returns are a concept from economics that refers to the idea that not all work you put in will have equal return on investment: the work you put in initially will usually have the highest return, but eventually you will hit a point of “diminishing returns” where the work you put in gives you a smaller return for each unit of work.
One way to understand this concept is to think about crunch. We can all agree it’s not a best practice, but it’s common because it works — the additional hours invested by the team will result in more progress. But we can also agree that the team will probably not be as productive in those extra hours as they’d usually be working their normal schedule, which is an example of diminishing returns. As illustrated by the graph, if the team continues to crunch past their limits they might even hit a point of negative returns, and the additional hours they’re putting in might be causing new bugs or mistakes that will actually generate more work for the team in the long run.
But I digress — what does this economic concept have to do with game quality? When talking about this with developers I try to explain two ideas with this concept:
- The initial phase of creation is naturally “more productive” as you’re creating something from nothing, but you will eventually hit a point where you are polishing something that already exists. This inherently will mean more effort for fewer results!
- Too much time spent polishing can actually result in negative returns, as you may start to rework parts that were perfectly fine and/or put effort into details that aren’t actually improving the player’s experience.
A common way I’ve seen people put it is “the last 10% is 90% of the work”: going from good to great is as much effort, if not more effort, than going from nothing to good. With that in mind, the question I ask people is “What does 70%, 80% or 90% finished look like? Which level do we need?”.
The Best vs. Simplest Solution
There’s this really good video where Jonas Tyroller, an indie developer known for titles such as ISLANDERS and Thronefall, interviews Ricard Pillosu, a veteran game developer with 20+ years of experience across AAA and indie who is currently a co-founder of a 30 people team called Epictellers.
It’s a long listen, but what makes it so interesting is that Jonas generally tries to probe Ricard on how to write “better” code or systems, but Ricard’s responses are extremely pragmatic — he’s quick to point out that no matter how smart your developers are, an easy to understand and maintain solution will generally trump the “best” or “smartest” solution in the long run.
As someone who went to school for computer science, this hits especially close to home. Many programmers are passionate about their craft and want to do the best work possible when writing code tend to design, impressive, elaborate systems that show off their skills, but these system can end up overengineered, like trying to kill an ant with a tank. While there is a valid argument to try to overengineer a system to make it future proof, the iterative reality of game development can sometimes mean that the future you’re proofing for might never happen.
That said, Ricard is quite modest and also admits the limits of this approach too: for example, they took this “simple first” approach when developing the skills system for their current game, Starfinder: Afterlight, but eventually realized that it was too simple and had to refactor the system as a result. But even if it doesn’t work all the time, preferring the simple solution by default usually balances out to be a time saver.
This has been a bit engineering focused, but I still try to ask all developers “What’s the simplest version of this we can build? Can we try doing that before we build the best solution?”.
75-20-5
I’ve had a draft for this post for a while now, but a couple of weeks ago Rami Ismail wrote an excellent entry for his Leveling The Playing Field newsletter that captures the same concept much more elegantly than anything I could have written.
You should definitely go give it a read, but the gist of the of the article is that having a clear definition of “good enough” is also extremely important to make players have a great experience with your game. Just like “peaks” and “valleys” only exist in relation to having land at an “average” height, to have a truly incredible moment in your game it needs to be incredible in relation to the rest of the game — and that’s easier to achieve when most of the game is “good enough”.
While there’s definitely a natural creative tendency to plan production in this manner, I’ve seen many techniques to formalize it, such as letter grades, categories like Gold/Silver/Bronze, or the 75-20-5 rule Rami uses in his article: 75% of your game has to be good enough, 20% has to be good and 5% has to be great. By defining clear standards for each category, it becomes much easier to define how much work is “enough” for the quality you’re aiming for.
Hope you’ve found something in this article that was useful! One of my goals when I started writing this blog was to be a bit less of a perfectionist and write “good enough” posts more regularly, so there’s something a bit meta in writing about this…
Until next week! If you enjoyed this post, sign up to the newsletter to receive them in your inbox each week: