Simple Complexity (Or, Do I Really Have to Learn This?)

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!

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.

Sick Day

It seems I was a bit incapacitated this week, so rather than a rant, here is something you may not have seen. At GDC in 2004, Pete Isensee outlined several common areas of performance loss in games found after analyzing the source of many titles for the XBOX. Whether or not you deem yourself to be an optimization guru and master of C++, this presentation is still very much worth your time. Check out his presentation here, get the slides here.

Best-Selling Games vs Best-Made Games (Or, Reaching A Larger Audience)

Recently I had a chance to reread Robert Kiyosaki's book Rich Dad Poor Dad. In it there is a section where he discusses an interview he had with a young journalist who expresses her desire to become a best-selling author like him. Kiyosaki tells her that her writing is excellent, tough and clear, and asks her what is holding her back from achieving her dream. Quietly she responds: "My work doesn't seem to go anywhere. Everyone says my novels are excellent, but nothing happens. So I keep my job with the paper. At least it pays the bills." When she asks Kiyosaki for suggestions on getting her work to be more noticed, he gives her what is retrospectively almost an obvious answer: "Learn to become a salesman." Indignant at the thought of "stooping so low" as to learn to be a salesman, she begins to pack her things and begins to leave. Kiyosaki stops her momentarily and points out that the article she's written on him says "Best-selling Author." He tells her that her ability to write is far beyond his. He says that she is a great writer, he is not. He points out that difference between them is that he is a great salesman, she is not. (Click here for the full excerpt)

Hopefully by now you are starting to connect what a book about business and finance and the game industry have to do with one another. How many times have you seen a best-selling title and thought "I can make something far better than this, why is it that their game is so popular?" How many times have you thought: "This game is so poorly made, all this company must care about is the bottom line!" I'm pretty sure the latter of these two statements is not completely true in most cases, but the simple answer is that the companies pushing these titles are better at selling than everyone else.

We all know at a basic level that marketing and salesmanship is important for getting your game to be noticed by the masses. We are no longer in the early days of gaming where simply making a great game was enough to boost you to superstardom. "If you build it they will come" is a great ideal, but it is no longer the reality of the industry we are in. Unless you know how to sell, how to capitalize on your game ideas, the chances of your developing that mega-hit that brings you fame and fortune are very slim. Let me be clear, I am not saying that we should sacrifice the quality of our games and focus on putting trash out there. No, I am saying that we as game developers need to make sure that we've added the tool of salesmanship to our game development tool-belt.

A couple weeks ago, there was a feature here on Gamasutra by Jeff Vogel in which he details the method by which he makes money doing what he loves. His message initially seemed to be about catering to a particular niche of gamer, or what kind of games to make if you want to make money. As you progress through the article thinking in terms of "Best Selling vs Best Made," you will notice, however, that he's actually discussing how to sell your game. This is a man who has figured out how to take something that is seemingly not popular and get it into the hands of the masses well enough that he can continue to do what he loves for a living. This is suggested reading if you have a few spare moments.

Around the same time, Tyler York also released an article about selling your games. Specifically, they speak to balancing your game's content and style with the monetization thereof. This is a fairly short read, but they hit upon a few key points, and in particular one what was also made by Mr. Vogel: "Sell experiences." Meaning that, as game developers we are not so much in the business of selling things as we are of selling experiences. Our product is adventure, entertainment, drama, social connection. The actual content of our product is the means whereby we accomplish this, but a 20,000 page Tolkien-esque epic means nothing if the user-experience is not first and foremost in your design.

Finally, Wojtek Kawczynski gives us lessons learned as he and his studio released two iOS titles: Garage Inc. and KULA BLOX. Primarily these lessons pertain to marketing on the app store, but the spirit behind the message is applicable to selling your products anywhere. Keep your marketing short and sweet and your message clear.

Summarily, the ability to sell is equally as important as the ability to make a great game, assuming that you'd actually like people to know about and appreciate your game. It would be of great worth to all of us to take time out of our busy schedule creating great games to become at least half as good at selling our games. Such is my take on the matter, anyway. I'd love to hear thoughts anyone else may have on the topic, so leave me a comment!

Making Small, Big (Or, The World Is A Character Too!)

Over the Christmas holiday I finally sat down and went through a few of the games in my backlog. Among them were Radiant Historia and Bastion, two excellent games that everyone should take the time to experience. Both of these titles make the attempt to get the player engaged with and attached to the world they present, though they do it in somewhat different ways. This focus on player engagement with a world got me to thinking about various games I have become attached to over the years, and the difference between creating large worlds, and worlds that feel large.

I will preface this conversation by stating that the opinions offered hereafter apply mainly to games in which story and engagement with the world is a primary factor in game-play. I am a fan of other, more action-oriented titles, but this conversation is not for them.

Long ago, in a land far away, there used to be these mystical collections of writings which people commonly referred to as “books.” Many of these books contained tales of worlds as far and wide as one’s imagination, but due to the limitation of the medium, being that you can only describe so much at any one time in a coherent manner using words, these books generally focused the reader on a small subset of the world, commonly revisiting locations presented earlier in the story. Through clever use of dialog and other narrative techniques, these books were able to create in the reader’s mind a world that was much, much larger than what was actually penned by the author, while bringing the reader to fall in love with the locations that were purposefully designed.

In the earlier generations of gaming, specifically the 80’s and 90’s we had such classics as Monkey Island, Maniac Mansion, the early Final Fantasy titles, Chrono Trigger, The Longest Journey, the list goes on and on. All of these titles were released at a time when there were pretty strict limits on both what content and how much content you could stuff into a single experience. To compensate, the developers were forced to reuse assets and locations, and to center a story around a small subset of the larger world they would have otherwise liked to create. Ever since, as technology advances, we have been trying ever harder to create larger and larger, more expansive and detailed worlds for players to become immersed in. Not that I think this is in and of itself a bad thing, but I’d like to posit that maybe it is not actually the correct direction for getting players immersed and interested in your world.

I like to think of the locations in a game in the same way one might think of its supporting characters. The more time one spends with a specific character, the more one becomes attached to that character, their history, and what happens to them. It also gives the designer a chance to introduce the true characteristics of the character, or in this case, the world. Rather than appearing large and intricate, it gets the chance to actually feel large and intricate. This is an important distinction. Creating a world that is large is not the same as creating a world that feels large, and yet, one of these takes much more effort on the part of your artists and other talent.

It is no secret that two of my favorite games are Ragnar Tørnquist’s The Longest Journey and Dreamfall. In these games, Tørnquist presents a world, or set of worlds, technically, that are both massive and sprawling in terms of how they feel. These games, however, physically present a very small subset of the world. The Longest Journey, or TLJ, effectively took place in 9 areas: Newport, Marcuria, the Banda village, Roper Klacks’ castle, the Maerum village, the Alatian island, the space station, the Guardian’s Realm, and the area in which you start the game, which I won’t name to avoid spoilers. Each of these places had somewhere around 3-5 subsections, things such as the inside of a house or another part of a village, but ultimately, the entire game centered around these 9 places, which were not very large themselves (with maybe the exception of Newport, since travel was done via subway).

Having such a limited selection of locales worked greatly to this game’s favor. The player spends the first several hours of the game becoming familiar with Newport, with its people, its culture, and the general lore of the world before you are suddenly shifted to the next area (pun totally intended). The amount of time the player spends in this area gives them time to bond with it, to feel like they have mastered its ins and outs, and to feel like it is a “home base” of sorts. Once ripped from it, the player experiences the exact bewildered and slightly curious feeling the designer intended. They have become familiar with the intricacies of “home,” but now there’s a new and potentially dangerous place to explore. If the game had been about exploring area after area all along, this transition would lose a large part of what makes it special.

With few exceptions, the game continues in this manner, giving the player a chance to familiarize themselves deeply with each area before pulling them away, occasionally back to an area they’ve already seen. In the instances in which the player is returned to an area they’ve already seen, they are expected to have already become so familiar with the area that they can connect the plot points without a big “Megaman Megaman, there’s a thing!” explanation (warning -- language).

By including the world as a character in the story, a designer embeds not just memories of the characters and events in the player's mind, but also memories of the experience. Done correctly, a player will look back on the game and think "I want more stories to take place here." By focusing on specific parts of the world while alluding to larger things, the designer is able to get the player to feel more like they are going on an adventure as they are shown more of the world little by little.

On the other hand, creating a world that literally is immense is a risky proposition. It requires much, much more in the way of content to get a player to stay in one area long enough to come to appreciate it. Adventuring is much like eating cookies, an awesome snack in-between meals, but if all you find yourself doing is running from one place to the next, the adventure-cookies start to become much less awesome. Gorgeous vistas are great, but more so when you have a reason to appreciate them, rather than just running into them as you go from Town #631 to Town #765. I think you will find that even (good) games which literally have large, expansive worlds tend to focus on smaller sections, essentially marrying the concept of making the world feel large with making the world actually be large.

Done improperly, a world that actually is large but is merely a placeholder for the content therein tends to feel empty, and much smaller than it actually is. I am sure we have all played games with huge areas between plot-points that are essentially nothing but the terrain-engine writer's desire to show off their work. The games themselves contain the same amount of content as a much smaller game, spread over a much larger area, and result in feeling like there is less to the world than if they had simply created a smaller world. I have seen many titles fall into this trap, and I have been guilty of it myself.

In summation, your game world is going to exist, use it. If getting your player properly acquainted with your world and telling your 90hr epic tale is not going to fit in your budget and schedule for a single game, it is better that you condense everything into a well-crafted-but-smaller package than attempt to speed the player through your world so that they can experience all the content you want to show them. Just my two cents. Let me know what you think in the comments section.

I'm Back!

Apparently "soon" is a relative term. The reason I have been gone so long is that I just finished up work on the recently released Nintendo Zone app included with the December 3DS update. I guess that gives away where the new job is! Things are going pretty well and life is beginning to settle down into a regular pattern, so I'm going to give this blogging thing another go. See you all tomorrow!