It’s Dangerous to Go Alone!

Posted by Rampant Coyote on November 29, 2012

Now, as an excuse, with the Thanksgiving break over, I’ve been back to working 11-ish hour days for The Day Job, and so game development has slowed to a crawl again. Sadly, this has been the case most of this year. 2012’s been rough, but still not as bad as when I was working at Sensory Sweep. But for a couple of days I’d been plagued by a bug I just could not figure out. I’d spent maybe an hour each night for the last couple of nights working on the game, and pretty much banging my head against the same wall. When you only have an hour to work, you end up spending a chunk of that time remembering where you were, what you’d already tried, and so forth. After two days of this, I was getting pretty frustrated. Nobody else online seemed to have this problem – which suggested the problem was in my code, not in the libraries.

But HOW? The code was pretty dang simple, and I’d looked at the values many times in the debugger, and they looked fine (at least, I thought they did… because I’d focused on the wrong parts).

Fortunately, I still have somewhat of a partner-in-crime on Frayed Knights – Kevin, who mostly does level building but is also a programmer and often plays the role of devil’s advocate for me. Within five minutes of explaining the problem to him, I’d had the solution (which I wasn’t able to actually try and make sure it was the solution until much later that night). There are a lot of things that he and I disagree about – game engines, RPG design, etc. – but that’s actually beneficial a lot of times as he can help me see things in a different light. After a few minutes of chatting with him, I realized my problem.

It’s not that he’d offered any useful suggestions – he tried, but ultimately it came down to a bone-headed mistake on my part that seemed obvious once I knew what to look for.  When I explained, “It’s almost like it’s not taking the Z value into consideration at all!” it became clear where I needed to look in my own code to see if a value was getting dropped or overwritten. Sure enough, it was.

This happens a lot.

One of my discoveries when I graduated from college and started my career as a “real” programmer, working in an office and everything (making GAMES!) was the social element of software development. I’d always held the traditional view until that point of a programmer being someone who stays in his cubicle and bangs out code all day, coming out occasionally for meals, bathroom breaks, and talking about Star Trek.  In school, even on group projects I still kinda took that role.  We’d discussed what areas we were working on, maybe work out some kind of interface, and that was it for communication. As my skill level in programming was rarely less than my peers, I really didn’t see the value in having someone else “look at my code” to help me solve a problem. What could they possibly offer?

As it turns out – and pretty much every programmer who has worked on a team knows this – this is not usually the point of “asking for help”. 80% of the time, simply the process of explaining the problem to someone else reveals or at least leads to the solution. It helps if the someone else knows enough about what you are doing to ask some intelligent questions, but it’s not strictly necessary. Whatever the case is, breaking down the problem to a level where it can be communicated to someone else, and then the act of explaining it (and answering said intelligent questions) can often make puzzling bugs or problems obvious.

This isn’t limited to programming.  I’ve found the same applies to game design. Having a sounding board – especially one with skills of their own who can again ask intelligent, probing questions, and venture suggestions and opinions – can be invaluable. Even if you are doing all the heavy mental lifting yourself, the effort of packaging thoughts into a communicable form can be highly revealing.  It can also reveal where priorities should be. Sometimes what seemed a crucial problem will, after talking about it with someone else, show itself to be pretty trivial. And some things which you totally glossed over in your head turn out to be potential train wrecks once you discuss it.

Incidentally, this is perhaps the strongest argument for putting together some kind of design document – a “paper prototype” – in advance, too. I’m not an advocate of big, exhaustive design docs – quite to the contrary. But writing crap down to keep track of it is always a good idea, and going through the process of explaining your core gameplay to even an imaginary audience can help reveal problems in advance.

Even on the art front, having another pair of eyes looking things over at various stages can also help identify problems before they become costly to fix.

So what’s my point? A lot of indies either lone-wolf it, or work alone with geographical separation from other team members. While chat, Twitter, and forums can be massive time-sinks if you aren’t careful, they can also be extremely valuable tools if you have a network of friends and team-members off whom you can bounce problems and ideas.  It needs to work both ways – you need to be a good listener to help them, too, when they need the ear. But it’s important to take time out to socialize. Otherwise, although it sounds counter-intuitive, your productivity could falter as you waste too much time trying to work out your problems alone.

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



top