Chicken-or-egg problems

What came first, the chicken or the egg?

How do you build levels if you don't know what weapons you'll have?
How do you concept a creature whose abilities you don't know will work?
How do you design recipes and loot progression when you don’t know how long the game is yet? But how do you know how long the game will be if you don’t have progression?
How do you start prototyping a game if you don't know if it's single-player or multiplayer?
How do you make sounds for units that don't have models or animations yet?
How can you design a world for a game that you can’t play yet?

These are only a few of the horrors that face us - these problems are all around us when we start making a (original) game. They cause more insecurity, angst and torment on a daily basis than any other class of development problems, besides perhaps running out of money or team dynamics. They also create extra meetings, documents and a lot of wasted brain cycles as seemingly smart people try to figure out solutions to these tempting, infinite problems.

You probably know the feeling. Your mind wants to wrap around these problems. It feels like real research, the real meat of development. There’s always more research to be done, more meetings to have and more insights to have. But in the end, we get nowhere and we exhaust ourselves. We're stuck. This isn’t game development. This is misery.

But once we realize we have a circular problem like this, a chicken-and-egg class of problem, we have a way out. The mustn't continue to design or think. We must take action, even when facing the unknown. We must build our way forward.

Here are some ways to do this.

Build with placeholders

When exploring a mechanic but without knowing the context or genre of the game, we can stub in placeholder goals. For Subnautica, we knew the game was about crafting and exploring underwater, but we didn’t know if it was more sandbox or goal-oriented. So our early prototypes used a placeholder goal to “Find 5 Treasures”. This wasn't what the game was about and we knew it never would be. But it got us moving and able to evaluate the crafting and exploring without agonizing over everything else. Once the low-level stuff was working well, we had made enough progress elsewhere that we knew we wanted to make it an open-world game. After we worked on that for awhile, adding story happened automatically.

Instead of designing the world, we put in a placeholder for it in the form of a heightmap. We thought we wanted caves, overhangs and voxels, but to start it was good enough to have a simple heightmap. We stayed at this level for a couple months, during which time we learned a lot about how we really wanted to layout and build the world. We knew how big spaces needed to be to handle large subs, we knew how to make big open ocean less boring and knew how oxygen worked. This was validated learning, which formed a solid framing and base we could build upon. It put a stake in the ground somewhere.

Make provisional decisions

We had to decide what minimum system specs we wanted to commit to for Subnautica. This felt impossible, as we didn't have even half the game built. We barely knew what it was about - how could we possibly decide with any certainty what our poly count might be, or what graphics fidelity we needed? There was no way to know and we could've been left paralyzed.

But instead we made a provisional decision. We decided we'd be ecstatic if we sold a million copies and so looked at another game that did that and didn't run on the best systems (I think it was Space Engineers). We decided we could change our minds later, but for now, we would fully commit to its minimum specs. It was good enough for them, then it would at least temporarily be good enough for us. The key is to know we could change this decision later. That empowered us to make the decision quickly, removing us from our trap.

Whether you actually change the decision later or not doesn't matter as much. What's important is to keep moving.

We did the same with single-player and multiplayer. It was so hard to build both single-player and multiplayer, we were stuck trying to support both with the size of our team. So we quickly decided to support single-player, and that we could add multiplayer later if it was successful. We focused completely on that and the game was indeed successful. Now we have the option to rework the game or make a sequel that will focus on multiplayer - whether we do or not isn't the point. We got unstuck and made something instead of being stuck in quicksand (spoiler: no plans to do so yet, sorry!).

Ignore entire disciplines

Stop thinking about entire disciplines that are halting progress. Examples include:

Ignore art and build a prototype devoid of setting and theme.
Ignore programming by building a paper prototype.
Ignore game design by building a world and then forcing game design to make a fun game with whatever the artists and level designers create (we did when creating the huge world of Subnautica). Or ignore game design by committing to an unfun but playable prototype.
Ignore level design, programming and game design by making an animatic instead. This lets you find and communicate the ultimate experience quickly.
Ignore business and make a game that's free and fun (a mod). You can figure out if it's for sale, F2P, using a license, etc. later.
Ignore production and build your game knowing you'll throw it away. Then build it a second time, using what you've now learned.

There are infinite variations here, but boldness can get you unstuck.

Know it's a process

Realize that there is no "final" or "finished", there's only progress. Building an original game isn't about perfection or any destination, it's about moving forward, making mistakes, course-correcting, and hopefully moving forward again. "Not knowing" isn't bad - it probably means you're on track.

Like with puberty, just knowing that your difficulties are normal can make you feel better.

Conclusion

These techniques can help you get moving again. Use them when meetings run too long, when talking takes the place of progress, and when development slows. Use them when you find yourself talking and convincing more than building and experiencing.

They can set a direction and create momentum, even if that direction will later change. Suddenly "natural" decisions present themselves automatically from the bad stuff you built in the meantime.

Your path will reveal itself when you stop searching for it and instead start walking into the darkness.

Thoughts or questions? Join the discussion on Discord or get in touch.