Babagazeus Gaming

Keeping Yourself Motivated

February 29, 2016 by Andrew

This blog post describes my strategy for keeping motivated and organized.

As a warning: I think motivational strategies need to be tailored for each individual. There is no universal method for keeping motivation high, because we all have different triggers and goals. So let me give a brief description of my specific hurdles when it comes to staying motivated.

Getting Rolling - I find it harder to start a task than to finish it. Once I am seeing in the middle of something (and seeing progress), I usually can finish it.
Intermediate Results - I need to see results to stay on task. If I get lost developing an intricate inventory system that will take days before it even compiles fully, I risk getting bored.
What Next? - It is not always clear to me what the next step should be. Is the inventory UI a higher priority than a better damage calculation formula?
End Game - Often, I get discouraged and wonder what is the point of all the hours and energy I pour into my projects. Is this wasted time, or would I otherwise just be clearing out belly button lint?

If you see yourself in the above list, I hope some of the tactics I discuss can help you.

Getting Rolling

First things first! Before we can worry about motivation, we need something to do. For me, there are two (over-simplified) groups of tasks: starting a new project, and continuing an existing project. I use a different mindset for each of them.

Starting a New Project

When starting a new project, I consider two main questions. The answers to these questions determine things like the scope, technologies, and polish of the project.

Who is my audience?
How long do I want to work on this project?

Audience

There are a few discrete categories I use here to drive the answer. Each answer generally expands upon, and includes the earlier ones.

Myself
It is fine to say you are the target audience of your project. There are many types of projects that fit this category.

Educational: these projects can give you experience using a new technology, or a new design pattern. The value of these projects seems very low to a beginning. However, their huge value lies in two key factors:

Experience is the best teacher, and gaining experience in the middle of a huge project tends to take even more time and resources!

Example: if you want to learn how to use pygame, don't start building the next AAA MMO. Try to make a clone of a simple game like Pong. You will learn important concepts like how the code is best structured in that engine; what the engine does well; what it does poorly; and - maybe most importantly - do you like using it?

Proof of Concept: these projects show that you can implement a specific idea. You don't want to be half-way done with the next great MMO and find out that your central mechanism is not possible. Implement your idea in as small a project as possible. Then ask yourself: is this feasible? Is it what I expected?
Friends
Lots of projects are great when shared with your immediate friends. When you are sharing a game with your friends you can take advantage of some key benefits:
- You know what your friends like. A game is usually only a success if the audience has fun.
- You know what your friends will understand immediately. This means you don't need complex instructions, or to spend time develop tutorial levels.
- You need less polish. We aren't creating something that has to attract people based on amazing visuals or inspiring plot. This is for our friends, and they will play it because they like us (we hope).
Example: creating a simple game for a friend's birthday party. Maybe it guides the participants on a scavenger hunt; or maybe it's a silly take on Pong that highlights inside jokes to be especially fun for your friends.

These games still yield great experience, and they also give the return of entertaining your friends. But beware! They often require much more effort than a personal project. Everyone's time is valuable, and your friends will likely tired quickly of serving as a QA team for a project that is not fun and breaks often.
The World
Even as a hobby game developer, one dreams about strangers they will never meet playing our game. Maybe just to spread joy, and maybe to put food on our table, this is a very common goal.

In my opinion, even the india/hobby game scene is very competitive. Large companies regularly use vehicles (e.g. crowdfunding) that were designed to help the "little guy". In many ways, this is very good. The quality, variety, and content of indie games today is exceptional - and very diverse!

However, the other edge of this sword, makes it very unlikely that an individual hobbyist will enjoy massive success for their project. So if we want to still have a rewarding experience when selecting the world as our audience, we need to set realistic expectations.

To give ourselves that tiny chance for success when we want the world to be our audience, we need to execute at a very high level. That often means a very high cost (be it in time, effort, or money). I would say this is a very personal question. If you feel that the only way you will be inspired is to dream of enchanting a world of gamers with your game, go for it. But try to maintain a kernel of reality: the odds are against you.

If you can get inspired with lower expectations, that is often a good strategy. If 1000 people download your game and enjoy it, would you feel fulfilled? That is a lot of people to entertain - and likely well above average. When I select the world for my audience, I almost always plan on being satisfied with a handful of people appreciating the result.

Project Duration

In my experience as a professional software developer, I find that determining the amount of time a project will take is very difficult. With that in mind, it is still important to try to set realistic timelines for every project. The most important part of those timelines are regular checkpoints where the viability of the project is evaluated.

If I am starting a small hobby game, I usually give myself two months to work on it casually. At the end of that initial development period, I take a week or two to determine the future of the project. Is this something that I enjoyed working on? Do I think this project will achieve my initial expectations? Those are the types of questions I use to evaluate how the project's timeline should evolve.

Often times, I feel satisfied with where the project went during its time, and I end work on it. I do not consider those projects failures. I learned from them, and I enjoyed doing my hobby.

If I feel the project has more legs, I loosely scope an additional amount of work (aiming for 4-6 weeks of effort at whatever pace I can manage) and schedule another evaluation checkpoint.

This prevents me from getting bogged down in a project that I get frustrated with, or otherwise stop enjoying. It also helps keep me motivated because I am always refreshing my expectations and keeping them realistic. I am not set up for a big disappointment when I fail to reach expectations that I set when the project was in its infancy.

Intermediate Results

Almost all projects start by staring at a blank editor. From the first minute, we can see our beautiful completed game in our head. It can be discouraging when - after lots of effort - we still do not see that final vision realized.

Where do I start?

There is no silver bullet for simply completing the dream game faster. That usually takes lots of hard work. However, the hard work can be less painful when it is mixed with intermediate results. When I give myself frequent glimpses of the final destination, it helps me stay motivated.

I have found the best way to get intermediate results, is to spend time upfront ensuring that your tasks are discrete chunks of the larger project. This is easier to illustrate by an example:

Objective: Combat System

Bad First Task: I need to implement the inheritance heirarchy of all of the enemy and player characters. I need to determine the base class and put the movement logic in there. The player class needs to handle equipped items, and the enemy class needs to drop items.

Why is this bad? This scope is too large. This task touches reaches into many other areas of the game: movement/physics, inventory, loot, and combat. Also, the task is not designed for intermediate results. Once it is complete, all we have is some code.

Good First Task: I need to make an emey and a player character appear on-screen. When I push a button, I need the player to attack.

Why is this good? The task has a very tight scope. It does not dictate design decisions outside of combat. Once it is complete, we can play our little game right away! It may seem like nothing, but that kind of feedback can be critical to motiviation.

Design each task with the goal of being able to see it in action after only a few hours (or most a day or two) of effort. This gives critical intermediate results, but also feedback on the overall direction. This strategy also makes it easier to change course when necessary. Many projects sink after spending days implementing a feature that ends up not working out. Either one loses motivation from throwing away so much work, or the project is forever hamstrung by keeping an bad feature.

What Next?

I am capricious person, so I keep a very short-sighted view of what to tackle next. Each day I am going to do game development, I start by creating a short list I want to accomplish for that day only.

I keep that list short because it is just for a day/session of development. I also keep each item on the list concise in scope (so it can yield intermediate results!). I have tried a few complicated task management tools for this. Everything from complicated workflow tracking software like JIRA to handwritten notes.

The best I have found so far for me is Google Keep. It offers more functionality than a hand-written note, but it so simple that managing it does not incur any overhead.

Checking off completed tasks gives a strong sense of accomplishment. This is true even with small tasks. That personal reward is critical to motivation.

Prune Rotten Tasks

A common source of discouragement are rotten tasks. When a task gets constantly pushed back, it can seem like something that you are failing on.

When I that day/session is done, I always discard the list I made. If there is an especially important task, I will copy it to a the next list. And if I notice a task is getting copied multiple times, I do one of two things:

Drop it! If I am dodging a task, even for bad reasons (e.g. laziness), I do not want to let it jeopardize my project. I would rather finish a project that has a bug, or missing feature than not finish at all. If the task is really that important, I will notice it again later. Maybe I will have better luck tackling it down the road.
Cowboy Up! Sometimes I can psych myself into tackling a dreaded task. As humans, discpline is a finite resource for us. Sometimes we have excess, and sometimes we are running low. If I am particularly rested, maybe I can grit my teeth and tackle this daunting task. I do not sugarcoat it. In my mind, I make the conscious choice to buckle down and suffer a bit for the greater good.

End Game

This is where it is the most important to know yourself. It is inevitable that some projects will encounter huge setbacks, and some will completel fail. I will explain how I handle those situations. What works for you may be totally different.

When the scary question "Am I wasting my time?" pops up, I realize that my project has hit a (or, one of many) crossroads. In those situations, I spend a moment to find out what is making me ask that question. The best solution for me depends on that answer. So, what is getting me down?

I will never finish!

Because one almost has to be a big dreamer to become a hobby game developer in the first place, this is a common conundrum. And, unlike werewolves, there is no silver bullet solution. Here are the strategies I use:

Hack 'n' Slash - Features take time. Less features take less time. I would love to make the next gen MMO by myself, but that is not humanly possible. Spend an hour thinking about what parts of your project are pie in the sky, and what parts are the fundamental game loop. Cut out the fluff until you find a small core that is possible for you (or your team).
Pivot - Did you plan on making an awesome game for your friend's upcoming celebration but ran out of time before the event? Change your audience! Take the project in a direction where you can learn something that will enhance your development toolbox and contribute to your next project. Or change all the text and make it for a different celebration. Don't worry about completely changing the goals that you made at the beginning. Life is going to change, so your project will too. When it happens, it is not a waste but part of the process!
Sink the Sunk Cost - Not every idea we have is a winner. Halting a project before completion is not a failure, and is often the smartest option. The work is never completely wasted; with each line of code we write, or asset we create, we gain experience. And the experience of ending project at the right time (which is not always when it is completed) is extremely valuable.

Summary

In short set yourself up to stay motivated by:

Targetting the best audience for your project.
Develop in small, playable iterations.
Keep a low maintenance task list.
Stay maleable and know when to fold'em.

I hope these thoughts have been helpful. It took me quite a few years to adopt them, but I believe they have been very useful.

Babagazeus Dev Blog