Favorite game mechanics of 2012

I am initiating this seasonal tradition here at the Gameshelf -- which may turn out to be a singleton tradition, that's always a danger, like New Year's resolutions, but we'll give it a shot, right?

Frequently I play a game and think "Hey, that was a well-designed game." It's not so often that I play a game and think "Wow, that one design element really stands out -- and I've never seen it before! Clever." So I wanted to pick out a few of my favorites from this year.

I'm not talking about featured gimmicks here. I'm talking about ideas that other games might reasonably think about adopting. Yes, Portal has a core game mechanic, it's very clever. If you use it, you're writing Portal 2. (Or Darksiders, but let's not get into that here.) There have been a spate of these core-puzzle-mechanic games -- Quantum Conundrum and Unfinished Swan were two fine examples I played in 2012. But I want to talk about the mechanics that quietly make your game better.

Behold, my choices for 2012. No doubt I'll think of another favorite tomorrow morning.

Zarfplan: And that was November

Plan for the month: get all the shortcutting code finished, before the end of the month. Result: it's 11:59 pm on November 30th. Drat! But it is finished. Pretty much finished.

Sometimes code is painful. Sometimes code don't want to be written. That is to say, sometimes you just don't wanna write it. I am no more immune to this than the next hacker. Maybe the next hacker has a better strategy, but I try to get some progress made every day, and not think about the looming mass of progress I haven't made. Eventually the looming mass shrinks, and that's what's happened this month.

Why was this painful? Just an annoying collection of cases, all of which have to be handled differently, with guards against infinite loops and other such game-creating failures. See, there are shortcuts for going places, finding objects, and creating objects. Sometimes finding an object means creating it; sometimes it means going to where it is. And then there's the distinction between checking if a goal is possible, and actually carrying out the goal. None of this is conceptually difficult, but I have to get the code structure right, which means some false starts and then rewriting once I have a clearer idea of all the requirements.