During Steam's massive Christmas holiday sale, Mass Effect 1 and 2 were offered for $5 each. I thought to myself "Awesome, I am totally going to buy these when I get home!" and then I quite unfortunately promptly forgot. Thankfully, you can now get both games for $6 each (this week only) on Amazon. I am currently about 3hrs into the first Mass Effect, so still quite a ways off from the ending controversy that seems to be all the buzz these days. What does this have to do with anything? Let's get down to it.
During my brief time with Mass Effect (and also recently, Fallout 3), I noticed myself doing something very intentionally contrary to what the designers hoped I would do. I was presented with tutorial text and even tutorial sections as I went throughout the game that only served to annoy me, rather than actually help me to learn anything about the game. Not that these sections were bad, or even lacking vital information - Fallout 3's opening sequence with your character growing up in the vault is very well constructed, but there is just something about tutorial text and the sequences that explain to the player how to do a thing, ask them to do it, and then congratulate them for doing it that just pushes my buttons. Consequently, I vehemently ignore these sequences then later on find myself asking “Now how do I do that one thing again?”
Why is this? After taking some time to think about it, I realized that this manner of instructing the player is not conducive to natural learning. During our school years, we are given "tutorial text," asked to regurgitate the things we just read, and then congratulated for doing so; a process of memorization that is generally only successful if the person involved is actually interested in learning what you have to say. 5 minutes into a game I am not interested in learning to play the game, I just want to play it. "But that's contradictory, you can't play without knowing how to play!" one might say. This is only partially true. Think back to a time when you were a child. Was there a tutorial section on how to spin the merry-go-round? When you were learning to cross the monkey bars, did text rain down from the heavens to say "Be sure to put one arm in front of the other, you'll fall if you let go with both hands!" I'd be willing to bet there's a good chance this did not occur for you.
The more likely scenario is that you touched the merry-go-round and realized that it moved, which prompted you to move it faster, as natural curiosity would have you do. You saw the monkey bars as a challenge and, after falling once or twice, realized that gravity is not your friend and you should fight it by holding on with one hand while reaching with the other. Sure, there are many skills that generally aren't learned in total absence of teaching, but to be the most effective, the learner must be actively involved in learning the skill (kicking on a paddleboard while learning to swim, shooting a basketball, etc), and there is generally much more power in showing the learner how to do something, rather than telling them.
How do we apply this to games, an activity that is very technical by nature? Surely, games in all of their complexity need copious amounts of tutorials if the player has any hope of achieving anything, right? Well, no, not really. There are 2 factors at play which create the perceived notion that the player must have everything explained to them every step of the way. The first is the modern input method. Rewind time 25 or so years and the most prevalent inputdevice in console gaming was the NES controller, king of simple and effective interfaces. It had directional input, one set of "active" buttons (A and B), and one set of buttons to forget about most of the time (select and start). If someone were handed one of these controllers, the amount of time for which they'd be confused as to what the buttons do would be relatively short, as there's generally only 2 buttons that actively do anything in game (excluding the start button, which tends to pause things), and the d-pad automatically denotes movement of some sort, so much so that even TV remotes have them.
Fast forward to modern gaming and you will see that the standard XBOX 360 and PS3 controllers have 13 buttons on them, 10 of which are "active" buttons, along with 3 directional inputs. This is indeed a huge hurdle for most people, but assuming that they are willing to even pick up one of these monstrosities, there are a couple of assumptions you can make as a designer. First is an assumption about your audience in general. Either they've never touched a controller before, which we'll get into in a moment, or they are well versed with the controller, in which case you have little to teach them. In the case of someone who has never picked up a controller, unless you've done something strange with your use of the directional inputs, you can assume your player will figure out how to achieve basic movement. They will not be adept at it, they will not immediately be capable of navigating that obstacle course you have planned 5 hrs in, but with the directional inputs being the largest buttons on the controller, you can be assured that the user will play with them enough to figure out basic movement. Where this uninitiated user gets into trouble is with the rest of the buttons. “What do I press? I don’t want to press the wrong buttons, there so many of them” commonly stops the lay-user from further progressing in your game. So what does the developer do? At best, they put up context-sensitive markers on screen as you go from place to place, a giant “press this button now” prompt, if you will. At worst, they toss up one of these:
If you are guilty of the latter, I will quote Ernest Adams: “Bad Game Designer, No Twinkie!” The solution to this problem, however, is not a trivial one. For the players who are accustomed to gaming and using a controller, they will press all of the buttons anyway, just to get a feel for what’s what and map it to their preconceived notion of how your genre of game should function. For the newcomer-gamer, you now have a challenge to surmount that exists purely on the basis of the platform you decided to develop for.
Surmounting this problem moves directly into factor #2 for why we feel that it is an imperative to explain everything to the player at every step: Every button does something unique. As developers, we have subconsciously given in to the notion that every button on a controller must be utilized for some action, which actually hinders us from taking a step back and thinking about how to simplify the control scheme to create a flow that only needs to be played to be learned, rather than memorized and practiced. Take a journey back to 1991 and look at the original Sonic the Hedgehog for the Sega Genesis. The Genesis controller had a directional input, 3 active buttons and a start button. The directional input does what you would expect, so we can ignore that. What do the buttons do? A causes sonic to jump. B causes sonic to jump. C causes sonic to jump. The designers did not feel the need to increase the number and types of actions sonic can perform to accommodate the controller. A doesn’t do a small jump while C does a large jump. The designers said “Our character needs to be able to jump and that’s it, make it so there’s no wrong button to accomplish this.”
Given Sonic’s limited vocabulary, this example may be a bit trivial. Let’s step back 1 year into what I deem to be one of the most difficult NES games I have ever played: Double Dragon III. The NES setup, you’ll recall, is one directional input, 2 active buttons, as well as a start and a select button. The action vocabulary for this game, however, is much more expansive. Your immediate goal is to fight any and everyone who crosses your path. Both active buttons accomplish this goal, one allowing you to punch, one allowing you to kick. Sometime during the beginning of the game, you will witness an enemy jump at which point you will ask yourself “How do I do that? There’s only two buttons, and I have already explored what they do separately, why not press them together? Whoa!” With this limited button configuration where every button accomplishes the player’s goal in some way or another, and given time to play with them, eventually the player learns to punch, kick, grab, jump, cyclone kick, mid-air somersault, use a buddy for a flying jump kick, and use a weapon.
There are two major points to grasp from this. The first is that every button accomplishes the player’s current goal. There is no “wrong button.” New-comers to gaming need only to press any button to progress. The second is that through allowing the player to play with a small set of inputs, they will naturally explore and combine them in ways the developer can use to their advantage, offering them new moves or cool rewards for realizing that you can indeed press A and B together at the same time. I imaging that if Double Dragon III were created on the XBOX 360, there would be a button to punch, a button to kick, a button to jump, a button to grab, a button for “special moves,” a button for the buddy flying kick, and possibly a button to toss a weapon for good measure. While, if you have memorized this, it could very well serve to make it easier to perform these tasks, we have increased the button count from 2 to 7, and simply exploring buttons no longer causes everything you press to have an obvious and useful action. In other words, we have greatly increased the barrier to entry without changing the game’s mechanics, even though we simplified what needed to be pressed to perform the same actions!
So what can we do, given that we can’t force (nor do we want to force) people to play their XBOX 360 with an NES/Genesis controller, and people are not so prone to explore when the button count increases? If the game mechanics are simple enough, it is possible to take the Sonic approach, mapping every button to the same action. As less extreme examples, there are Earthbound and Dragon Quest VIII, both of which are fully featured RPGs playable with one hand via the dpad and L-Button. Smash Brothers does an excellent job, making the game essentially playable with two buttons and the dpad. Aside from that, consider if you really need to use every button on the controller, or if creating a seemingly more complicated control scheme through the use of fewer buttons actually helps to encourage users to discover how to play your game, rather than needing to be explicitly told.
There is a lot more I would love to cover, but I am both out of space and out of time, so I will have to leave it at this until next time. In the meantime, think of ways you can reduce the ability for a user to press a “wrong button” by simplifying your control scheme, rather than putting up a horrible controller configuration image which will simply be ignored by the hardcore and scare off the uninitiated. As always, I would love to hear what you have to add to this conversation, so leave me a message in the comments!
Wednesday, March 28, 2012
Saturday, March 3, 2012
SlickEdit (Or, Time for A Commercial Break)
I have more and more run into the need to work in various development environments lately, mainly going back and forth between Windows coupled with Visual Studio and various flavors of Unix with GCC or MinGW coupled with various text editors. On the Windows side, things are great. I will admit complete and total bias when it comes to using Visual Studio with Visual Assist. Nothing beats that combination for developing a C++ application, hands down. On the Unix side, however, I have been searching for a way to simplify my workflow and remove the need to work so heavily through the command line. Sure, the command line is more powerful than any user-friendly GUI will be without a heavy amount of tweaking and menus, but 99.5% of the time I don't need the power of the command line, I want the ease of use speed of an IDE that will let me drag and drop things, press a button to compile, another button to run, and click in some breakpoints here and there.
A few days ago, my prayers were seemingly answered in the form of SlickEdit. It very easily lets me set up to use my pre-existing makefiles to build everything, while also offering the ability to have my workspace visually set up, allowing me to navigate through files easily and debug my applications in a visual interface, rather than through GDB command line. I haven't had a chance to fully go through SlickEdit's feature set yet, but I can say that I have seen enough to recommend it if you find yourself in a similar situation. I don't normally outright advertise a product here, but for this one, I will. Go get it here. If you're one of those people who like to know all the ins and outs of your tools, pick up the book here.
A few days ago, my prayers were seemingly answered in the form of SlickEdit. It very easily lets me set up to use my pre-existing makefiles to build everything, while also offering the ability to have my workspace visually set up, allowing me to navigate through files easily and debug my applications in a visual interface, rather than through GDB command line. I haven't had a chance to fully go through SlickEdit's feature set yet, but I can say that I have seen enough to recommend it if you find yourself in a similar situation. I don't normally outright advertise a product here, but for this one, I will. Go get it here. If you're one of those people who like to know all the ins and outs of your tools, pick up the book here.
Subscribe to:
Posts (Atom)