I’ve been thinking about how I am going to approach the long term development of games. I’ve done a bit of reading on what other developers have experienced and what pitfalls to avoid. I think one of the prevailing sentiments is that the longer a project takes, the more likely it will have problems. Human beings are terrible at planning for the future, we have plenty of cognitive biases that make planning difficult into the future.

I want to talk about a few games to open up the discussion:

• Duke Nukem Forever
• Team Fortress 2
• Tobias and the Dark Sceptres
• Antichamber
• Stardew Valley

Duke Nukem Forever and Team Fortress 2, both had pretty long development cycles: Duke’s at 14 years and Team Fortress 2 at 9 years. Whilst Team Fortress 2 is a beloved classic and Duke was a giant flop, the difference is complex, but they both have a few similarities. They both went through multiple engines, and reworks in gameplay.

The other three games, are all developed by a single person so they are of extra relevance to my situation. Tobias took 13 years to develop, Antichamber took 7, and Stardew Valley about 4 and a half. All three games went through a lot of rework, and had a psychological cost in their development.

Here is my list of lessons learned:

Start as small as possible when you’re learning

The less experience you have, the smaller the game should be. It’s not a good idea to start your dream game like Tobias or the science-based dragon MMO. Focus on a really small mechanic, and keep the overall scope of the game as low as possible. Think of a vertical slice or a prototype as the goal, something to show off the main idea, but the overall amount of levels small.

You’ll improve your skills

Improving on your past skills in programming, art, sound and music means the components of the game made in the past will be of worse quality than the new stuff. That improvement will then tempt you to replace parts of your game.

Long projects lead to lots of cut content

All the games mentioned, the ones that turned out well and the ones that turned out poorly, had a lot of iteration. The longer your project, the more you’ll replace, rather than creating something new for a different game. Stardew Valley’s townsfolk were “redesigned at least ten times throughout development.” This can get to a sickening level if you move to an entirely new engine or other technology.

Technology changes quickly

Over time lots of different tech comes out that could affect the games development:

• New consoles
• New tools to develop with
• New operating systems (for PC & mobile)
• New versions of tools
• New ways of playing (motion controls and VR for recent examples)

On a long enough time scale, you’ll either have to stick to whatever technology you have when developing (and have potential compatibility problems) or incur a delay in migrating to a new set of technology.

Psychological burden

Antichamber’s developer Alexander Bruce, went through a tremendous amount of stress developing the game and (so far) seems pretty convinced not to make anything else. Eric Barone, developer of Stardew is more positive in the end but still had issues during the development:

“Imagine playing the same game, every day, for four and a half years. All day. I was just absolutely sick of it, I was bored,” he says. “I didn’t even have an objective sense of if the game was good or not. In fact, I thought it was bad.”

Variety is the spice of life

I think part of that psychological cost is the sheer repetition in the long run. Working on something new when a fresh new idea comes to mind is far more satisfying than grinding on the existing project. If the development cycle is short and you actually finish the games, then you can experiment with a lot more ideas. Experimenting with a wider range of ideas gives more breadth to your experience, which can help with finding new ideas and solving new problems.

Rotten to the core

I like to think of games as a core idea that forms the nucleus of what defines the game, and everything else supporting that. If the core idea isn’t that fun, a longer development cycle likely won’t make the game become more fun. Ideally you develop a prototype, see if the core idea is fun, and then either push forward or stop at that point.

Cost and bugs

It’s obvious that longer projects will cost more, which, given enough time can cause the entire project to fail and everything to go bust. The other major concern is that as your software project grows, so does the complexity, and the likelihood of serious bugs occuring.

My plan is to build and finish projects in ascending size, where I think 3-5 years is the point to stop at. There are exceptions to the these guidelines, but I think they apply for most people (and perhaps across multiple disciplines too). I also understand the irony of talking about this when I am at the start of the journey rather than after I’ve gone through this process to test it out, but I hope I can apply this process for my own success.

Links on what I’ve mentioned and other related stuff:

• Stardew Valley
• Duke Nukem Forever
• Antichamber
• Team Fortress 2
• Tobias and the Dark Sceptres
• Derek Yu’s advice on finishing a game

Books I want to read that discusses these topics more:

• Art and Fear (this also has the story about the quality/quantity ceramics teacher)
• The Mythical Man Month