Last week, an interesting discussion happened on Twitter following Cuphead’s win at the DICE awards. The executive producer talked about the challenges of designing the game and how they went all in; taking a second mortgage out on their house to finish the game. Many indie developers talked about how this is not the norm of what it means to develop a game over a long period of time.
For today’s post, I want to talk about something that no game designer wants to hear: How do you know when to stop working on your game?
“When it’s Done”
Ask a game designer when their game is going to be finished and they will usually respond with the phrase above. As we’ve talked about, game design is not an exact science, and however long you think it will take, chances are it’s going to be longer.
The beauty of being an Indie developer is that most often you’re not going to have shareholders or a publisher demanding that you release your game. With that said, the longer it takes to make a video game, the harder it’s going to be to recoup that cost.
Game Design is different from other consumer-base industries. When you’re building a car or making a movie, there is a literal endpoint that everyone working on the project knows. For a video game, it is always possible to keep adding in the hope that it will make the game better.
Given the hit-driven nature of the industry, developers know that they really only have one chance with their game to be that breakout success. Succeed, and they could have the next Stardew Valley; fail, and their game will disappear from the public eye.
That creates a lot of pressure to get it right, but how do you know when it’s right?
Success in the Game Industry is not the same for every company. One studio’s massive hit could barely pay the bills at another and the same goes for game design.
With so many games being released on a daily basis, it’s becoming harder for new games to stand out. The good news is that the video game market is not built on direct competition; IE: Someone buys a platformer and then they will never buy another one.
The issue is with discoverability, and how developers have had to raise the quality of their games in order to be noticed. The days of surviving off of basic video games are over; consumers today want quality without having to spend a lot.
Combine that with the hit-driven nature, and you can see why developers want to spend as much time designing a game as possible. However, that creates a big problem: What needs to be in your game to be a success?
As a developer, it’s impossible to know what features are going to make your game successful. If you take your 10 level long game and add in 20 more levels, does that mean your game will make twice as much profit?
Design vs. Money:
Continuing our line of thought, it’s time to talk about costs. There is no fixed cost for designing a game with exception to hardware/software used. In other industries, the quality or rarity of the materials used can help to dictate or put a value on the product.
Game design is different, and it’s impossible for the consumer to equate design/work to cost. How much do you price a 10 level platformer? What about an 80 hour RPG? Or a two hour narrative game? Let’s get one thing straight: There is no direct ratio of time spent on a game to the amount of money it brings in.
The one factor that people understand is content. The bigger your game, the more attractive it can be to the consumer. Even though that sounds simple, it takes us back to the first question of this piece: When do you stop?
Kitchen Sink Disaster:
More is not always better; both from a consumer point of view and the quality of the good. In my previous post about the “Fast Burn Syndrome” I talked about the temptation to go big with a game. When you combine complete freedom with the desire for a success, you can see how games can spiral out of control.
It is very easy to take an easy that could have been a modest or big success, and complete sink it with additional features, systems, and work. The most famous example of this would be the original concept for Duke Nukem Forever, and how they kept raising the scope of the game instead of just putting out one game.
We’ve spoken about the core gameplay loop of your game before, and if you create content that obscures it, you run the risk of making a bloated game. Figuring out how big you should make your game should always go back to the core gameplay loop, as that is essentially the foundation of your title.
Now there are ways to mitigate the risk that we’ll talk about in a minute, but I want to touch on the Cuphead discussion before wrapping things up.
The Chicken or the Egg Quandary:
Cuphead, like No Man’s Sky, received attention after getting backed by a major publisher. As the executive producer talked about, that’s when they decided to go all-in with the concept and raise the scope of the game.
I’m going to make this next statement as clear as possible: NEVER BET YOUR STUDIO ON AN ANGEL INVESTOR COMING IN TO SAVE THE DAY.
We’ve seen this from indie developers with the idea of pitching a kickstarter or early access game on the hopes that it will get noticed by a publisher to let them make the real version of their title.
Cuphead’s success presents an interesting discussion: Did Cuphead succeed because of the quality of the game and the passion of the developers alone? Or did it succeed thanks to Microsoft noticing the studio and what they were making? The story of Cuphead could have swung either way: A massive success, or a studio losing their house.
A lot goes into having a successful game beyond just the design. Once a studio has a big hit, chances are that notoriety will carry on through their next title. We know that whatever Studio MDHR works on next will get noticed by the major sites, but what happened if they failed? Just as success can elevate a studio, failing for any reason can doom it.
When is it done?
One of the hardest aspects of game design is knowing if you have a great idea. Just because you and your friends like it, doesn’t mean that the consumer base will. One of the most important steps you can do to mitigate that risk is to get eyes on your game as early as possible. It’s better to find out what people like/dislike about your game during the prototype, as opposed to two years into development.
This is why iteration is an essential part of game development, and knowing what to keep and what to scrap. At the end of the day, it always goes back to your core gameplay loop and how much you can get out of it. Remember this: No video game can stay in development forever; at some point you must declare it finished, or at least at version 1.0.