Stop Doing Your Best Work in Game Dev

Read Time: 7 Minutes

If you managed to build the best game dev team in the world, here’s two principles they would follow in their work:

1. They would only work on the most important things they could find. If it wasn’t the most important work they could be doing, they would stop and go do that work instead.

2. They would only take each piece of work to a barely sufficient quality level. Once it was “good enough” they’d move on to the next most important work.

No matter how many people and how much money you had available, if you got your team to follow these two principles, whenever you ran out of money you would have gotten as much of the most important work done as you possibly could have, given your team and budget.

This is an ideal worth striving for! It’s hard to do, there’s a ton of nuance in both points, “easier said than done” as they say, but if you could pull it off, that team would give you the best shot at producing something amazing.

The first bullet (only working on the most important stuff) is intuitive to most people. The difficulty is in figuring out what the most important work is and then doing only that. 

But the second bullet, this idea that we’ll do barely sufficient quality work… that one’s a bit trickier. For many a game dev, it runs against our intuition. We don’t want “barely sufficient” work, we want amazing work!

So when I tell you that I think you should err on the side of doing work that doesn’t meet the bar, instead of exceeding it, I know I’m probably ruffling some feathers.

It’s true though.

All other things being equal (warning: they might not be), you are better off stopping before what you’re working on is good enough than going too far. 

Let’s explore why.

The Cruelty of Diminishing Returns

Every song, game, movie, character, book, and etc. humans have ever made could be improved. None of them are perfect. If you had a proficient expert, they could go through every game you’ve ever played and point out little flaws and mistakes made, errors in the art or story, ways the design could be subtly improved.

Even your favorite things are imperfect. It’s the nature of the creative endeavor. As we used to say at Riot, no champion is ever done, we just stop working on it.

And why? So we can ship it and move on to the next thing. Perfection, as they say, is the enemy of good. It is the unreachable and subjective and shifting target that we may aim for but will never achieve. 

And if everyone at Supercell, or CDPR, or Valve were completely obsessed with perfection and only moving on once it had been achieved, they’d all still be working on the first few assets and features of their first game, trying to hit that infinite quality bar. Realistically, they’d have gone out of business long ago.

League of Legends doesn’t need one perfect champion. It needs a ton of imperfect but pretty darned good champions.

The game you are working on doesn’t need perfect code or the best possible feature or an immaculate main character. It needs code and features and characters and story and etc. that create the compelling experience for players you are aiming for.

What this means: all work we put into a game is not equal in the value it returns. And the deeper you go on one asset, the less you get back for it. Conversely, as you get closer and closer to the unattainable “perfect,” the more effort you need to spend to make it even better.

Here’s a couple of charts to help:

On average, after a small bump at the start, the closer to perfect you want to be, the more effort you have to put in. Effort grows exponentially, and you never get to 100% perfect.

Now let’s look at value vs perfection:

On average, after a bit of a slow start, you get a pretty nice ramp where making things better adds a lot of value, which then tapers off dramatically as you get close to 100%. It’s shocking how much value a game can get out of an asset that’s just barely working and only took a day to throw together. But spending another two weeks polishing a part of the environment may net you almost nothing.

This is reflected in all kinds of truisms like, “The last 20% takes 80% of the time” or the 90/10 rule that 90% of the outcomes result from 10% of the efforts, and etc.

So if effort doesn’t create perfection at a linear rate, and perfection doesn’t lead to value at a linear rate, then effort expended is not the same as value gained.

In fact, it is EASY to spend massive amounts of effort and get very little value out of it. In my experience, this is COMMON in game development. Developers in all disciplines focus on creating more and more perfect things at a higher and higher cost. Even ignoring the subjectivity of “perfection” for a moment, this is a bad trade!

Way before we realize, we’re in diminishing returns on whatever it is we are doing. The tweaks become smaller and smaller. The improvement to the player experience becomes more and more negligible. The time lost though, that’s gone. You spent two days trying slightly different shades of blue for a cape. You don’t get that back. Time lost is linear. 

And in game dev time disappears faster than anyone expects. 

Choosing What To Improve

Imagine that all games could be broken down into a set of categories. Based on what your game was intending to become, the audience, and the impact you were trying to have on the world, you set a target “quality” for each category between 1 and 10. (By the way, if you’ve never done this, it’s an interesting alignment check on a leadership team)

You have high expectations for gameplay and performance, but you also want a pretty strong story and some good progression systems in there. You’re not as worried about the long-term viability or cohesion of the IP.

You can probably think of a game that looks something like this.

Your devs are constantly investing time to learn and build so you can create this amazing game you want. How do you go about building this thing?

I think a common approach people take is to use their craft expertise to always go above and beyond. You want to outperform expectations. So, whenever you are thinking about the quality bar, your objective isn’t to hit it, it’s to exceed it. Everyone everywhere is doing this all the time.

This shifts the target quality bar of the studio a bit. It takes the actual target higher.

Remember the value to perfection and effort to perfection charts I mentioned above? Well, to get these higher quality bars across the board, we have to invest more effort than we expected. But hey, we’re game devs, and our job is to exceed expectations! We’re not settling!

And everyone is thrilled with this. As each individual asset comes in, it’s even better than it needed to be. The team is psyched, you’re making an even better game, gosh does it look good. The publisher loves the high standard!

And then you hit the point of realization: you don’t have enough time. Your runway, well, it’s running out. Yes, the publisher is loving it, but it’s not quite a game yet, even though you’ve got a ton of high quality stuff everywhere, and your investors are getting concerned about spending more.

Suddenly your whole approach shifts. No longer are you able to exceed expectations. That seemingly endless three year runway you had is into the last 14 months, and things aren’t where they should be. You spent a lot of time in “diminishing-returns-land,” and now it’s time to pay the piper.

The quality bar drops across the board. We go from multiple iterations to make sure each walk cycle is just right, to just making sure it kinda works in game without breaking anything. That extensible feature we thought about building other things on top of? That’s the prototype, and it’s shipping like that, because we have zero time to spend improving it. 

When you first started this whole thing, someone made a plan, and they did their job of adding buffer and even added a two month window at the end of development before launch called, “Polish.” 

Now, the buffer is gone, and so is that polish window. Some people might think, “Well, stuff took longer than expected, and we’re just not going to have that time.” I think it’s more accurate to say, “You already polished. You just did it before you knew what was important to polish.”

The above story (or some variant of it) happens a lot.

In the end, you don’t make that many meaningful choices about what to improve. All your time is spent just trying to get something out the door. People blame estimation, they blame the publisher, they blame the red ocean you were going into, they blame leadership, they blame all the usual things.

But the reality is, you spent a lot of time way before you should have, trying to get higher and higher quality. The effort to quality line fought you the whole way, burning hours and days you didn’t have. 

You spent way too much of your time here…

…spending a lot of effort for not much real value.

In the end, the quality of your game is all over the place. Performance (both smoothness and bugginess) is not in a good spot. A game limps out the door, but it falls far below the goal you had. And for the last 6 months, it felt like you had no agency, no ability to change anything, you just had to keep trying to grind out stuff you weren’t proud of and hope it all worked out.

The Alternative

So imagine you went back in time to before the last 6 months. Let’s say you went back to the very beginning. How could you approach this differently?

Let’s keep the same targets, but you start by having serious conversations with all your individual contributors/discipline leads. 

You don’t want to be overshooting the quality bar, you want to be undershooting it. Yes, absolutely, we want to make a high quality game, but the quality of a game is much more about everything coming together and investing in the right key elements than it is about every category being high quality. 

So you tell people to undershoot, to do less than they might think they want or need to. This doesn’t mean everything starts as a “2” in the quality bar, mind you! Some things might still be very high! But you want the bias to be towards under-delivering rather than over-delivering. 

Not everyone is thrilled with this, but you walk them through the possible futures: do you want to burn all our effort on stuff that might not matter so that everything is high quality individually, but the game may not be great, or do we want to spend less time getting more done, and then having the choice of where to spend our resources?

They get onboard. You’ve basically convinced the team to spend more time here:

You are getting more value for less effort.

The outcome of this is a less flashy game with less polished assets, but that is actually coming together holistically. It’s not a bunch of great pieces, it’s a cohesive whole that starts to show you where more investment will win, and where it won’t. 

And now, when you get to the “buffer” and “polish” parts of your plan, one of two things probably happens. 

1. You don’t have time anyway, but at least the game is complete and man are you glad you didn’t overinvest in every asset for the first 18 months of development.

2. You do have time, and what you’ve learned means you get to really focus on leveling up the most important parts of the game, while leaving the stuff that really doesn’t matter as much as it is.

Either way, this is a better place to be.

Summary and Takeaways

There is so much more we could go into about this topic. The subjectivity of perfection, the way a large “AAA” studio thinks differently than a small indie dev, the way those categories are ridiculous and can also be subdivided almost endlessly, how the little graphs I made up don’t apply all the time to everything, the importance of establishing a clear quality bar, and on and on.

Let me know if you want me to dive more into some of those details in a future newsletter.

For now, here’s the concrete things you can do to improve your chance of making a better game:

1. Recognize that not all effort is created equal. Your job isn’t to be always working, it’s to be working on what returns the most value.

2. Encourage people to show their work early and often. Don’t let people go off and work on something till it is fantastic. Get people to show their work “before it’s ready”, and then see if it is actually good enough. It will be, more than you realize.

3. Set expectations that we’ll be looking and working and playing stuff that isn’t great, and that we EXPECT you to produce stuff at that level. 

4. Do the alignment check with your team or your fellow leaders. Break your game into its pieces. What needs to be a 9? What would be fine at a 2? Figure out what the target is, and then work with the appropriate disciplines to not overshoot early on. 

Remember, if we work only on the most important stuff to a “just barely good enough” quality bar, you will get the most important work done that you possibly can with whatever your team and resources are.

That’s why I’m telling you to not always do your best work. Good enough can be good enough.Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].