Pacing and Dear Esther

I didn’t like Dear Esther very much. I thought the audio/visual experience was great, but after spending one hour on that virtual nature hike (gorgeous!), I felt a little cheated out of my money. This is not a good feeling, as Jon Blow, one of my indie idols, partially funded the game and presumably likes it. It also got glowing reviews for the most part, except from Destructoid. It’s never great to feel like you don’t “get” something.

After a bit of thinking, as I like to do about these things, I think I’ve nailed down what exactly I didn’t like about it: Pacing. It wasn’t the fact that the game isn’t very interactive; I loved “To the Moon,” which is barely a game. It wasn’t the fact that it was incoherent and vague; I love David Lynch movies and experimental music like Sonic Youth and Yume Bitsu. It wasn’t the British voice; I love Ricky Gervais and Steve Merchant. It was the pacing. It was the fact that not much really happens in that one hour – there weren’t many “beats.” If your game doesn’t have much game play, you can still have story beats, like “To the Moon.” If your story isn’t very coherent, you can still have “beats” despite that. One of my favorite movie scenes is the diner scene from “Mulholland Drive”, which has little to do with the rest of the movie (and the rest of the movie has little to do with the rest of the movie), but it’s a moment of intensity that is an undeniable “beat.” Dear Esther has a few such moments, but only a handful in the whole one hour experience.

Now, this was probably intentional. Steven Pinchback has said in many interviews that part of what he wanted to do with Dear Esther was to give players space to feel and think. I can understand where he’s coming from. Most games these days are about keeping you constantly bombarded with stimulus that it gets overwhelming and numbing at times. But, for me, going too far in the other direction can lead to a boring experience.

I don’t believe in making value judgments when it comes to creative endeavors, so I’m not saying what kind of pacing is good or bad. Plenty of people really enjoyed Dear Esther, and that’s great. My tastes just lie elsewhere on the axis of pacing. Thanks for reading!

Advertisements

Lesson Learned: Beware of prioritizing aesthetics over design.

So last night I finished up my second Pirate Kart entry, MachineHead. Compared to BoomBox, which I think is quite fun and addictive, MachineHead is a complete dud. After thinking a lot about why it sucked so much, I got to the root of it: I was letting aesthetics dictate the design.

The basic inspiration for the game, in addition to the awesome Bush song and Lost Highway, came from images like this:

Now that looks pretty cool doesn’t it? Surely it would be cool to play as a game! And I think I succeeded in creating that same sense of speed (pro-tip: randomly jitter the highway and use UV scrolling).

(it looks cooler in motion) OK…but what about the game play? I wanted to do some kind of avoid/collection gameplay, since that goes pretty naturally with speed, and I think that was a sound foundation. Plenty of games use it to great success. So why does my game suck?

There are many reasons, but the basic reason was this: I was too married to the look. For example, one thought that came to mind was to make the red/green streaks sparser, so you weren’t just being constantly bombarded with them all the time, and it would give you time and space to think and strategize. But I immediately shot down that idea because that would kill the look! That, right there, is the reason this game fails. Who knows if that would’ve fixed the game, but the point is, I was shooting down ideas because I was prioritizing the look of the game over trying out new mechanics.

Once again, here we see the value of making small games. I could have learned this lesson over the course of many months, working on a game of moderate size. Hell, some studios learn this lesson over the course of years and millions of dollars. But on MachineHead, all I paid for this lesson was 4 hours of my time. That, dear readers, is the value of making small shitty games. PIRATE KART FOR LIFE.

Failing Fast, Failing Furious

If you’re an aspiring indie dev like myself I’d highly recommend checking out this talk by Alan Hazelden. He does a great job of echoing a message expressed by many other successful indie devs: When you’re just starting out, make many many small games. You need to just try stuff, fail, learn from it, and move on. Don’t dwell on a single project for too long, because it probably isn’t very good to begin with.

Now, I’ve been working on Pupil on and off for almost a year now, so this really hit home. I indeed have been getting bogged down by technical issues (growth physics), and I’m pretty unsatisfied with the number of puzzles I’ve come up with so far. I think I’m just a little too married to the game, and I will admit when I first started working on it I thought it was gonna be a huge hit – how naive!

Given all that, I decided to make a game for the Pirate Kart, and the result was BoomBox. I did it in about 4 hours, and I think it was quite successful for what it is (a dumb and addictive mini-challenge). The development process was also pretty interesting. I started with the idea of the single-button rotating cannons (stolen from Yoshi’s Island) and nothing else. I had no idea what the rest of the design was gonna look like. I implemented the bubbles, since every platformer ever has something like that. And I placed some cannons and bubbles around and fixed some bugs…and it wasn’t really fun or anything. Then I just started messing with Unity’s “snap to grid” function and started putting the things into a grid – maybe something would come of that? So I just played around with that a bit more, added some sounds, and decided to remove gravity. Then I noticed it was actually pretty challenging to just aim the cannon…so OK, maybe I could slap a time limit on this and make the walls “lava.” And 30 minutes later…I was still trying to beat this monster I had made almost by accident. I zipped it up, submitted, and that was that.

This was such a nice change of pace from Pupil! I think I’ll stick to making these shorter games for a while, as I’ve got so many other ideas I’d like to implement. One interesting thing I noticed is that my code base for BoomBox is so much cleaner than Pupil’s. When you start fresh, you have an opportunity to take everything you’ve learned and actually apply it without the fear of breaking stuff.

So, I think I’m gonna wrap up Pupil soon. I’ll probably implement one more mechanic (magnetic fields), see if that yields any interesting puzzles, and then just consider it “design complete.” I’ll keep making it look nicer, integrating John’s art and experimenting with some real-time fractals, but as far as designing levels I feel like I’m stuck here and need to just move on and call it “done”. Sure, the end result will not exhibit the kind of elegance, completeness, and sheer length that my favorite puzzle games exhibit, but hey, this is my first one. I’m still a n00b at this. Some day later, I hope to come back to Pupil with better puzzle ideas and really build it out!