Brian Crick

Global Game Jam 2014 Post #1: Planning on Failure

My Global Game Jam 2014 entry is up, and I thought I’d spend a few posts talking about it.

First, I want to talk about failure. One great thing about game jams is, they’re a safe environment in which to fail, and I haven’t really been taking advantage of that. I’ve always been cautious, limiting the scope of my projects in past game jams.

But for this game jam, I rather deliberately set out to make a project that I was certain was outside of my abilities to finish. The question was not whether or not I would fail. The question was how I would fail, which is valuable knowledge to have.

And this the most important thing I’ve learned: at every game jam, and in other projects, you will have a feature you just can’t complete. Because you don’t have time, or the skills to do it, whatever. And… I handle this situation very poorly.

example #1: the embarrassment factor

I always try to compose music pieces with multiple layers that are dynamically mixed together at runtime based on the game state, but for this to work, the music has to play long enough that the player can listen to the music and get used to it before it changes on them, so they can realize something changed.

I tend to make only get around to making a minute or so of music for game jams, and while that’s unquestionably short, that’s not all of my problem.

The problem here is that I always try to hide my short, incomplete music cues because I don’t want to make it that obvious how little music there really is. Allowing my short cues to loop endlessly is the obvious solution here. People do it all the time.

example #2: the coolness factor

In an attempt to make my game tie in with the theme for the jam, I made these ghost things, these swirling vortices, and they were very pretty, well-realized vortices.

They made the game pretty much unplayable. As soon as you touched one, you died, and they were everywhere.

See all this level? You can’t get to a fraction of it most of the time.

Interior-Editor

 

I tried to solve this really quick after the jam by reducing the number of ghosts, but they still just sat there, blocking your path, and weren’t very fun.

A quick solution during the jam would have been to remove the ghosts entirely, but I didn’t want to do that because they were the only thing tying the game to the theme.

why the embarrassment factor and the coolness factor are actually the same thing

These are both symptomatic of the same root problem: when I have a feature that doesn’t work as expected, and a deadline is approaching, I start to make decisions based on whether I want people to see the work I did, rather than making decisions based on the feature’s effect on the game as a whole. And it enters this weird limbo state where I’m unable to fix it properly, unwilling to cut it, and uncomfortable with bringing it to the foreground and looking at it long enough to think of a decent stopgap solution.

I suppose there’s a certain amount of pride at work here. I want to fix these things without allowing myself to experience them in their broken state.

So that’s something I need to watch out for. In my next post, I’ll babble about some more mundane workflow type things.

 

 

Copyright © 2017 Brian Crick.