Don’t Start With Your Dream Project

I wish more beginners to game development understood the incredible momentum that they can build from small projects.

When I ramp up inexperienced programmers, my goal is to give them tasks that are small and challenging enough for them to make many small mistakes. As they gain experience, I want them to work on larger and more challenging features, and have them use the experience around their mistakes to mitigate the impact of larger pitfalls.

In a sensible game studio, we put protective guards around the impact of failures from inexperienced people. The nuances of large pitfalls are lost on the inexperienced and can have great costs on a product.

Contrast that with a more experienced developer, who has the knowledge and the tools to see emerging problems earlier, try out disaster avoidance and recovery techniques, and learn a variety of useful lessons from the potentially big and looming problem without tanking the project. Building a foundation of good experience makes all the difference.

The Beginner’s Fallacy - Trying to Outrun Scope

You might naively think that extensive plans, great ideas, or good code architecture lets you skip the small, less exciting projects, that you can jump straight to your over-scoped dream.

Unfortunately, as a beginner you aren't actually capable of making big plans without first making small mistakes and learning.

Jumping into your dream project early is the equivalent of dooming it to fail. What you're actually doing is punching holes in it and destining it to sink. You're making it undeliverable, and it will fall far below your high expectations.

I've had great but too big ideas that I thought would turn into full games. They all ended up as learning experiences that didn't get released but helped me in my next project. While they returned some value, if I'd have scoped them correctly I would have learned even more, and they could have been published too.

Use scope control. Maximize learning and minimize risk of project failure.

Releasing projects that you're proud of is what you want to achieve at the end of the day!

A Healthy Core Loop

Just like games, developers have a core loop too. Let’s look at a few and compare how healthy they are.

Unhealthy - The never ending dream project

Here’s how this pattern usually goes.

  1. Come up with big new project idea

  2. Work on project, make many mistakes, struggle with problems, learn some new things

  3. Rewrite feature after feature

  4. Repeat from step 2 until project is abandoned or released 10 years later

In this loop, you make 1 unreleased or disappointing project in the time you could have done 10 other projects.

Unhealthy - Always over scoped

You may abandon your dream project for another project that is also too big, and this is how it plays out.

  1. Come up with big new project idea

  2. Work on project, make many mistakes, struggle with problems, learn some new things

  3. Realize project is unrealistic

  4. Repeat from step 1

In this loop, you make several unreleased projects of the same scope until eventually releasing something 5+ projects later.

Healthy - Start small, increase scope

Do this instead!

  1. Come up with small new project idea

  2. Work on project, make many mistakes, struggle with problems, learn some new things

  3. Release flawed but completed game

  4. Come up with new, slightly bigger project idea

  5. Repeat from step 2 with new game

In this loop, you make several released projects of increasing scope.

You learn valuable lessons and release projects.

The Scope Trap

Let’s look deeper at the examples above. Starting small makes the most sense if you break it down.

Someone with a track record of published projects of growing scope is confident with ambitious projects, and exudes trust.

  • After 5-10 projects, they can confidently make large scoped games or features in a fraction of the time as others, since they learned from a variety of different mistakes and see pitfalls early.

  • They can play out ideas and architectures in their head and foresee how they will work on a long time horizon.

  • They aren't scared of failure because they know they can start something new and try again.

  • They naturally attract other people to join them with their strong track record of releases.

Someone who always picks projects of too big of scope learns many of the same lessons over time, but sadly don't have released projects in their portfolio.

  • They have trouble attracting others to their projects because they have little to show.

  • They can see a variety of pitfalls early, and develop good architectural sense, but they lack experience dealing with real users and can only guess how to deal with a live game, which hurts their chances of success when they do release something.

Someone who works on the same over-scoped game for a long time takes a very big risk by putting all their eggs in one basket.

  • They learn from iterating on the same features multiple times, but slower because they work on a smaller variety of features and architectures.

  • They have trouble attracting others to join because no one else wants to risk their time on a never ending pet project.

  • They have good, specialized knowledge of a single game genre but may have a lot of trouble adapting to their next project if it's different.

  • They are very afraid of failure because they have no experience with it. Failure is dangerous for their mental health because of the stakes involved.

  • No possibility to hit small successes from 10 smaller projects.

A healthy scope isn’t just good for your project, it’s good for your health.

You can increase your velocity but you can't change the laws of physics, and the physics of game development says outputs of small become inputs to big. You'll find many places to express your unique creativity in everything you do, big or small. So start small and move quickly if you can. It will not be time wasted.

But Wait, You’re Special

There are a few archetypes of people who believe they are the exception to the rule and growing progressively doesn’t apply to them. Let me address those I commonly see.

“The Extreme Planner”

Some people think that they can skip to a very hard project early by making very detailed design docs and thinking of things upfront.

A good plan can get you one step ahead of the curve but not 10. If you want to beat a hard boss, the solution is to fight the boss several times and think about what you learned, not to do endless theory-crafting to beat them on the first try.

The simple truth is that having real experiences and being able to reflect back on them leads to better insights than ruminating over hypothetical ones.

Don't get lost in intellectual problems beyond your level, you can grow into those shoes.

“The Pain Avoider”

You may think that lowering scope is itself a failure. Or you subconsciously avoid small projects because they aren’t impressive. You might prefer to work endlessly on a project because seeing it fail on release or giving up on it is too painful to bear.

The truth is, failing is painful, but not for as long as you think, and leads to incredible learnings. Failures are an integral part of the road to success, so the pain of experience is worth being actually able to achieve what you set out to do.

This identity is one I struggled with and overcame through many learning experiences. I don’t fail less but I recover quickly and learn fast. It is no longer that painful, and can even be exciting to fail.

“The Gamedev Speed-Runner”

How I created a multiplayer FPS in 20 minutes with no programming experience!

How I made a game start to finish in 4 HOURS

Your time is valuable to you, so you want to race to the finish. The problem is, your dream project is a 100 mile race and without practice you’ll be exhausted at mile 2. Speed-runners play a game over and over for years to become fast, and even then it’s extremely challenging. Imagine betting your happiness on breaking a record on a game you’ve never tried, on your first attempt.

You can learn a lot from 24 hour game jams (and I recommend it), but you can't learn everything for your dream project by unrealistically timeboxing projects over and over.

Fundamental to making software are a whole class of problems that take grit and trial and error to get very good at. When you find one of these challenging problems, the 200 IQ shortcut is to actually to slow down. These are the experiences you spend 5 days struggling on but learn 10 new things that make you faster and faster on future problems. Doing this is the real speed-running strat.

Summary

Grow by taking the time to grow into the person you want to be. Set realistic project goals, create a lot, and be patient with yourself.

Find projects that are a balance of challenging but achievable. If you fail, learn from your mistakes and reduce scope. Don’t get stuck in loops or endless searching for shortcuts.

You won’t start your dream project tomorrow, but you’ll set yourself up to finish it when you have the right number of cycles in, and release a bunch of games in the process. This is the fun path, take it! 

Alex Naraghi

Game Programmer. Augmenter of code.

Previous
Previous

Do Job Research

Next
Next

How I Remembered the Kanji