Lone-Wolf Game Developer, or Just a Straggler? Ten Tips for Solo Indie Game Devs

Posted by Rampant Coyote on May 10, 2013

One peril of being a lone-wolf developer (and a part-time one at that) at that is that it can be really tough getting motivated to keep plowing through stuff – particularly the un-sexy parts – on your own, particularly when working on a (relatively) really big game. That’s probably why most successful small indies focus on tiny games that they can complete and polish within six months. It’s tough to keep your eye on the ball for months and months and months. And as something of a lone wolf, there’s little accountability – positive or negative.

It can wear ya down. Sure, slacking off one night isn’t going to hurt things too badly.  Two nights? Nah. But when the one or two nights stretch into a week? Or a month? Particularly when paying the bills is not dependent upon your game sales, it’s easy for things to get sloppy, and go from sloppy to dead.

This is how many indie projects end up dying. The fun part mostly over, the work-part begins, and the project is never really canceled. It’s just that those working on it (especially if it’s just one person) just slow work down gradually, focusing efforts on new, more fun “side-projects”, or getting sucked into a new game (guilty!), etc. Before you know it, a month has gone by without any real work being done, and by then it’s really hard to get back into the swing of things. There’s no intention involved, it just… dies of gradual neglect and entropy.

There are three big advantages, in my mind,  to having a team working on a game. The obvious reason is that you are able to specialize in skills and complement strengths. A less obvious reason is that it gives you people you can bounce ideas off of.  It’s easy to get stuck in your own little world or thought-loop, and having someone else around that can give you a fresh perspective. Or – and this happens to programmers all the time – it’s just good to have somebody to explain a problem to, because four times out of five the process of explaining the problem to someone else is all you need see the source of the issue.

The third reason a team is so valuable is because – in the right kind of team – you can motivate and push each other. You can have accountability, dependencies, and – this is surprisingly important even for most self-motivated, self-starting people – the appropriate moral support and “attaboys” from peers as you complete tasks. People who can appreciate the fact that you just spent three days converting a working prototype to actual functional, maintainable code.

A lot of indie teams work remotely, which limits some of these advantages.You might be on a team, but be on your own most of the time. In many cases (like mine), you might be the primary person working on a title, but might have a few people pitching in or working under contract. While you aren’t the sole developer on the game by any stretch, but you are still carrying a lot of the load in solitude, with no one to answer to on a day-by-day basis.

(I should note there are downsides to a team, as well, and a lot of devs really thrive operating largely on their own. But I’m focusing on how solo or “semi-solo” indies can obtain some of the advantages of working on a team, or at least limit the downside of being on their own).

For me – it seems like I need to re-solve this problem with every project.  Sometimes I’m awesome at being motivated and pushing myself to get tasks done. Sometimes – especially in the boring mid-development stages – I struggle, too. That’s probably why I have to keep re-solving it: Shifting from the breakneck pace of final testing back to design and early development is a huge change of pace and rhythm, and it’s easy to forget how you made it work the last time.

Here are some ideas, largely taken from tricks that have kinda worked for me in the past. They can certainly be improved upon or adapted by other developers:

1. Keep it small.
   It’s a lot easier to keep your eye on the goal when the excitement for nearing release kicks in just as the excitement of working on a new project starts to fade. (And no, I may never actually follow this advice myself, because I’m stupid.)
2. Group boring and fun tasks together.
   I broke up my task list into collections of tasks (usually 3) that had to all be completed before moving on to another collection. One of the tasks was a “fun” task. That was my reward for getting the other jobs done.
3. Have a “dev buddy.”
   As in “the buddy system.” Find another indie in a similar situation (there are literally thousands of us now, it’s easy), or maybe a network of buddies, willing to act as sounding board and moral support for you. In exchange for you doing the same for them and taking an interest in their project(s).
4. Weekly ‘team’ updates. Even without a real team.
   Send weekly updates out to a “team” – even if the team is only friends, dev-buddies, testers, or people only peripherally involved in development – on progress. While this doesn’t prevent a night of slacking off (and really – we all need a night of slacking off now and then), it DOES hold accountability for everyone involved. The updates should include both goals for the following week, and how you did on achieving the goals from last week. (This makes it important to set reasonable goals — if you get into the habit of only hitting half your targets, you’ll get used to it and admitting falling short will get easy).
5. Set serious internal milestones… with bonuses!
   Any other means of actually *setting* internal milestones and having them mean something. While it’s possible to do this completely on your own, it’s often better to have somebody else involved – even if they aren’t otherwise involved in the game. Buy a new game or fun bit of hardware for yourself, but don’t take it out of the shrinkwrap… instead hand it to your spouse, sibling, or friend and say, “don’t give this back to me until I complete this milestone, which I plan to complete on this date.”  This not only puts in a reward structure for hitting milestones, but it forces you to be accountable to someone else.
6. Blog Reports.
   Write weekly, bi-weekly, or monthly reports on development on a blog. Granted, these can be really, really hard (especially when you are down in nuts and bolts that isn’t of much interest to anyone), but it’s one more layer of making sure things keep moving so you’ll have something to talk about. It doesn’t matter if nobody ever reads ’em – you are putting yourself out there as a matter of historical record.
7. Show your work-in-progress to the public.
   Participate in Screenshot Saturday,  local indie meet-ups where you show your game, or other kinds of shows /presentations where you can publicly demo your game. Anything to force you to show progress to someone else. Knowing that you have to have something new to show in a few days can help drive development.  There was (and still is, as far as I know) a long-standing joke in the tech business that, “If it weren’t for trade shows, we’d never get anything done.” True, they can cause some horrendous wasted effort as well as you make stuff with the intent of throwing it away once the demo is over.
8. “Live,” in-person demos with the “team.”
   Likewise, live meet-ups with whatever might constitute your “team” in any form is a good thing. Not only is it a motivating factor to get things ready to demo, but you’ll be with people who have a higher level of interest in the game and able to provide some quality feedback. And like talking about a programming problem with another problem, it’s funny how you can see problems when showing the game live to a group that you overlooked a hundred times on your own.
9. Test early, test regularly, but get testers!
   Start testing as early as possible. Early testing can be with other devs or experienced testers who understand what a work-in-progress really means. Start getting that feedback loop – and dependency on getting regular, steady builds out the door – going as soon as possible.
10. Work towards a true release goal.
    And lastly – here’s a big secret: All those companies that brashly give a street date of, “When it’s done?” That’s only what they tell the public, because of the number of things that have to be coordinated for release. Internally? You bet they’ve got a release date. They may totally blow it, but they’ve got a plan. If you have a release goal and you earnestly strive to achieve it, but fail miserably, you’ll still be far, far further along and better off than if you didn’t have a goal.

I need to remind myself of these tricks from time to time. It’s easy to get sloppy when you are going at it alone as an indie game dev, and the bigger the project, the harder it is to keep things together. Hopefully these ideas will help.

Now, you may notice that most of these tips involve other people. That’s the way it is. If you truly wish to live in a cave by yourself, you may need to come up with better ideas. But indies usually make games for other people. For me, even being a “lone wolf” doesn’t mean being a hermit. If anything, it probably requires you to get out of your space (physically or digitally) and interact more with other people. So get to it!

Filed Under: Game Development - Comments: 10 Comments to Read



top