IndieCade, and MOR updates

So two weeks ago I went to IndieCade…and it was frikkin awesome. I got to meet tons of talented, passionate indie developers, I met some of my game dev heros (JOHN ROMERO!!!!), and I played some awesome indie games (RENGA!!!!!!). The talks were also very inspiring, especially Bernie De Koven’s key note on The Well Played Game (reading the book now) and Bennett Foddy’s talk about difficulty. Overall, it’s a great feeling to be part of a relatively small community drawn together by a common creative passion.

I was also showing Moments of Reflection to anyone who would spare the time, and that was a great idea. People really enjoyed the game, and it also helped to uncover some issues with the game. Based on watching people play it (I think I got about 10+ people to play it for at least 10 minutes), I redesigned the “tutorial” a little bit for the better. I basically got sick of telling people that they could move the mouse :P One highlight was during the “Game Slam”, where I got to show the game to a small audience for 2 minutes. The moment I showed the reflection mechanic, I immediately got a round of applause initiated by Richard Lemarchand! It feels a bit cheesy to say this, but I can’t deny that that kind of validation is very invigorating. The game was also recently featured on http://freeindiegam.es, which blew my mind a little bit that those guys would care about my game :)

Anyway, I don’t know when MOR will be considered “done”, but I will definitely continue to work on it. There are still mechanics I want to add and see how they interact with the core reflection mechanic. We also plan on doing more world-building to give the game a sense of atmosphere and cohesion. I also must thank Sijie Liu, who has done all the visual art (except for the stuff that sucks – that’s me), and Mark Anderson, who is doing all the sound and music. I’m infinitely grateful to have these talented folks working with me.

Lastly, I submitted the game to the IGF and made this lil trailer for it:

Updates

OK, more MOR updates. This game is turning out much better than Pupil! I’ve been working on it for almost half a year now, and so far the puzzle count is around 30. They’re not all super-awesome, but there’s a good amount of stuff in there I’m pretty proudĀ of. I’ve also cut a bunch of puzzles that felt like filler. I have a few more ideas for mechanics, and I don’t think I’ve squeezed the existing ones dry yet, so there’s still plenty of work left! I think I’ll submit it to IGF – not expecting anything, but I would love to get people’s feedback. The current build looks something like this:

Image

I’ve also started prototyping another simple game mechanic that’s turning out OK so far. I think it has promise…but it’s gonna take some more tweaking before I’m convinced. I’ve started learning Lua and I’m using LOVE2D to prototype it – I actually like it better than Unity for rapid prototyping! Cool.

In other news, I’m done with my PhD (so you can call me Dr. An :P), and I’m living in the SF Bay Area now! W0000t.

Update: “Moments of Reflection”

So, another thing going on in my life right now is finishing up my PhD. I’m giving a talk at SIGGRAPH this year, and I’m defending my thesis right after…so I’m pretty damn busy :) But I still find time to at least design and think about my current project, Moments of Reflection (MOR).

One minor revelation I’ve had recently is how to teach the player the reflection mechanic: Do it step by step. In Portal, you don’t get the full portal gun right away. First, you just step through a portal. Then you get to control a portal with a button. Then you get to place one portal. Then finally, after about 4-5 “tutorial” puzzles, you get the full portal gun. I generally find this sort of tutorial muuuccchh more enjoyable than tons of text boxes all over the place.

Give the player things one by one, and let them play around and learn it on their own without popups screaming orders at them all the time. Restricting the player’s abilities might seem lame at first, but it allows you as the designer to stop nagging them. They can’t mess things up too much, so you don’t need to tell them what to click and what strategy to use. They can discover it on their own! And self-driven discovery is always more fun than listening.

I’ve implemented this in MOR by initially removing the ability to change the mirror’s angle. So I have a few puzzles where you just need to position the mirror correctly, and it’s always facing left. This is better. But now I’m thinking, maybe I can go a step further and redo the controls a bit. Right now, you click to set the location, then move the mouse to set the angle. But playing with the position-only puzzles revealed a flaw in that system: You can’t continuously change the position. If you put down the mirror and then realize it’s not gonna work, you have to cancel, move your cursor, then click again. Why not just have the mirror’s position follow the cursor, so you can just move your mouse around? Then we can assign rotation adjustments (which are snapped to 45 degrees anyway) to the Q/E keys or the mouse wheel. This makes the intro levels less cumbersome, and I think it will make the rest of the game feel better as well.

I dissected the controls, and not only did it yield a better way of teaching the player, it also helped me to realize a better control scheme. This is why I love game development!

Quickie: Two-sided Mechanics

Quick thought: When considering new mechanics to add to a puzzle game, consider how they can be useful AND detrimental to the player’s goals. Ie. ask yourself, does the mechanic have both pros and cons? If so, design puzzles that demonstrate both sides of it! If not, could you modify it in some way to make it two-sided? If they only have cons, the player may feel annoyed. If they only have pros, that’s probably fine, but less cool :)

Example of a con-only mechanic: The concrete un-portal-able walls in Portal 1/2. Portal 2 used them way more, and while it makes for some neat puzzles, I couldn’t help but feel that they were a bit cheap. Especially considering that Portal 1 used them in relatively fewer situations. Could they have been useful somehow? What if there were “enemies” of some sort that shot portals, and maybe in one puzzle you had to prevent them from portaling? That’s not really a great idea, so perhaps this is a lost cause. I’m sure the Valve folks pondered these questions as well!

Example of a pro and con mechanic: The magic items in Braid that were unaffected by your rewind. They were useful, such as the first key-in-pit puzzle, but they were also detrimental when applied to enemies and certain platforms. Same with the goo’s in Portal 2: Clearly they were useful in a lot of situations, but in others they acted as an obstacle. I’m pretty sure there was at least one puzzle where the bouncy-goo was in your way and you had to find some way around it.

In my current game, I was about to add lava – ie. parts of the level that will kill the player upon touch. But then I asked myself..is the death necessary? If I removed the death, and just made it rock that is unaffected by the reflection mechanic, it can still function as an obstacle by blocking the player’s path. But then it can also help the player as a platform! So I’m gonna implement it without death, give it collision, and try to design puzzles that also highlight its positive uses.

Spoiling Emergence

Emergent game play, where the mechanics behave in some non-trivial, unexpected, and beneficial way, is quite fun when it happens. One of my favorite moments in Deus Ex was getting past a turret by holding a crate in front me, effectively using it as a shield. This is something that many designers strive for in their systems. When the player stumbles upon such a moment, they get the joy of discovery, creativity, and pride. They want to tell their friends and the internet about it. It’s good for the experience, it’s good for PR.

However, these days with the internet and PR practices, such moments can often be “spoiled.” One example that comes to mind is BioShock. Before the game came out, the PR campaign talked a lot about how you could electrocute enemies in a puddle of water by shooting lightning into it. The NPCs even told you this in the game. Was this the best thing to do?

What if they had just let players discover that on their own? I think that would have been better for the game experience. By spoiling it all in the PR campaign and then in the NPC chatter, they robbed players of the joy of discovery. It’s simply fun to discover and figure things out on your own, and it’s one of the most unique aspects of games. Imagine if, during a heated battle, you just happen to notice that lightning travels through water. You may have thought, “Oh wow that’s so cool that they made that work! Neat! I’m gonna tell all my friends about this cool moment!”

Of course, BioShock was plenty successful anyway, but I think keeping things a bit more mysterious would have been beneficial. This is part of the reason why I’m not watching any of the PR media for BioShock: Infinite. I am totally pumped for the game, and I want to discover it all on my own – story and game play.

Trial and Error in Games

Just a quick blog post about something I’ve noticed in the games I enjoy. Nothing new or revolutionary or anything, but just thought I’d write it down: I like trial & error in games as long as the “down time” between each trial is minimized.

I think trial and error is a very valuable type of experience for games to give. It’s fun to over come challenges, it’s fun to learn and discover and experiment, and I don’t really know how to allow for those experiences without a lot of trial and error. It can be frustrating, and as a result, I think many games have decided to just make games less challenging, less interesting, and less open to experimentation to avoid the frustration. But I think it’s pretty clear we can minimize frustration without gutting out the good stuff.

I think it has gotten a bad rap in recent years for some very non-inherent reasons. For one thing, load times. If you have to go through a long load-screen every time you fail, then yes, I can see how that becomes very frustrating very quickly. More generally, “time filler” that you must go through with each trial is very frustrating. This includes load times, but it also includes cut-scenes, mindless game play, long traveling times, and just any activity that takes any time at all but requires no interesting action on your part. This is generally what I mean by “down time.” This also includes game-over screens that over stay their welcome. “Snake? Snake..SNAAAAKKEEE!!” I loved MGS3 in Euro-Extreme Mode, but yeah, totally could have done without that each time.

Recent platformers like Super Meat Boy, VVVVVV, and LIMBO excelled at eliminating down time, and I hope more games follow suit. I would like to consider how to eliminate down time in some game-types that are heavy on trial and error, such as stealth games and turn-based strategy games. I think it’s pretty straight-forward in stealth – just eliminate load times and keep “rooms” small. Stealth Bastard, Beat Sneak Bandit, etc. all accomplish this pretty well. Adding rewind would also be cool, maybe?

But what about turn-based strategy? In a game like X-Com, battles can get pretty damn long. I feel like it would be a shame to shorten these battles, as many TBS games do these days. The more you shorten it, the more you remove the possibility of emergent experiences. Would unlimited undos help? That’s pretty much how I played X-Com anyway, just saving a lot of checkpoints (and copy/pasting save games in the file system to get around the game’s save limit). But maybe some sort of “check point tree” would be cool? Instead of a rewind feature, we actually maintain a tree of each turn, and we allow you to go back to a previous turn and explore other branches. But, you can go back to parallel branches as well. This is just facilitating the exploration of a large possibility space. The technology is there – just save games – but maybe presenting it as a huge tree and allowing easy navigation with fast save/load would be cool? You could try different branching strategies… :: end brain dump ::

Now, what about Demon’s Souls? It’s definitely less accessible than SMB, VVVVVV, since the time between trials can be pretty long (lose against a boss? Start all over from the beginning of the level). But I still enjoyed it, and I think it was because that time was not mindless. It wasn’t “down time”. It was filled with combat and traversal that required your attention. It wasn’t mindless, but rather very mindful. Again, I can understand if most people find DS’s structure frustrating, but I found it more tolerable than most games with bad check points. I’m not sure if the DS-style experience is something I’d want to make, but there’s something valuable to it…

UPDATE: Many “casual” games are actually very good at trial and error game play. Cut the Rope, Angry Birds, and Beat Sneak Bandit all come to mind. They’re easy to beat, but to get 3 stars in them is very difficult. This is also similar to racing games – it’s easy to finish the track, but getting first place requires much skill and practice. One game I will probably work on in the future – perhaps after Moments of Reflection –

Project Updates

It’s been a busy time for me, looking for a job and all, but I still manage to find time to work on the 2/3 projects I’ve got in the pipeline:

- The rhythm game has a fresh new title: Beat Juice Radio. Play the current build here!. A lil bit Puzzlejuice and a lil bit Jet Set/Grind Radio, two games with some killer style and innovative game play. We also got a new artist and he has come up with a sweet new look for our game. Here’s a sneak peak:


We’re hoping to wrap this up in about a month and put it up on Kongregate. Then, we’ll have done our part in pushing rhythm games a little bit.

- About a month ago, I finally implemented a puzzle platformer idea I had been sitting on for a while. The result was this:

There are about 14 levels in there right now, and I have some more on paper. This is a much better “yield rate” than Pupil – I should definitely implement more ideas from my list more often! I found a fellow Cornellian to help me with the art, and so far she’s produced some great mock ups. Here’s one of them:

It would be great to get this ready to show for Indiecade, but given that I’m gonna be completely busy in May with work, job interviews, and a lil bit of Beat Juice Radio, this will have to wait until summer. Ah well!

As for Pupil, well, I’m pretty much taking a break from it right now. I still think about it a lot, especially while playing Fez. I think Pupil would be very well suited as an exploration-style game rather than its current Braid-like focus on puzzles. If you haven’t heard them already, the Infinite Ammo podcast has some great conversations with indie devs about the creative process. It’s good to know that other indie devs I really respect also face the same kind of creative struggles that I’ve been having with Pupil.

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!

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!