It’s blog post number 100, so time to catch my breath. Crazy string of weeks there from April through mid-May, trying to make deadlines, having those deadlines pushed back, trying to make the deadlines again, and so forth. Some successes, some failures, but you can’t argue with the fact that deadlines are great for getting shit done, even if you don’t get it all done.
It’s a little weird because my day job is filled with deadlines. Basically, it’s like a slow march from one deadline to the next, and every so often I get caught up in it and spend massive amounts of time working like crazy to finish under the wire. But that’s work. This was a deadline for a hobby. None of the panic, despair, and regret to deal with. It was a very different experience.
One of those deadlines was for the last Utah Indie Night, back at the end of April. I missed the last couple, so it was nice to be back, and to have another rare opportunity to present Vespers in public — even if we didn’t get everything for the full demo done. TRC had some nice things to say, which I appreciated, even if the game isn’t very playable yet. Now that Aaron Reed has finished Blue Lacuna, it’s now down to me and Jay to see who finishes last. Sorry, Jay, that flying car is all mine, so better start saving up now.
On a related note, at the start of the Utah Indie Night there was a short presentation by Darius Ouderkirk on how to choose an indie game project, with the key being a project that you can finish and release. As Jay blogged, it was simple but hit a lot of very good points — even if, as pointed out to me later, he hasn’t shipped a game himself yet (d’oh!). It was filled with good advice; a collection of fairly common sense approaches that have been mentioned in one context or another in various places around the ‘tubes, but assembled and presented in a nice way.
But as I think about it now, there was one thing he forgot to mention.
With most projects, especially those you put a lot of yourself into over an extended period of time, there are peaks and valleys. And sometimes, those valleys can really suck. Sometimes, as Jay mentioned in another of his blogs, it has a lot to do with motivation. All games have fun parts and tedious parts, and those tedious parts can start to feel like chores after a while. Designing and implementing dialog boxes. Placing endless numbers of decorative objects, like walls or leaves. Modifying terrain. It can get pretty dull, but there are ways to fight through it, mixing the dull parts in with the fun parts. The target is always in front of you, so you just plug away until you get there.
But then there’s the other type of valley: the periods of self-doubt that grow insidiously the longer you work on a project. Often you end up spending so much time working with all of the pieces at the microscopic level that you go long periods without taking a step back to see things at the macroscopic level. But then sometimes, when you do, the view doesn’t seem so pretty anymore.
The usual questions start popping up, questions like “What am I doing?”, or “Why am I doing this?” You have a clear view of all of the flaws, and none of the virtues. Nothing looks as good as you thought. The game doesn’t seem very fun. The interface sucks. And of course, nobody is going to want to play it.
And that can be a really deep valley, because now you’re not just dealing with the motivation to push through the boring crap, you’re dealing with the motivation for the whole project. It’s the kind of valley that can kill a project.
Of course, as with many things, it’s never as good or as bad as you think, and sometimes it just takes a little perseverance to get through those periods. Maybe getting back to the microscopic level until the bad mojo passes. Or maybe taking a little time off from things and recharging the batteries. Or, perhaps, using the opportunity to get other people involved — letting fresh eyes take a look at things to see what works and what doesn’t, recalibrating your inner barometer.
I don’t know what proportion of game projects go through valleys like these, but I imagine it’s fairly high. I think it’s probably more of an issue for individual developers and smaller indie groups, since there are fewer eyes looking at things from wider angles. Regardless, I think it’s an important issue to mention to aspiring developers. Hell, it applies to anyone working on any kind of creative project. Be ready to hit at least one, and decide whether you’re gonna suck it up and fight through it, or let the project wither away.
So I’m in one of those valleys right now. The closer it seems that we get to a working demo, the less I think this is actually going to work. It’s hard to imagine people thinking the game is fun. The performance will stink, the animations and voice acting will disappoint, and the interface will be nothing but a confusing mess. What’s to love?
I’ve taken about a week off from the game, but I’ll be getting back to it soon. And I think maybe the best thing to do right now is to start getting some new eyes to look at the game. Do some testing, see if it really does stink. Maybe see what parts can be improved, and what parts just don’t work at all. It’s getting to be that time. And so I may need some help with that.
Enjoyed this article? Subscribe to The Monk's Brew RSS feed.