Tangible goals are key to any project. Without them I feel like I’m peddling up a steep hill just so I can peddle up some more. Scheduling and time logs showing time spent are great for statistical and historical purposes, but in the scheme of things can do little to save a project if you and your team lack that motivation needed to push the last mile. Countless indie games die from loss of interest. I’ve had several of my own projects fall by the wayside as other opportunities popped up that seemed more “fun”. As they say, the grass is greener on the other side :). But I would argue the overall motivation for those failed projects didn’t dropped per-say. It was just that a particular type of motivation wasn’t effective at getting that project done, and that the person failed to cultivate the right type of motivation to see it through…

Short Term Vs. Long Term Goals

When it comes to goal setting I tend to write my short-term, concrete goals down in some form. That list takes the form of a weekly schedule and to-do list. The longer term goals, such as “Finish game X” or even loftier ones such as “become a full-time independent developer” or even “Travel…somewhere…anywhere” kind of stay in my head constantly nagging away at me :). I find that when I’m not working directly on my game for a period of time the long term goals rear their head and eventually guide me back on course. But interestingly enough, the second I sit down in front of the computer to work my long term goals go out the window and short term goals kick in. This has had some pretty compelling implications on my work habits.

Some weeks I tend to faff about a good bit on YouTube, TED, RSS, IM, and other things throughout the work session. This happens even when I’m fully aware of the devil that is the internet. Now what happened between the time I was driving home from errands all hyped up about getting my game done and sitting down in front of my computer to make that dream a reality? I feel like my long term goals aren’t pushing me along anymore once I’m in a position to do actual work. What I’m finding is that I’m constantly looking at my to-do list and reminding myself how great it’ll be to finally have a a a good GUI system implemented this week to make the game hopefully look a little more…professional? I’m looking forward that following weekend to have a new build to push out to beta testers. I’m not looking forward to finishing game X on any given week, but finishing feature Y or bug Z. The important distinction here is that those short term goals have tangible results that are more easy to visualize while working.

Yes, I’m saying I have no idea how Tilt To Live will end up, I can only guess at that. I have a clearer image of how feature Y should work though. Maybe I should chalk this up to inexperience? It just seems so weird to me that there’s some sort of internal switch in my motivation based on the context of where I am at or doing at the moment that decides whether short term or long term goals will be the most effective. Realizing this will help push me more to create better weekly schedules so that my short-term goals are more tangible.

This seems obvious when you think about it, but I started thinking about how this applies to other things in life when I came across The Buried Life while listening to an Adam Corolla Podcast (doing laundry at the same time so not completely faffing about!). How many goals do people never see become a reality because they experienced my errand-to-computer dilemma? They got all hyped up about an idea, but when they were on that edge of opportunity they backed away not because they didn’t want to do it, but because they simply didn’t have any short term goals to push them over that edge? I’ll leave at that for now as it’s a bit heavier topic that I simply don’t have the time or qualifications to fully analyze at the moment. Back to my indie task at hand…

Gravity Well

Work in Progress Screenshot of "Tilt To Live"

As I’m approaching the final legs of production (and starting to get my shit together for promotion and marketing) tangible goals are harder to find and smaller. In the beginning, having a playable mock up was a huge step forward that could be completed in a single week. Nowadays it’s about getting X animation doing Y exactly correct so it’s timed with the audio to give the best feedback for the user. The amount of effort for both tasks is about the same, but the return on investment for me as a programmer is much smaller when doing these polishing tasks. But I know polish on a good game is what pushes it past “ok” to “good” and gets people talking about it.

In a large project, such as indie game, having long term goals are essential to getting you and/or your team to jump on the project. Without those short-term goals feeding your long term motivation, your motivation eventually starves and the project slowly dies.

This week’s partial tangible goal list:


By Saturday that list will hopefully be empty, but it’s not the empty list I’m excited to see, but the fact that I’ll have a first pass of a tutorial system in the game by the end of the week :). Looking at this list I can tell my “scheduling skills” were a bit lacking and I know most if not all of the priority #2 cases will be moved to the following week because this week’s goal is to implement and polish a tutorial system. Hopefully, this won’t translate to another hour long fall through the rabbit hole they call the internet :|.

Oh, and in case anyone is wondering what task management system I’m using, it is called FogBugz. It’s been a treat to be able to use such a robust system, even if I’m a single developer.

Some days it takes a herculean effort to force myself to sit down and work on my game. Some weeks it can be destructive to my entire schedule, while others its a complete non-issue. Overtime I’ve found prioritizing my tasks wasn’t enough to really Get Things Done. I needed a way to organize my daily tasks in such a way that would maximize my motivation to actually work that day, particularly after coming home from my day job. By taking my top priority items and then sorting them from easiest/most fun to hardest/most boring I think has helped my overall productivity.

I’ve resisted the temptation to try to squeeze in and finish off any low hanging fruit when I’m finishing up for the day and leaving it for the next session. Why? It increases the chances that I start on time the next day and get ‘into the zone’ faster for when I need to really concentrate on the harder bugs and features later into the day. It’s much easier for me to come back to an easy fix or feature. Whenever I have a really hard bug I tend to dread working on it before I’ve even sat down at the computer. Sometimes this can’t be avoided as some bugs can take days of work to finally be fixed, especially if you’re on a very limited time schedule with a day job and other obligations. I haven’t met many people who look forward to debugging some crazy hard bug when they start their day’s work. Once over the ‘hump’ when you’ve settled into just doing the easy things you can quickly ramp up and tackle the hard problems on your to-do with little fuss.

But when the day (or in my case, the night) is winding down, I try to save away some of those easy or fun 5 minute tasks for the next day to really help motivate me into starting on time. As for other tips on game development project motivation and such, instead of going into other aspects of it I’ll just link you guys to a post by Jake Birkett, of Grey Alien Games, that sums it up very nicely for indies looking to get ‘serious’ about their game development business. In particular, this bit:

I’ve run out of motivation

Well perhaps game programming isn’t for you but some other aspect of game production is? But maybe you just need to re-motivate yourself! There’s plenty of stuff about this all over the Internet. Try doing something that inspired you to make games in the first place – perhaps you need to play some of your favourite games, or boot up an emulator and play some old classics, or read some stories about other people’s success, or make a little fun minigame, or listen to some Commodore 64 tunes or Euphoric Trance music. Whatever gets you back into that space where you really want to have fun making and selling a game! Be sure to REPEAT this process whenever you feel your motivation dip.

Having a plan really helps out as you can chart your progress and see clearly what you need to do next. Also if you feel unmotivated, just START something, anything on your project and 5-10 minutes later you’ll probably be really into it.

That last bit is very important and speaks to the issues I encounter most often. For me, that ‘something’ is usually a 5-15 minute fun/easy high priority task that needs to get done. Planning this ahead of time helps as staring at a list of tasks and ‘cherry-picking’ when I’m in a state of lousy motivation usually ends up with me picking things that don’t need to get done right away and leaving more important tasks to linger on the list. Game development isn’t all fun, but with a little forethought and planning you can really help minimize the mundane feeling parts of software development.

I’ve been using Subversion even as a single developer for several years now. It’s invaluable to me and millions of other developers. If you’re a developer working on any project that lasts more than a couple hours and you aren’t using version control then you are shooting yourself in the foot. As a developer, we’re comfortable with juggling several things in our heads at the same time, it’s a fundamental skill we use everyday when developing software. But when you start to do ‘internal’ version control in your head while developing you are only slowing yourself down and it will ultimately lead to lesser quality code.

Don’t think you’ll need this chunk of code, but you’re not absolutely sure? Did you just rewrite method X but you want to keep the previous iteration around as a reference? And more relevant to me: Are you making a bug fix but are mentally keeping in mind how to revert that fix in case it doesn’t work?

All of those questions are red flags that you aren’t using your version control system (if any) to a meaningful capacity. That last question came up earlier this week when I was wrapping up the first alpha build to start testing with a small group of testers for my iPhone game, Tilt To Live. I wanted to implement a new collision algorithm in the game so the higher difficulty levels would run much more smoothly. Wanting to get this right ‘the first time’ (hahah ya right, another lesson learned) I first mocked the algorithm up in Blitzmax, optimized there and debugged it there. Of course, any debugging done in a different language for a mock up is fixing purely conceptual bugs rather than implementation bugs.

The Wednesday night deadline was quickly approaching and I just finished implementing the new algorithm. I start play testing for 5 minutes. 10 minutes. 15 minutes. 20 minutes, wow the game is performing really well! 25 minutes, CRASH! WHAT?! How can this be?

So I quickly restart the game to see if I can figure out any clues as to why it is happening. 5 minutes in I crash again, but it’s still seemingly random. And the debugger isn’t spitting out any useful information to help pinpoint the bug. Knowing the only code I had introduced was replacing a call to the new algorithm I knew just replacing a single line of code would revert me back to the ‘previous version’ (this should have been red flag #1). I start debugging for hours to try to find the cause of the ‘BAD_ACCESS’ fault that is most likely coming from a null pointer somewhere in the new collision algorithm, that seems to still happen ‘randomly’.

Anyway, hours pass and then the next day I spend a few more hours on it to try to see if I can fix it before I start trying to compile an alpha build. Failure. I simply just need more time to get this fixed without releasing the alpha build with a critical bug (red flag #2).

In the end, I had to revert to the slower n-squared collision algorithm for the alpha build. Using SVN, it was trivial to revert back to the previous version, quickly test it, build, and release. Yet, there is a much better process to avoid this very time-sensitive issue of getting bug fixes into a build without compromising the stability of the build. It’s called branches.

Now, I’m no stranger to branches, as I use them to catalog releases, but to incorporate them into my daily development routine is new and is something I’m going to try to implement to avoid this issue in the future. Jeff Atwood, co-creator of StackOverflow.com,  has a rather good summary of different branching patterns for on-going development. As a single developer I’m going to try to adopt the ‘trunk is sacred’ (Branch per Task) method and try to merge features into it from development branches.

What’s the benefit? Always being able to release something that is relatively stable regardless if you’re in the middle of something or not. And you don’t have to worry about ‘auxiliary’ changes you made leading up the current fix that may also break the build. I’m finding that as I draw closer to a more complete game, I need to be able to release builds on a weekly or bi-weekly basis for testers to play test. Knowing that there is some glaring bug that is a showstopper is a head ache for you and your testers.

I’ve been researching different version control systems outside of SVN to see if there’s something that could make branching and merging more seamless and integrated into my work-flow. I’ve found that distributed control systems such as git, and Bazaar, supposedly make this fast and easy. Although,  I’m not ready to give up subversion yet; mainly because it is working. But I may test those systems out in the future for smaller projects. TortoiseSVN’s merging dialog can be a little more clearer, as it stands now it is rather confusing the first time you use it. I’m currently testing out Versions (Mac Only) since I’m developing mostly on the Mac for the iPhone game, and it seems to be a little more intuitive in branching, but can’t comment on merging yet as I’ve yet to look into it.

And now I’m off to enjoy the rest of my weekend :).

Update: Looks like Versions won’t suit my needs. Neither will Cornerstone. SyncroSVN Client seems to support basic things like switching, merging, and branching while the other more ‘fancy’ looking apps don’t do anything beyond committing/updating/branching. Except that SyncroSVN’s GUI isn’t any easier than the command line for merging/switching. Looks like I’m going to the command line or revert to using Tortoise SVN (on windows) for the time being while these Mac apps sort themselves out and mature a bit…