Elements of Design: Technology

The last few times I've sat down to work on the game, I've been wrangling the same problem. I set my protagonists next to one another . . .

It was very gracious of them to pose for this shot.

 . . . push a couple buttons . . .

up up down down left right left right b a start

 . . . and watch as the girl drifts off the top of the level, never to be seen again.

The sense of abandonment is sobering but not exactly what was intended

Now, this is not ENTIRELY inconsistent with the behavior I'm going for, but it's still something of a problem.  If you are the sort of person who has messed with code in a game context or otherwise, you probably know about putting on your Code Gloves (like gardening gloves but smellier) and getting mussy up to your elbow in brackets and semicolons. It's fun and rewarding when you find an elegant solution to a problem, but as one concern starts to dominate your time you can begin to panic at the amount of resources you're pouring into solving a problem you never considered might exist.

One of the major differences between my esteemed co-developer and myself is that if I could magic the game and physics and behavior into existence with a nod of my head, without any of the mucking about in Javascript, I would do so. My partner wouldn't have it so; to him, the code itself is something beautiful and a lovely process, and on days when it's going right I can be impressed by our accomplishments too - but on other days, I wish I were making a board game. Whichever pole you gravitate towards - and if you're a dev, you probably bounce between them - your game is going to be supported by some kind of technology, so I want to examine some of the considerations of technology. Since I'm mainly interested in video games, I'll be talking mostly about code, but remember that your "technology" could just as easily be a board, or some cards, or a stack of books and some dice.

One of the things that's really cool about code is that it is one of the most tactile, controllable aspects of a game's design. In a medium that's really fuzzy and lacks a lot of precision or definition, this is an advantage we should cling to for dear life. Like the art, or the balance, or the story, code can be tweaked, code can bloat, code can be missing crucial elements or weighed down with unnecessary elements. The advantage is that code is more strict than the other parts of the game. If you're doing something critically wrong with your script, it won't compile, and you will know immediately; if you're doing something critically wrong with your art, it'll suck, and you probably won't know why or how to fix it for awhile. When you are rightfully kicking yourself in the head for the typo during the villain's grand speech just before the final confrontation, you will wish that the person typing your story up could be as strict as your compiler. Your code can still suffer from vagueness or lack of clarity, and can still have corner-cases you can't always see, but its representation is at least concrete and responsive.

Semicolons are the lucky ones. It's null pointers you must beware.

Technology, of course, offers a lot of limitations. You can't do better than the system you're working on or the tools you're using for implementation. For our own game, we're more limited right now by what we don't know how to do than what our computers or Unity can pull off, but think about the kinds of experiences that weren't possible until recently. Would Minecraft have been doable before it was possible to generate worlds of that magnitude? Could we have the experience of World of Warcraft before the infrastructure existed to support so many characters in the same world? Still, I'm going to assume the majority of my audience is limited not by the available technology, but by their ability to use it - in terms of time, resources, skill, etc. If I were a master of Unity and Illustrator and Blender my game would be a lot prettier, but since I'm not, we make do; maybe our game could be using more of the available technology, or using it more efficiently, but we have to work with the skills we have.

Sometimes, though, that isn't a bad thing. Part of what appealed to us about a shadow puppet-style game is that it was within our abilities. Our characters can look pretty static, and have simple animations, and still adhere to the aesthetic. It can even be charming. Similarly, though I'm certain there was no lack of skill that limited Mike Bithell to rectangular characters and platforms in Thomas Was Alone, the simplest uses of Unity suggest those kinds of shapes; starting with very basic uses of technology and using that as a stylistic theme helps direct the art of the game. Benjamin Rivers of Home imposed similar limitations on himself, to the betterment of the game. Pushing technology to its limits can produce something really wonderful if your vision is well-planned out, provided that vision isn't visibly handicapped by its execution. But when a game is visibly aware of its technology, and plays on the limitations of that technology in an elegant way, it can serve to unify the experience, as Thomas Was Alone demonstrated so successfully. If your technology doesn't get in your way, that's good; but careful understanding of it is what makes it not just an enabler of your game, but an active agent working towards whatever single purpose unites the disparate elements of your game.

Thinking about technology in this way gives us some interesting lenses for examining games. Is this game making full use of its technology? Is it handicapped by its technology? Is it playing off the strengths and limitations of that technology to achieve its purpose? Looking at technology is a way of examining our tools, and deciding whether those tools are sufficient for our vision, and whether we are using them in a way that makes our game as beautiful as it can be.

Review - Thomas Was Alone

When I first started playing around with Unity while beginning work on Candlelight, I made the simplest level I could. It had rectangles for characters, rectangles for walls, very simple physics, and a very simple aesthetic. A few people said "You know, this could almost work as a game." And the people who made Thomas Was Alone proved them right.

I've felt this way about the world sometimes.

Thomas Was Alone is a Unity-based platformer by Mike Bithell that follows the adventures of fledgling AIs as they slowly gain awareness of themselves, their environment, and one another. You begin play as Thomas, an orange, rectangular AI, and gradually add more AI friends with different abilities to your fold, with the goal of each level to get all of your rectangles to their respective end portal. You can switch between the characters as you please, and their abilities range from simple (John's great jump distance) to more specific (Claire's ability to survive the game's toxic water) to outright detrimental (Chris's slow speed and low jump). The levels are about using the character's abilities to compensate for one another's shortcomings.

You, too, will come to find stairs difficult. Consider yourself warned.

Every element of the game has a refined simplicity: the characters are just little rectangles, but they wobble and bend when they jump; the backgrounds are unobtrusive, but pulse with little symbols and pixels like the inside of a computer program; there is no dialogue, but the story is expertly narrated and brings just the right amount of emotion and humor. The game enjoys a straightforward, no-(some)-nonsense style, but it doesn't use that as an excuse to slouch when bringing life and activity to the details.

They're a festive bunch, and assembling the team feels kind of cool. Like The Avengers only the characters are, somehow, less two-dimensional.

The characters are the stars of the game, and their story is delightful and adorable. Despite having no voices, faces, or curves, the characters are some of the best I've seen this year; the narrator explores each of their internal monologues and insecurities and aspirations, all of which extend naturally into those characters' abilities. The humor is sometimes deprecating, but not as spiteful or unrelenting as that of, say, Portal; Chris is meaner than he needs to be to Thomas, but is lonely when they are separated. Portal's humor works because GLaDOS is a sociopath, where Thomas Was Alone's humor works because the characters are all believable  and likable. The story has a couple neat turns but isn't overly complicated, and like the rest of the rest of the game it succeeds not by doing anything enormously groundbreaking but by weaving its charm and style into every aspect of the experience.

It might feel hard to write a lot of emotional significance into rectangles, but you will.

Thomas Was Alone isn't an especially long game, and the difficulty never ramps up out of control. Though the story and its ending feel complete, it's a little sad to put those characters away when you get through the last level. But at its end, the game is like a little peek into a beautiful world, and too much more might spoil the illusion. Bithell's creation is an excellent platforming experience, and remarkably fun, but in addition, it's a case study in common purpose uniting a design: every aspect of the story, the visuals, the sound, the level design, and most importantly the characters is in alignment, and all feel deliberate, targeted, and successful. This is what makes Thomas Was Alone a good game; that all of those elements, and the game they serve, happen to be so vital and enjoyable is what makes it a great game.

Website: http://www.thomaswasalone.com/
Mike Bithell's Twitter: https://twitter.com/mikeBithell

What are we looking for?

Whatever game you're playing, you can almost always find some aspect of that game that is about acquisition of stuff. This "stuff" can be of a few kinds: things with a physical representation in the game world (coins, ammo, helmets, new levels), things that have value within the mechanics of the games but no physical representation (extra hearts, level-ups, skill points), or things that have no inherent gameplay value but some other kind of worth to the player (achievements, special endings, easter eggs).

I guess when you play the Song of Time all this stuff gets recycled back into grass?

What this Stuff does for players varies by game and by type of Stuff - we've explored already how feedback  can be used to guide players along certain paths, and Stuff is both a kind of feedback and a mechanism for giving feedback. You learn that cutting grass gets you rupees, so you cut all the grass; you learn that the blue goo makes walls and floors bouncy, so you experiment with finding new ways to direct and redirect the blue goo so you can get to new areas. But why do we want the rupees, or the new area? Usually the answer to this is: so that we can do more things. We like new powers, new challenges, new places, new things to do. Implicit in each fabulous new weapon you pick up in Diablo 2 (marginally better than the fabulous new weapon you picked up 3 hours earlier) is the feeling: "Awesome, now I'm gonna be able to kill ten more of those little goblin things every minute!" When you beat a level, you get pumped and excited about the next level and all the things you get to do there.

But I don't want the idea of more-things-to-do to undercut the feedback power of getting Stuff, because using Stuff as a feedback mechanism is one of the sharpest tools in addictive game design - for better or for worse. MMORPGs give you tiny incremental gains, Tetris gives you line-clearing, Facebooks game gives you little points and stats and notifications.

Yay! I got a new, um, eggplant? I never played FarmVille.

The games that are often the most addictive are the ones with the most rapid rewards structures. In general, if you can give out lots of little rewards, you can keep players' interest piqued. You'll just want to turn the next corner, to meet the next character, to gain one last skill point.

This is how weekends are lost.

This isn't as easy as it seems. Coming up with a game that can perpetually give you rewards while still keeping those rewards meaningful is really, really hard. Add more stuff, and you can run into balance or complexity problems. Throughout World of Warcraft, balance is maintained so that the little boosts you get gradually draw new challenges into the realm of possibility. And the fact that they can keep players doing this for as long as they can is what makes the game so addictive (and why, I'd argue, the game is borderline amoral; "addictive" isn't a word I'm using with any hyperbole here). For any game you hear described as "addictive," think of the things players get in that game, and how frequently they get them; this is very likely a big part of why the game is addictive.

There are plenty of more benign examples of how a fast-paced rewards structure can be used to keep a game exciting. A good one is Katamari Damacy, which gives you the satisfaction of picking up all those little items, of sizing up and suddenly being able to go new places or pick up new things, of going from not being able to pick up a banana to lifting buildings out of the ground in a 10-minute span.

It's only a matter of time for that mountain, too.

Katamari certainly feels addictive a lot of the time, and this is a big part of why; you always want to do just a little better, to get that ball of weird stuff just a little bigger. Moreover, the frequent incremental gains keep things moving at a quick pace, and as you build momentum you want to maintain it as best you can. At the same time, there are upper limits on this, and eventually you will wear yourself out on the game or complete it. That's because games like this one are designed to be a finite experience. You can continue to improve and collect, but there's a last level you can beat, and a limited number of secret items to find. But throughout that finite experience, the rapid affirmation of your progress by way of Stuff - new levels, bigger Katamari, less traumatic derision from the main character's father - is key to enjoyment of the game. 

A lot of games do very well with a slower-paced rewards structure - Shadow of the Colossus comes to mind - because the games themselves are slower paced. In SotC, the rewards you get aren't always overt; you grow a little more powerful with each monster you kill, and you get the satisfaction of watching a cutscene of the monster's death, but sometimes it's just as enjoyable to be riding through the silent landscape towards your next encounter. Having the game's major rewards be more spread out heightens the anticipation. Slower reward pacing helps players appreciate rewards; faster reward pacing helps increase momentum and excitement; and incredibly high pacing can either burn players out or become addictive, depending on how it's implemented. Try watching, as a player, for the rewards that the game gives you, and think about what reaction they're seeking from you by giving you those rewards.

E-Sports

It's been true for awhile now that I enjoy watching high-level games of Starcraft 2 almost as much as I enjoy playing the game itself, and I think in most circles that statement would still earn me funny looks. But the idea of video games as having inherent entertainment value for people watching them is something that's starting to gain more traction; Starcraft has been a very established e-sport for some time, and Blizzard has been considering making Starcraft 2 free to play so that it can compete more easily with free-to-play e-sports like League of Legends. I spent an hour or so last night sitting on my couch, eating nachos and watching Day[9] (a Starcraft enthusiast and commentator) analyzing games between high-level players, and in order to keep that admission from being really embarrassing I thought I'd break down a bit of what I think is really cool about that activity, and about e-sports in general.

Actually, "Day[9] is really attractive" might be enough of an explanation.

I was never very physically active in my youth, and never pursued any competitive sport for very long. Maybe for that reason, I've never been taken with watching sports in general; I haven't been to many games of any sport in my life, and I don't know if I've ever watched a game of any sport start-to-finish on TV. Part of that is not understanding the sport, and part of that is not having any point of context for what's occurring; I don't know whether to be impressed, or how impressed, by any feat of any athlete because I don't have any benchmarks to compare it against. I haven't tried to do it myself, and I haven't seen enough talented players try and fail, so the accomplishment is lost on me.

From that perspective, I enjoy e-sports because I understand how complicated some of the things that are happening are. When watching a Starcraft 2 game, I'm impressed when a player correctly infers what army his foe is amassing by seeing what resources that foe is focusing on collecting. I'm impressed when a player commits the barest resources necessary to respond to a threat, so that her production doesn't slow. Hell, it's not an e-sport example, but I used to love watching Metroid Prime speedruns, and seeing people abuse the game in strange ways in order to get through it as quickly as possible. When you know enough about any activity - sports, dance, singing - to be impressed by someone who's good at it, it can become really fun to watch people do it at a high level because you can appreciate the subtleties of what they're doing. When that's dynamic and competitive, as sports are, watching two players who are both very skilled face off, and knowing only one can win, is exciting as hell, even if they're just moving little bugs and spaceships around a digital map.

If this makes sense to you, you might think it looks pretty cool. I do, anyway.

Because of this, I think this offers gaming a way to break into a kind of market that regular gaming doesn't always provide: watching, in addition to playing. And where there are eyes there are advertisers; this is an incredibly profitable avenue for some kinds of games. Which, though interesting, isn't the most interesting thing about e-sports to me. I'm personally just excited about the opportunity to enjoy these games in a new way. It's fun being a couch-critic, to whine with the benefit of hindsight about bad decisions made by great gamers. It's fun sitting with friends and eating nachos and watching a game. If you can get invested in one side or another, there's a lot of tension and entertainment to be had in watching a match. (Granted, team loyalty isn't something that I think is as easily built in fans of e-sports, but that could change as e-sports become more popular.) It's great being able to feel like you can participate in a game even if you aren't great at playing the game yourself. And as I mentioned before when talking about strategy and asymmetry in competitive games, these games lend themselves by virtue of their complexity to a complex metagame, and the more that metagame is examined and discussed and refined - by the grinding of thousands of players on the servers as well as the careful experimentation of masters at the tops of the ladders - the more engrossing it becomes not just to play, but to watch and discuss. It's a new way to engage with games, and more importantly to me it's a new way for people to come together around games. Games are a lot of things to different people, and sometimes they're social and sometimes not. But when they are social, it's really cool to see the roles they can take in social groups starting to expand; it's another indicator, of many, of how many more ways there are to look at this medium, and how much is yet to be done with it.

Interview: Benjamin Rivers of Home

Today, we are fortunate enough to receive the wisdom of Benjamin Rivers, who kindly answered a few questions I had for him regarding his experience with game development, particularly Home. His answers are reprinted verbatim.


What would you say was the biggest technological impediment/problem/question you faced while creating Home? The biggest stylistic one? The biggest design one?

The entire design was the big question, because that's how I approached the project. The goal of the game was to create a lo-fi horror game that genuinely creeped people out and was engaging. So, really, just coming with all the elements I felt I needed to do that was the biggest challenge. Also, my relative lack of experience in programming. :-)


What are some major differences between how you initially envisioned this game and how it ended up?

The only major difference is the visual fidelity of the game; originally it was going to be an almost Atari VCS kind of quality. After much convincing by my wife, I decided to increase the visual complexity.


Home's focus is almost entirely on its narrative. Did you ever envision having more other mechanics, like combat, at play? If so, what steered you towards its finished form instead?

Initial sketches were much more traditional, yes--I had monsters skittering away from the flashlight beam, and things like that. But as soon as I reviewed these ideas, I realized I didn't want to make a shoot-the-monsters game. Sure, it's much harder to do so, but that wasn't my only concern; I just thought there was a better opportunity that hadn't been explored yet.


I noticed by way of your website and Wikipedia page that you've produced a long list of graphic novels as well as games, which makes me think visual and narrative art are closely linked for you. What do you like/dislike about working with both of those at the same time?

Yes, I routinely bounce back and forth, to keep me interested. I like hopping back into comics because it means less time in front of the computer, which I sorely need. But making games is a much more realistic business. :-) Comics are a really expensive hobby for me right now.


How do you feel Home compares to other games focused on choice in narrative? Did you set out trying to emulate or improve on anything specific that another game had done?
The creation of Home and its narrative style was really simple. I know a lot of folks like to put words in my mouth about why I did what I did--because I am a shitty artist, or a lazy programmer, or totally full of myself, etc.--but the reasoning was simple. I just look at games that I like and kind of feel them out--would I want to make a Silent Hill game? No, I'm not interested in a shoot-the-monsters scenario. Would I want to make a classic adventure game? No, they're too clunky with too many elements that get in the way of personal storytelling (inventories, cutscenes, etc.). I do think Home is pretty unique--I really don't know of another game that handles its narrative quite the way that it does, though I can think of a lot--Metal Gear Solid, Silent Hill 2, etc.--that all contain elements of game-based narrative from which I drew inspiration. So I didn't try to emulate anything, but rather feel my way around until I found what felt right for me, personally--what was the game I wanted to play up until now, but wasn't available.


Without presuming to know a lot about the technology that went into Home, it seems like the sort of thing that could have been implemented many years ago, but to my knowledge no game quite like it really exists. Do you think it would have been possible to make a game like Home five or ten years ago? Why do you think it took so long for a game like this to emerge?

I think someone with better programming skills than me (i.e. everyone) could have certainly pulled something like this off. But the goal of my company and personal ethos isn't to focus on tech, but to create games that (hopefully) don't exist yet, and give people an experience that maybe they've been thinking about for some time. Perhaps Home couldn't have existed 10 years ago, because I wasn't as disinterested in certain genres or series back then--or my exposure to them wasn't there yet. So no, I think it is a product of its time--certainly because the tools I had to create the game are only available now, really.


Gaming is still a pretty young medium. What direction do you see it taking in the next few years?

That's a big question! I see the big games getting bigger and more lost, the indie games gaining much more traction as new, unique endeavours become their domain, and those wonderful middle-of-the-road titles being gutted altogether. I wouldn't even blink if there was a severe market crash or implosion, with budgets being what they are, companies living and dying off single titles and franchises, and studios closing left and right. In a weird way, I feel it might get worse before it gets better.


Where do you want to take your own game development next? What ideas do you see working on?

Oh, I'm afraid I can't say much about that! I haven't prototyped anything new yet--Home is very much still an ongoing thing--but I have some concepts stewing in my brain that I intend to check in on in a few months. I would love to do something more modern and 3D with Unity, which I'm looking into now, but that feels like an epic climb, and I've just put on my boots.


What are a few of your favorite games, books, and/or movies, recent or ever? I'd like to know not just what inspired you for Home or as a developer, but what inspires you in general.
I can say concisely that major influences on everything I do or create, which includes Home, are: Silent Hill 2 (obvious), the book House of Leaves, and quiet, emotional drama films (I can't even think of any right now!). But that's not to try to make me sound smart--these days I read a lot of trashy 90s comic reprints for yuks.
:-)


So there you have it! If you want to know more about Benjamin, you can out lots on his website:
http://www.benjaminrivers.com/
And I have also enjoyed his Twitter:
https://twitter.com/BenjaminRivers
Definitely look at his games and stories if you haven't. I quite enjoyed Home (and I've got a review up), and in general Benjamin has great ideas about narrative that are readily apparent in his artwork - so go check it out!

How Do We Talk About Games?

Something I've seen come up in a number of places recently is the question of what the best way to talk about games is. This is a question that takes a lot of forms depending on the scope of the conversation. One group of people might be focusing on the language that exists around game development and consumption, the words for particular techniques employed by developers or for particular styles of play. Another group of people might be questioning whether games are art at all, and whether they have the same merit as other media considered art, like film and written fiction. And still another group might be so convinced of video games as a frivolous pastime that the concept of games as an artform, or as being complex enough to need their own lexicon, might seem really bizarre. So, rephrased, the question is: how do we want to talk about games? If you've read any of my other posts and are choosing to read this one, I'm going to guess that your appreciation for games is such that you're at least comfortable with the idea of them being artistic, or at least requiring complex and artful construction, so this post will mostly be aimed at you folk. If you don't think you match that description, though, I hope you'll keep reading anyway, and maybe get a sense of how people who immerse themselves in the gaming culture, industry, and experience see those things.

Why we think of games as art is its own post at least, so I'll slide over it for now. Suffice to say, we find that occasionally a game comes along that evokes emotion in us that feels authentic, that shows us a perspective that's new to us. This is a crappy definition of "art," but it's a reasonable criterion for good art. Like all art, then, we try to explore the boundaries between two things: what we can communicate about both the technique and experience of art (for the sake of better producing/experiencing it), and what is beautiful to us because it is not communicable, because we can only experience it through the medium. We want to talk about how to make good games, but if we could get the experience of the game by talking about it, we'd never have to make them. This is why good writers read a lot of books and good filmmakers watch a lot of movies: part of what's great about the medium is what we don't know how to describe.

But the post about "why games are art" will fumble with what we can't say. This post is for fumbling with what we can say.

Video games, like other media, require formula and precision. The tools of our craft aren't really comparable with those of other media, however. If an author wants to adjust pace, he can change the length of sentences, choose words that flow together, cut dialogue. A filmmaker can examine where his cuts are and which scenes can be combined, expanded, or removed. A game maker may have to do similar things, but also needs to adjust game balance and difficulty, must tune puzzles so that they remain enjoyably complex without slowing things down, change up their level design so that new areas are interesting, must adjust a monster's difficulty so that they seem legitimately scary but don't frustrate the player by killing her constantly. As I've just demonstrated, games already have some language particular to them; balance, level design, and difficulty are all established terms with a particular meaning for game developers and players. And as I've just demonstrated, a language particular to games is necessary because there are a lot of concepts particular to games, like these. If you compare the language to film to that of novels, you'll find similarities simply because they're both vehicles for narrative, but you'll also find a lot of differences because movies can do things books can't (and of course, vice versa). If you're going to have meaningful conversations about movies, you'll need to have some words and phrases that mean something particular to the medium. So, too, with video games.

So then the question is: why do we want to talk about games like this? And the answer is really about quality. If we want to have higher quality games - whether that's higher quality visuals, design, play, story, execution - we need to be able to talk about them, we need our own language, and theory, and criticism. Ours is a very complicated medium. We have a lot of rules about narrative to obey, and many more to learn if we want to tell really compelling stories. We have rules about how character's abilities interact with one another. We have code. We have bug testing. We have to account for an audience whose personal skill at our kind of game affects whether they enjoy the experience, or even encounter all of it. We have a lot of rules about balance and pacing and level design, and even if they're not written in stone, they are (much like rules of film or writing) essential to know if you want to experiment in a meaningful way. The better able we are to communicate about these things, the firmer the foundation of the medium will be - developers will have more to work with, and gamers will be better able to think critically about what they're playing.

This may come off as kind of elitist, but it isn't meant to be.  A lot of movies, books, and games are pretty frivolous, and their creators didn't intend them to be particularly deep, and that's fine. Great, even; sometimes I don't want a complicated narrative, I just want something to occupy my attention and help me zone out a little. But for those of us who have genuinely felt moved by a game, that won't be enough all the time. Without that language to communicate about and refine our games, without being able to talk with one another (as well as storytellers of other kinds!), we're not going to find that spark. Sometimes, somebody jots something down in a notebook without thinking about it too hard or ever revising it, and it's brilliant. But talk to most writers or artists of any kind and they'll tell you that more often, success comes from studying what works well, alone and with others, and using that as a starting point for experimentation. The more we pursue a language that lets us do that, the better our games will be.

Managing Complexity

As we introduce more mechanics into the game we're working on, a danger we're continuously up against is unnecessary complexity. When I described to a new person on the project the extent of some of our plans for mechanics and art, she was surprised and a little skeptical to hear about the potential complexity of the game, and worried that the abilities we were thinking of implementing would distract, confuse, or overwhelm the players. The danger of having too much in a game is always looming, but I can think of a great many other games that somehow managed a great deal more complexity than what we're planning. So, in the interest of considering ways to manage our own complexity I thought I'd investigate some of the tactics used by other games to keep them from becoming too cumbersome to be fun.

Have a good curve
This is basic but worth mentioning. Pacing must be kept carefully with new mechanics to ensure the player has time to grasp the mechanic and grow comfortable with it before being asked to use it in more complicated ways. In games that offer players a lot of different abilities - think Banjo-Kazooie - these are often unlocked one at a time, with more and more available later in the game.

Otherwise, people might get confused by something like this.

Counter to this, games like Super Mario 64 gave players most of their abilities up-front, and taught them how to use them as needed. So even if you don't get how to wall jump right at the beginning of the game, you'll have time before they ask you to use it to beat a level - and even if you can't figure it out then, you can always come back to it when it makes more sense. If your game is going to have a lot of abilities, it helps to isolate mastery of them in different spaces of the game so players are aware of them as available tools and can identify the appropriate one when the time comes. Which leads into our next topic...

Cues

If you've played a 3d Zelda game, this probably looks familiar:

Take a moment to appreciate how ordinary this looks for how weird it is.

That object Link's using is called a Clawshot (Hookshot in earlier games) and that thing he's launching it at is a target. When the Clawshot hits the target, it'll pull Link to it. That is what those targets are for. That is the only thing those targets are for. And when Link needs to use the Clawshot, you'd best believe something somewhere is going to look like one of those targets. Even if you're supposed to hit an enemy with it, chances are the part of the enemy you're supposed to hit will, somehow, look a little like that. Similarly, in Super Metroid:

ok maybe I play too much nintendo

The pink things on either side of the screen are doors, and they will open when you shoot missiles at them. Green doors, super missiles. Orange doors, power bombs. Blue doors, any weapon. The game teaches you early on what kind of weapon you need to access these spaces, and then sticks with it. So when you get your first set of power bombs and blast open your first orange door, you might think "Oh, I remember seeing an orange door awhile back. Now that I can get in, maybe I should go back there." That's critical, especially in a nonlinear game; without that cue, the player might get power bombs and not have a very clear idea of where to go next. Even if exploring a certain area of Super Metroid doesn't reveal where to go next, it does fill in a mental map full of cues that will help you later when you understand how to bypass those obstacles. (These are also great sometimes for making a game feel bigger than it is; when you get the magic ability to bypass these obstacles, you might have inexact memories of where the obstacles are and that can give you the feeling that there's still more to explore). These kinds of cues are really important to help keep players from getting frustrated, so they don't get stuck wondering which of their abilities will work on an obstacle, or with a new ability but no idea where to use it. And when "cue" becomes "necessary counterpart," we have...

Situationally-useful abilities
Late in Twilight Princess, Link gets a staff capable of controlling big statues and moving them around. They have to be a specific kind of statue (statues with a hole in the chest are our "cue"), and they can't jump, so they're bounded near their starting point by terrain. This tool is only useful for controlling these statues; it has no effect, of any kind, on anything else, and no other tool can be used to interact with these statues. In this case, the item is situationally-useful; it is specifically restricted to only one kind of use. Combined with cues, figuring out which tool to use is no longer part of the puzzle; the puzzle is figuring out how to use each tool effectively. This is also how games like Braid divide up types of puzzles; some mechanics, like the shadow copy of Tim or the time-slowing ring, only appear in certain areas. The game allows for variety by having these mechanics, but only applies them in certain situations, so the player isn't confused about which mechanic to use.

Redundancy
At first glance the idea of redundant mechanics may seem like a design flaw, and in some cases it is. Sticking with Zelda, though, think of how enemies work in Skyward Sword. For the most part, they require more sophistication than simply smashing them with your sword, but often there are several different ways to combat them. For example, a Beamos can be defeated by using horizontal slashes to cut it down to your size before stabbing it in the eye - but it can also be killed with a well-timed (and well-aimed) arrow to the eye. When you encounter several of these enemies over the course of the game, it adds to the fun to be able to mix up how you deal with them. Moreover, the arrow strategy is a little easier and safer, but you get the bow long after encountering your first Beamos, and when you do it's a nice upgrade for dealing with this kind of enemy. Redundancy is most common for combat purposes; you have a few different abilities, and one might be more efficient than the others for taking out your foe, but it doesn't really matter which one you use. There's no hard and fast limit to the places where you can offer players multiple solutions to a single problem. You could do this in a puzzle game (though at the risk of reducing the difficulty of the puzzles), and it's common to see it in RPGs, where it might be possible either to fight or talk your way out of a dangerous situation.  Redundancy either requires careful balance of all the available options or demands that newer, better options render old ones obsolete, and so must be used carefully. When implemented well, however, it can give players a sense of accomplishment when they acquire a new tool that renders old challenges much easier, or give them a sense of ownership of the story when they can solve problems on terms of their choosing.

There are a lot of great games that have few mechanics and never give the players new abilities; simplicity is a beautiful thing, and some games would have their elegance diminished by overcomplicating the mechanics. But variety can be fun, and it's neat as a player to see that you have a lot of options or that you gain new skills over time. A good way to summarize the points I talked about might be to ask of any mechanic:

When was this mechanic introduced?
What lets me know I should use this ability/mechanic?
Are there places where I'm forced to use this ability, or where this ability does not work?
Can this ability complement, be used instead of, or replace altogether another ability?

Hopefully the above will give you something to think on next time you get a cool new toy in a game, or the next time you're thinking about implementing one in your own game.