Motivation for the Solo Indie Game Dev (with commentary by @yayfrens)

“How do you stay motivated?”

I’ve heard this question hundreds of times, both on Twitter and in person. Motivation is one of the biggest common problems for solo indie game devs. If there’s no one beside you to cheer you along, it can be really hard to keep going.

In general – the first and best course of action is to find people who will cheer for you. Tell your friends or family what you’re working on, and show them your excitement so that they’ll share it. Join an indie game dev community, either local or on the Internet, and cheer on their successes as they cheer on yours. This is a fantastic way to find support, and knowing that people are excited about your work is incredibly motivating.

Unfortunately, this isn’t always possible. Some game devs are working on projects too secret or personal to discuss. Some game devs are battling anxiety or depression. Some game devs are isolated by unsafe home situations. Some game devs just don’t click with the communities available to them. These game devs may not be able to tell people about their work, or may be unable to receive support from their available communities.

How can you stay motivated if the only one who knows about your hard work is you?

Set goals. Then complete them.

For these purposes, a “goal” is a task with an associated deadline.

Setting a goal means deciding what the task is, and when you’re going to have it done by.
Completing a goal means completing that task by the time you decided you would.

When you’re your only cheerleader, it’s important to have something to cheer about. Goal completion will give you a sense of accomplishment, and it moves the project forward, too.

Size your goals for easy wins.

Big goals – “all the art is in the game”, “all the levels are designed”, “everything has sound effects” – are fantastic, but by definition, they’re spaced far and few between. (After all, “make this game” is the biggest goal of all.)

Give yourself easy wins by breaking big goals down into little goals. The momentum of small successes will help you pull off the big one. For example:

  • Instead of “make the game”, break it down to “make the art in the game”.
  • And break that down to “make all the character art in the game”.
  • And break that down to “make the art for this specific character in the game.”
  • And break that down to “design the costume for this specific character in the game.”

Personally, I like goals that are about half a day to two days big. It keeps my brain properly happy that I’m accomplishing things, but it doesn’t add too much overhead to my day.

Keep your deadlines appropriate to you.

When I’m working solo, I am my entire team. It means that my output is confined to what I can accomplish with X amount of time, Y amount of money, and – often most critically – Z amount of energy.

If I hold myself responsible for spending Z+8 energy on my game dev project when I only have Z available, then I’ve set my entire team up to lose. I shouldn’t be trying to match the output of Failbetter, Telltale, or Bethesda, because I’m not a full-size studio. I’m just me.

How do you figure out what’s appropriate for you? I suggest starting with goals that are too low, and then moving the needle slowly up until you find the point of resistance. Here’s one way.

  • Pick a set of goals that you should be able to complete in three days.
  • Give yourself a week to complete those goals.
  • If you have time left over, do whatever amount of work feels right. Don’t burn yourself out – this is all bonus work, remember! – but don’t take a vacation, either. Just keep working at whatever speed is comfortable.
  • At the end of the week, evaluate how much work you actually did.
  • Set goals for the next week that are somewhere between the amount of work you thought you could do, and the amount of work you actually did. (I like aiming for a halfway point.)
  • Repeat steps 3-5 until you feel comfortable that you know how much work you can do in a week.

     Sometimes, this means you’ll increase your expectations. Sometimes, you’ll decrease them instead. Either way, it’s okay! This is just a calibration exercise. If you get the information you need, that’s the important part.

Avoid scope creep.


Scope creep is what happens when you add new features to a project in progress.

“Oh, wouldn’t it be awesome if -“

It might! It really might. But keep in mind that everything you add will cost you some combination of time, energy, and money.

The more features you add, the harder it will be to complete the game. Whenever you add more features to a project in development, you’re moving the goalposts. That isn’t fair to your team, no matter what size your team is.

That isn’t to say that you won’t need new features. You will. There will be things you haven’t considered, and new problems will crop up, and you’ll get complaints in playtesting, and you’ll have to adjust the design. That’s just how game dev goes.

But in that moment of “Oh, wouldn’t it be awesome if – “ take a step back and consider your idea in terms of time, energy, and money. Be possessive of your resources. Don’t add any new feature unless you’re sure it’s worth the cost to your hardworking team of you.

Document your accomplishments.

Documentation will help you see what you’ve accomplished. It’s the counter to breaking down tasks: if you go the other way, you can build small successes into medium-sized successes into enormous successes. Then you can look at your enormous successes and understand what a fantastic job you’re doing.

On Monday morning, it’s difficult for me to remember what I did last Thursday, let alone two weeks ago. Fortunately, paper doesn’t forget.

My personal approach starts with a daily log, which lives in a notebook on my desk. I set one or two goals in the morning, I note whether I made them or not, and I write down anything else I do that’s work-related. The daily logs are not impressive.

Every Monday, I convert the last week’s daily logs into a weekly digital log. That gives me a list of ten accomplishments or so from the prior week (plus whatever else I added along the way), and the weekly logs are impressive. It’s a reliable mood booster – look how much I got done last week! – and it helps me feel positive about the coming week.

And if I did have a bad week (trust me, it happens!), then I can scroll back to see the week before that, or the week before that. I have proof that good weeks exist, and I can wave that proof at my doubts until they scurry away.

If you don’t meet your goals, take the time to understand why.

Sometimes, everything goes so smoothly that it feels like the game is writing itself. It’s glorious.

But sometimes, everything crashes and burns. I hit the end of my week and realize that I’ve completed half a goal… maybe… if I fudge my original goal.

It’s really tempting to wad the bad weeks up and toss them away. But it’s helpful to figure out what happened first, because maybe you can prevent it from happening next time.

Sometimes, you can’t. If the answer is “family crisis” or “friend in hospital” or “sick for three days” – there’s nothing to do but give yourself a hug and try again next week. And that’s the right course of action.

But sometimes you can prevent it next time – either by changing the plan (example: “It took forever to draw this monster, so I’m going to palette-shift five monsters instead of drawing fifty unique monsters.”) or by changing the process (example: “I had a massive slowdown because I didn’t understand this technology, so I’m going to document research tasks separately from coding tasks in the future.”)

In cases like those, a little reflection now can save a lot of heartache down the line.

Celebrate your personal progress.

When you work on a game, you’re not just making a game. You’re gaining skills, knowledge, and experience. These will be valuable not only for this game, but for all your future games, and perhaps for non-game projects as well.

Sometimes you’ll be struggling to understand something new. That can be really frustrating and overwhelming. (I wrote about this back in December.) But struggling means you’re learning – and that alone deserves pride. Learning is hard!

And if you struggle long enough with something, a day will come when you’re not struggling any more, and a day after that when it’s effortless. Then you can look back and say “Wow. Was I really having all that trouble just three (weeks/months/years) ago?” and feel incredibly pleased with yourself.

Be kind to yourself.

A mistreated car will eventually break down. A mistreated game dev will do the same thing. Make a priority out of taking care of yourself, physically, mentally, and emotionally.

What this means will vary from person to person, but some things worth examining are:

  • Do you have a comfortable space to work on your game?
  • Are you taking routine breaks, especially for meals?
  • Are you leaving your work space during those breaks?
  • Are you reliably eating food that feels right to your body?
  • Are you drinking enough to stay hydrated?
  • Are you getting whatever level of physical activity feels right to you?
  • Are you reducing distractions during your work times?
  • Are you getting enough sleep?
  • Are you getting medical attention when you don’t feel well?
  • Are you taking any medications that you need?
  • Are you spending enough time out of your house and work environment?
  • Are you getting enough in-person human contact? (This could be time with friends, or it could be going to the library or a coffee shop – whatever is right for you and your situation.)

If you’re in a bad space – too tired, too hungry, too upset, too unable to work on a bus – you won’t be able to work effectively. Give yourself permission to stop working, and don’t start again until you’ve resolved the problem – whether that means taking a nap, getting a snack, having a good cry, or reading until the bus ride is over.

Treating yourself well won’t necessarily increase your motivation to work, but treating yourself poorly can decrease your motivation, and it will definitely decrease your productivity.

And besides, you’re a game dev! That’s amazing, and impressive, and difficult, and you deserve to be treated with kindness and respect.

Take care of your team. When it’s just you, you’re all you’ve got.

Bookmark the permalink.

5 Comments

  1. “Oh, wouldn’t it be awesome if -“

    It might! It really might. But keep in mind that everything you add will cost you some combination of time, energy, and money.

    Yes. But the energy part might be a positive. Sometimes – particularly late on in a project, where much of the work is unimaginative implementation of what has already been designed, or fixing of what’s unsatisfactory – it can recharge me immensely to spend a few hours working on an element that’s unnecessary but pretty cool.

    (That’s my excuse why Invisible Parties has such complicated code to respond to the player swearing, anyway.)

    • You’re right. It’s totally reasonable to invest a few hours of work into something fun as a personal reward. (Two weeks back, I expanded the scope of a game to include an unnecessary bar fight, for similar reasons.)

      Scope creep becomes a problem when someone either a) makes a habit of adding new features (so the goalposts are constantly moving), or b) commits to a new feature without considering the scope at all (which can be harmless, or can completely swamp the timetable).

      Either way, the important thing is to examine the cost and reward before committing to something new.

  2. I must add a personal situation/factor to be considered. I correct myself, it is a factor that a lot of people have mostly in my region (Latin America): we have another job, a job without relationship with the game dev process who help us to keep a income until we reach our dream. This consumes a vastly portion of the day, leaving almost 55% of the day to do the tasks you mentioned.
    Anyway the motivation tips that you listed are greatly helpfull and thank you to spend your time to write this text.

    • Your point is entirely valid! I’m from the United States, and most of the solo indie game devs I know have a day job as well.

      The techniques above are still helpful when you have limited time for development. (I used several of them when I was working full-time at Harmonix and writing interactive fiction in the evenings.)

      But it does mean that your expectations have to scale to the amount of time you have. For example, you might think of your goals on a weekly timescale rather than a daily timescale.

      I’m glad you found the post helpful!

  3. I can’t even get past the planning stage without expanding the scope of the project past my (very limited) capabilities. RIP.

Leave a Reply to Carolyn VanEseltine Cancel reply

Your email address will not be published. Required fields are marked *