How not to get stuck

Throughout the lifetime of a project, there inevitably comes a point where what you’re doing is no longer intrinsically fun. The easy/fun parts have been finished and now you’re working on the nitty gritty. Such as working out the bugs in a pathfinding algorithm, writing networking code, or even simply researching how do accomplish the next task you’ve got on the drawing board. At this point its very easy to get distracted especially with new games coming out all the time combined with having non developer friends wanting you to join in. So how can you overcome these temptations ? How can you continue to work towards your goal of finishing? The truth is that nobody knows the answer to that question, its something you have to discover for yourself. However what has worked for others has also worked for me.

Here are a couple of tricks and pitfalls that have I found  in my productivity. Hopefully they will help you.

Pitfall: Falling Down the Rabbit Hole

This one is a big struggle for me. Often times when I see a problem I’m tempted as an engineer to solve to problem in “the best way possible”.  This post about how engineers and project managers prioritize work was a real eye opener for me. The TL;DR on the article is that engineers look for the “best” solution, while project managers look for “good enough”. The article goes into great detail why both parties are completely justified in their priorities based on the way in which each of them is punished and rewarded.

Bringing this back to gamedev. What this means is that I as an engineer have a tendency to over-engineer and over-prefect areas of the project that don’t necessarily  need it. But on an indie project, I am also the project manager and fail to look for solutions that are “good enough”. The result being spending hours upon hours perfecting and optimizing a single part of the code leaving the rest to suffer.

While on the face of it this may not seem so bad. Because after all when you’re done you’ll have something perfect and you’ll never have to work on it again right? Wrong. Since you don’t know what the final implementation of the game will be, there is a very, very, strong chance that you’ll have to update this code later on to make it compatible with your new features. Not only does this prevent you from doing any real work it also saps your energy, motivation, and the visual progress of your game.

The Solution: Attempt to build what is called a vertical slice of your project. This translates into getting a simplified or rudimentary solution for each piece of your project. While there are some downsides to using a vertical slice, the advantages you get are enormous. By having a vertical slice in place, it allows you to see the full implementation of your game more clearly and allows you to make informed decisions about what parts should be generalized and optimized, and what parts are ok with being “ugly”. Additionally, having a full vertical slice gives your project a sense of visual progress which you can use to convince others to join your project and to convince yourself that you’re making progress allowing you and everyone on the project to keep their morale high.

Pitfall: Premature Optimization

One of my idols, Johnathan Blow (creator of Braid), opened my eyes to one of the pits that I had been falling into for years, that of premature optimization. From his presentation (which you can view here at his blog) he talks about the ways in which premature optimization can hurt a project. In a lot of ways its similar to the rabbit hole problem mentioned above except on a smaller scale. While you can usually guess which parts of your code are going to run faster or slower than others, its difficult to tell how much  difference a particular optimization will have on the final implementation.  Additionally, optimizations usually rely on a set of assumptions which, while valid at the time of writing the optimization, may later turn out to be false. These subtle assumptions then later cause very strange/irrational bugs which can steal days worth of your time away from you. Your time is a precious resource and you need to treat it as such.

The Solution: Today’s computers are reasonably fast enough and compilers are reasonably smart enough that you can safely ignore most optimizations until the end of the project. Its perfectly valid to do little optimizations (like writing a real findMax function to find the maximum value in an array instead of using Sort/Reverse ) but optimizations that rely on implicit assumptions should be avoided until the final implementation is clear. Additionally, waiting until the end of your project gives you the added benefit of spending your optimization efforts where it counts the most, and leaving the less important optimizations to be fixed as time allows.

Pitfall: Boredom

In every project there are sets of tasks that are fun or boring and we have a tendency as human beings to want to work on the fun parts while ignoring the boring parts. Assuming that 50% of the project is fun and 50% of the project is boring (a very generous assumption), you wind up very quickly with a distribution of tasks in which the majority of the ones left to do are boring. Unfortunately there is not a lot you can do to avoid this pitfall but there are a few tips you can use to stave off boredom and prevent it from reaching levels high enough to make you quit the project.

When you start to stagnate, switch tasks

This is a bit counter-initiative to us engineering types whose instinct is to double down and focus on a problem until its solved since breaking your concentration on it will cost you effort getting yourself back up to speed later on. This approach would be fine provided you only had that one task to preform, but its important to remember that the real enemy here is fatigue and boredom. Switching tasks and getting some victories in other places will refresh your confidence and motivation and while finally solving the difficult problem may do the same, its usually too little too late.

Take breaks and reward yourself with success

Just finish a major feature or fix a major bug? Reward yourself by doing something different for a little while. Play a mindless game, go out with friends for the evening, browse Reddit, or cook yourself a nice dinner (as opposed to yet another microwaved pizza that you’ve been eating the past two weeks). Even little things like going for a walk or taking a shower will do wonders for your morale and mental state and sometimes may even open your eyes to the solution that had been staring you in the face the whole time.

Balance the fun with the boring

While most projects are going to have far more boring parts than fun parts, be sure to ration your fun parts sparingly to allow yourself some “easy” or “relaxing” work to reward yourself with after slogging through the boring parts. It may help to finish of the day or week with a fun part so the proverbial “taste in your mouth” is that of a good one. When I was a kid I’d often employ this strategy by eating all of the things I didn’t like first, and saving the good stuff for last since that’s the taste that will linger afterwards. Similarly by ending on fun tasks you can help reenforce your last experience working on the project as enjoyable, making you more likely to do it again.

Remove distractions

While this might seem like a no brain-er in practice its incredibly hard to do. Today we are constantly surrounded by easy access to entertainment through our computers and through our phones. The internet itself can be a large source of distraction, especially sites like Reddit which feature nearly endless streams of content for your viewing displeasure. It seems like an ideal solution to simply unplug and let those distractions fade away, but the reality is that as a developer you need access to the internet to look at reference manuals, ask questions, and look up known solutions to problems you encounter. Your game itself may require internet access in order to function correctly. So what can you do? Well, what I’ve done is create a new user account on my PC called ‘dev’ in which I do all of my development work. He is a full administrator, has all the permissions as my other account and there is in essence nothing stopping this account from procrastinating like my main account. But it turns out that little things, like not having your bookmarks, not being logged into Reddit or email, having no game shortcuts on your desktop, having all your gamedev files on in this user so you “have” to be there in order to do development, does wonders for my productivity. Any time I’m tempted to look at Reddit, I’m reminded that I shouldn’t be by virtue of it not showing up in my address bar when I type “re”. I’m reminded that I shouldn’t be playing games when I have to hunt for the shortcut button to open it up etc, etc. And at that point I have to make a conscious decision to stop development and switch to my main account. It doesn’t always stop me from procrastinating, but in my experience it helps more than it could possibly hurt.

That’s it for my list of pitfalls and tips for now. Perhaps more to come in a part two. Thanks for reading 🙂