The Difference Between the New Kirby and Mario Games

I've spent about five hours with Super Mario 3D Land, and I'd like to explain what makes it so great so far, especially in comparison to the drab Kirby's Return To Dreamland. In order to do so, we're going to look back at this article.
If you haven't read it, here's the theory I put forth. In every game, there need to be three things in order to make the game work well:

1. Good controls.
2. Challenging yet attainable goal achievement.
3. Anticipation of what comes next.

That's the holy triumvirate of game design. If the game is missing all three, it's awful. If a game has one out of three, it's bland. If it has two out of three, it's OK. If it has all three, it's fantastic.

Kirby's Return to Dreamland had solid controls, and that was about it. Beating levels was easy, and the supposed "secrets" were painfully easy to find. There was minor anticipation, since you knew you weren't going to find more special powers as you played. That made Kirby's Return to Dreamland bland.

Super Mario 3D Land, on the other hand, has phenomenal controls. It's challenging yet fair. Every level is slightly different or has something you didn't expect to see, including the remixed special levels that you get to play after you've beaten the first quest.

In essence, everything that you could want from a platformer is in Super Mario 3D Land. That's the difference between an OK game and a great game. Good job, Nintendo.

Game Design: Bad Ideas

We always remember things as being better than they actually were.

I say this because I'm currently playing 10 NES games as provided to me by Nintendo on my 3DS. NES games are usually viewed as being totally awesome, and if you mention that maybe some of these games weren't maybe very good, you run the risk of angering people.


The argument is that these games were good for their time and helped lay the foundation for modern gaming, and that's correct. The danger isn't in recognizing them for what they were, but rather believing that old games are some sort of end-all-be-all and that gaming was somehow better back in the NES days than it is now.

It's a mistake to think so. A lot of the design decisions that are hailed now were only placed there because of system limitations or due to erroneous assumptions about what video games were all about. We're going to go through some design decisions from time to time that were bad ideas then and bad ideas now, and only have managed to stay in gaming because of misguided nostalgia.

The first mistake is evidenced by Super Mario Bros. If you lose all of your lives in Super Mario Bros., what happens? Do you get to restart at the last level you died in? If you die in 8-2, can you restart in 8-1? No, you restart from the beginning of the game, level 1-1.

You may say, "Well, of course! It wouldn't be Super Mario Bros. without that! Gaming shouldn't be about about completing the game, it should be about improving your skills and getting to the point where you can complete it!"

If you say that, you're wrong.

Gaming was born in the arcades. Early designers were tasked not only with making fun games, but also ones that would gobble coins. Pacman, Space Invaders, Gauntlet and Donkey Kong were all about taking your money as quickly and as often as possible. In order to get good at an arcade game, you had to spend lots and lots of money until you could finally get to the point where you didn't have to spend that much money.

That means that you don't want players to restart from the last level they died on. You're giving away your livelihood if you do so. You'll also make a lot of other design decisions that are ridiculous for precisely those reasons, but we'll get to those at a different time.

A lot of developers who came from that background (read: all of them at the time) carried over that philosophy from the arcades. Miyamoto designed arcade games, for example. Therefore, instead of making the game easier to complete, they made it harder to finish precisely because that's the philosophy and experience that they had.

Was it the right choice for Super Mario Bros.? Yeah, it was the right choice because Super Mario Bros. is a rather short game. If you're good, you can finish it in 10 minutes, and if you're really good you can finish it in 5. If you could have started the game over at level 8-1, you probably would have finished it almost immediately, even back when you were 10 years old.

However, is it the right choice for other games of its type? No.

Let's use the example of Zelda II: The Adventure of Link. If you lose all three of your lives, instead of starting you out at, say, the beginning of the dungeon that you died in, you restart the game at the very beginning. That means you have to traverse open fields, dangerous caves and lots of hostile environments all just to get back to the last place you died.

Does that force you to get better at the game? Yeah, sure. Does it make you want to keep playing? Of course not.

Imagine playing for two hours, dying, and then having to struggle all the way back to where you died, then dying again and having to get back to the same place. If you're nodding your head and saying, "Yeah, what's the big deal?" then you're part of the problem.

It's easy to forget that you played this type of game when you were a kid. You had a lot of time on your hands, so losing several hours of progress was not a big deal. If you still have that much time on your hands years later, you're probably not doing so hot in life, frankly. Get a job.

For the rest of us, we simply don't have time to waste. My gaming time is sometimes broken down into 15-minute chunks when I have space to breathe. Do I want to waste that time? Heck no! It's too precious to lose!

It didn't take long for game makers to learn that lesson, but some gamers still pine for the days when they had to restart games from the beginning when they lost. Listen, designers only did that to screw you over. It was a bad idea then, and it's a bad idea now.

Let's Make A Game! Episode 3

I was going to try and explain what I know about programming, but it's complicated stuff. Anything I spit out here would sound like the ramblings of an above-average seven-year-old, so I'm just going to stick to what I know.


Instead, we're going to work off of XNA tutorials to learn the underpinnings of the language itself. Microsoft's site doesn't reveal tutorials unless you really go digging, but I finally found one that's been EXTREMELY helpful. Here's a link if you want to follow along with me.

The idea behind this tutorial is to give us all a better idea of how to build a simple game while walking alongside us with the code. We'll try and follow along.

I hope we're all familiar with the idea of a "variable." In case you're not, a variable is a value that can change over the course of our program. For example, let's take a video game character like Cloud Strife. When he starts out the game, he may have 200 hit points. Over time, that number can change. It can go up, down, or do whatever within certain limits. That's a variable.

There are couple main types of variables that we'll use: integers, Boolean expressions, vectors and textures. Cloud's hit points are an integer, or a whole number.

A boolean expression is something that's either true or false. For example, when Cloud has one or more hit points, he's alive. When he has zero hit points, he's dead. That's a boolean value.

Vectors are the location of an item in 2D or 3D space, and textures are what any given tile will look like, as far as I know. I could be way off on those definitions.

So, if we want to declare a variable, the tutorial suggests that we do something like this:

public int Health;

What I've done here is said that this variable is going to be an integer (or "int"). We're naming the variable "Health" and ending the statement with a semicolon to end the "sentence."

This goes hand in hand with the idea behind "methods," or "functions." The nearest analogy I can come up with is this:

During the day, you do several tasks repeatedly. Most boil down to a few basic things. For example, you eat, go to work, brush your teeth, use the bathroom, etc. Each of those individual things you do is comparable to a "method."

For example, when you eat, some of the possible variables could be:

• The food you're eating


• How much time you have to eat


• What utensils you have

Using those variables, you will do the method that we'll call "Eat." After "Eat," you'll use the method "Work." Some of the possible variables for that could be:

• How long you have to work


• What tasks you must accomplish


• Who you're working with

After you've done the method "Work," you may go back to "Eat." Maybe after "Eat," you'll do more "Work." Then you'll do the method "Drive," where you'll go home. Some of the variables may be:

• What you need to do on the way home


• What the traffic is like


• If there are any roads closed

And so on. In the program from the example above, they've declared a few methods at the beginning which will form that basis of most of our programs:

• Initialize


• Update


• Draw

"Initialize" appears to be the beginning of the game. "Update" asks the program what's changed. Has the player hit the left mouse button? Has he hit the space bar? Has an enemy moved to the left or right? Did the player shoot a gun? "Draw" puts the results of the update on the screen.

That should give us a good starting point. We'll complete the step called "Creating the Player" and then go from there.

Let's Make A Game! Episode 2

So if I'm going to make a game, one of the first things I have to sort out is what method I'm going to use to make it. I've settled on a couple of options as to the tools I can use:

1. Game Making software, like GameMaker. An interesting solution. You can do some really cool stuff with GameMaker. For what I want to make it might be the easiest to learn, but it's also one of the least portable. It's Windows-only, and there may be some licensing restrictions in there. It also wouldn't help me learn actual programming skills, which is kind of what I'm shooting for
2. C++. Everyone tells me that learning C++ is a byzantine mess. You need a steady hand and a firm guide. Plus, the amount of knowledge necessary to make a game is crazy, especially considering that I don't want to build crazy first-person wall-hugging simulators with bump-mapped textures and whatever else. In my mind, learning C++ would be like bringing a shotgun to a snowball fight- overkill.
3. Python. The most recent Civilization games are made with Python. Some people think that Python is ridiculously awesome and can do everything you want it to. That may be so, but it appears to be good language to use if you already know C++ and just wish it was simpler.
4. C# with XNA. XNA is designed specifically to make games. XNA is designed to be portable to the 360 and Windows Phone 7, as well as Windows itself. The recent hit Terraria was made with it. If we're using the snowball fight analogy from before, XNA may be akin to a laser-guided snowball-firing sniper rifle. It's possible that it'll do exactly what I expect it to while providing me a good foundation for other types of programming, including C++ and Python if I choose.

I think you can tell which route I'm leaning towards. C# with XNA it is.

As far as art and music, I've decided to make the art and music myself. Whatever game I choose to make will be in the style of an 8-bit game, so it won't be crazy-difficult to make the art. I learned the principles of music at a young age, so the music shouldn't be terribly difficult. I've decided to use FamiTracker for the music because of its ability to do exact replicas of the the NES sound chip and have found it incredibly intuitive to use so far. I'm going to use Photoshop for the sprites, just because I know Photoshop reasonably well and can manipulate it pretty easily at this point.

I'm going to try and be humble, as well. If someone has a better method of doing something, I'm going to use it with their permission. If someone made a really easy way to put together levels or whatever, I'm going to use that as well. However, I'll want to analyze WHY their code does what it does so that I can gain a better understanding of the underpinnings of the language.

With all that being said, if you have a programming horror story, words of encouragement or even words of discouragement, send them my way. I really want to know what people think of what I'm doing here. In the course of making my game, if you see me making a huge mistake, scream it at me. If you want to lend me a helping hand, it's entirely welcome as well.

So I'm Going To Make A Game

Like most people who spend any amount of time around video games, it's always been my dream to make my own game.



This dream actually started shortly after I learned about video games. I was about 7 years old and had barely played 3 or 4 video games TOTAL and realized that I wanted to make my own game. I used to spend hours drawing screenshots for games I would never make. I was very meticulous: Each screenshot had to show a new part of the game, a new level or a new boss. I couldn't make a game idea unless I had a real idea for it.

I made up six games called "Stanley & Marvin" and another six based off of some characters named "R. Williamson & Joe" that were typical platformers. I wish I still had pictures, but those are lost to the mists of time and my disapproving mother who HATED video games and didn't want them in the house.

A few years later, I put together a series called "Hopeless Hero" where the hero would beat bosses and take their powers just like Mega Man and another couple of games called "Super Chicken" that was a shameless ripoff  of Earthworm Jim.

I always strived to put in something that wasn't being done at the time. Another of the Stanley & Marvin games was full of collectibles that would make it easier to beat the game, and if you found a super-secret item, you would find the "true" ending. That's right, I predicted the collect-a-thons of the N64 era when I was 8.

For example, one of my Hopeless Hero games included its own game-within-a-game that would be unlocked after you beat the final boss, a robot named Omicron. You could play as Omicron through his own separate series of levels and beat the "real" final boss of the game who was controlling Omicron. That's right, unlockables. I was 11.

I also put together my own Mario games by carefully copying the sprites out of my Super Mario Bros. 3 strategy guide and inserting them in my new Mario games. One final level I invented was full of EVERY enemy in the game, all in the same level, including "Jelectro," the unbeatable electric jellyfish. One of my games included a final boss that you had to beat before the clock ran out. How did you have to beat him? By ripping the clock out of the ground and throwing it at him, that's how.

Bear in mind all of these games were formulated in my head before I was 12 years old, and you have an idea about how badly I wanted to make a game. By the time I got to high school, I still didn't have a computer, but I had a graphing calculator that enabled me to finally program my own games. With the generous help of a few friends in class, I quickly became one of the better programmers in the class. I threw together an arcade game with powerups, but my crown jewels were two RPGs that I made in a week for each one. They had their own leveling system which revolved around purchasing your upgrades so that the only resource you were worrying about was money.

I went on to make my own engine for graphing calculators to handle movement on a 2D plane while still allowing for random battles. All you had to do was supply the background image and the engine would sort out your movement. I had hoped to use this to make piles of high-quality RPGs quickly and with as little overhead as possible.

The funny thing is that I would come back a few months later to these programs and engines and be really pleasantly surprised. I would look at my code and say, "Wow, how did I figure that out so well? That was a really elegant solution to a complex problem." Never mind that no one else could understand my code (which I understand now was pretty important), I understood it perfectly.

After a while I stopped making game ideas. Whereas before I had the time and the help of other people to help me through programming, all my programmer friends went on to different things while I stopped trying. I got super-depressed for a while and did nothing but play Lords of the Realm II for about a year (still a great game, by the way) until the itch to make a game started taking me over again.

When I wanted to make another game, I kept looking for a magic bullet to make game making easy. I tried DarkBasic, a programming language specifically designed to build games. I never got any farther than putting a logo on the screen for my "company." I even picked up some books that promised to "Teach you game programming in 30 days!!!" Every single one of them felt like this:

Day 1: Create "Hello World!" program.
Day 2: Create the Matrix.
Day 3: Bend the Matrix to your will.

And so on.

I moved away from it for a while and decided to just write about games for fun. It's a heck of a lot easier than making them, right? But that itch, that darn nagging itch keeps coming back. I keep wanting to make a game, and I keep building worlds in my head that can't be realized unless I know how to use the tools.

As I get older, I realize that there IS no magic bullet to making games, or doing anything worthwhile for that matter. You can't just pick up a simple program and expect it to transmute your raw thoughts into gameplay. Learning programming and making games is a slog, but it's a slog that I've decided that I should attempt for a couple of reasons.

First of all, I'm getting older. I'm 29, soon to be 30. I know I still (hopefully) have a long life in front of me, but  the days are going by quicker than I care to notice. Why wait to follow your dreams?

Second, I have ideas. I know ideas are worthless by themselves, but if you combine them with effort and action, you can create great things. Most things in this world start because someone with an idea decided to do whatever he could to make it a reality. That's what I want to do.

Third, I'm coming around to that idea that anything worth doing is going to be horribly difficult to accomplish. I learned Spanish and it was incredibly painful. It was also extremely rewarding. I got married and found it to by incredibly difficult, but also one of the most rewarding experiences in my life. I can't believe it took me almost 30 years to figure that out.

For these reasons, I've decided to bite the bullet and make my own game from scratch with very little prior programming experience and document every second of the struggle on this blog. I may not even make a real game for five or ten years. I'm okay with that. I would be remiss if I didn't at least try, though.

There are going to be a LOT of naysayers that will tell me it can't be done, and that good ideas alone can't make a game. They'll say that I'm going to quit as soon as it gets complicated. I understand that. A lot of people do quit. I'll need a lot of support if I'm going to pull this off, but I'll also need to call on my own (admittedly small) reserves of fortitude.

I'm pretty excited to do this, and above all else, I'm excited to be sharing this with my readers. My sincere hope is that I'll inspire other people to pick up some tools and make their own games. Wish me luck.

Game Design: How Much Help Do You Need?

The Legend of Zelda: Link's Awakening is one of the best games for the Game Boy and one of the best of the Zelda series.  It has tricky puzzles, smart dungeons and cool enemies.  We're going to focus on one dungeon in particular.  In this dungeon, there are four pillars on one of the levels and a steel ball that you can pick up.  The game doesn't really tell you what to do, but it expects you to do the math.  You throw the steel ball at the pillars (which are rather difficult to get to), which collapses the top level of the dungeon down to your level and enables you to fight the boss.  There aren't a whole lot of hints, so you have to sort it out yourself.

Compare that to Twilight Princess, Phantom Hourglass, Spirit Tracks.  Most of the time you'll have your assistant telling you what to do, whether it's Midna, Ciela, or Zelda.  If you walk into a level, Zelda might tell you, "Oh no!  Look at those guards!  You better avoid them!"  Midna might say something like "Take a look at the jewel on that guy's head!"  They'll pretty much walk you up to the solution or tell you where to go next.  So, the question is, was it better before?  Were games better when they didn't tell you what to do, or is the extra help a good idea?

First, it's important to ask why we got so little help on older games.  Was it because the designers expected us to figure things out?  They trusted us more?  Not really.  It's because they couldn't give us any more help due to system limitations.  The cartridge memory for Super Mario Bros. and The Legend of Zelda was prohibitively small.  For instance, the clouds and the bushes in Super Mario Bros. are the exact same sprite, just palette-swapped.  Those were the kind of things they had to do by necessity in order to get the full game onto the cartridge.  So, the reason why they only said "Dodongo dislikes smoke" is because they couldn't say anything more.  They had no space for it.

Game designers always wanted to provide more pointers, and they tried to do so in instruction manuals and the like, but there weren't a whole lot of choices.  Was the game better off for it?  That's open to debate, but a lot of the games of those days were solved with hint books and heated debate on the playground ("I was able to do an infinite hair-pull kick!"  "Nuh-uh!").  Most gamers didn't go it alone, as much as they'd like you to believe they did.  Those playground conferences are gone for most of us, but in its place we have our group of friends that we game with, as well as the big playground:  The internet.  When we get stuck in a game or find an insurmountable obstacle, we're able to go to that bastion of groupthink and get the help we need.  For the most part, we're still not going it alone.

So, if you're a game designer, you know people are going to seek help and space is no longer an issue, what do you do?  You provide the help in-game so that frustration is reduced to a minimum.  If you're a designer, you don't want the gamer to step away from your game for a moment, especially in a moment of frustration.  Therefore, you provide those in-game tips to gently nudge (or shove) the gamer along so they can see the next location.  Another option is one provided by Demon's Souls, where the community provides tips and help and recreates that "playground" environment, where multiple gamers provide help on a solution.

However, where do you draw the line?  How much help is too much help?  It's an especially difficult problem now that more gamers are entering the fold.  For instance, you show me a small key in a Zelda dungeon and I know exactly what to do with it.  If you show my wife a small key, she'll need the full explanation.  She'll need you to tell her what the key is used for, what the doors look like, and how to open them up.  If you don't tell her these things, she'll get frustrated and throw controllers.  (Yes, she throws controllers.)  That makes giving tooltips and explanations a bit of a moving target:  Too many and you alienate more experienced gamers, too few and you alienate inexperienced gamers.  How do you accommodate all these different players?

The best solution that I've found is in one of the most sneakily revolutionary games of the last couple of years:  Professor Layton.  In Professor Layton, you're presented with a puzzle and given all the time you want to solve it.  You have the option of getting hints, and in order to use them you spend coins which are scattered throughout the world.  If you use the hints, great.  If you don't, no biggie.  You can do whatever you want with them.  It's a sliding scale of hints, and it works.

PC Games have had this sort of sliding scale for years, allowing tooltips and tutorials to be either used or skipped.  Granted, they won't help you outright with the game, but who's to say that's not a bad idea?  I mean, think of this:  You're playing Zelda.  When it starts up, it asks you how experienced of a player you are.  If you're a Beginner, tooltips will be all over.  They'll show you which doors have just been opened by your actions.  They'll point you in the direction of the solution.  If you're Intermediate, they may just show which doors have been opened by your actions and tell you what you've just picked up the first time you get it (i.e. "You got 20 rupees!").  If you're an Expert, you get no help whatsoever.  You picked up a small key?  Congrats.  You know what it does, so we're not going to tell you.  You have a boomerang?  Great.  You figure it out.  If you get a brand new, never-before-seen item, they'll explain what it is, but they won't belabor the point.  This sort of sliding scale works excellent in a game with a long reach like Zelda, but what about games like Modern Warfare 2 or God of War?  Honestly, those are OK the way they are.  They have varying difficulty levels, and most experienced gamers don't need to have their hand held throughout the game.  Most enjoy the thrill of the hunt and like figuring out where things go.

The underlying issue is that we're used to thinking of solutions in a 3-D space, or using video game logic to solve puzzles.  If we see a torch and a spiderweb, we know we can use the torch on the spiderweb.  If we see a block with strange markings on it and tracks by it, we know we can push that block.  Most new gamers, however, need a little push in the right direction.  They need to have someone basically point at the solution, and that's OK.  It's up to developers to sort out how much help is too much for everyone involved.

Game Design: What Makes A Good Game?

We've talked at length about certain facets of good games, but we've never really crystallized what makes a game great.  It's easy to say that Game X is "good" and Game Y is "bad," but what makes them good or bad?  What is the objective of a game, and what are dealbreakers for games?  These three things end up tying together to make a great game, and you can't have one without the other.

1)  Controls.

The amount of enjoyment you have with any given game is directly related to how well the game controls.  Why do controls matter so much?  If your controls are poor, you cannot progress in the game with any degree of enjoyment.  This stymies the more important part of game design.  Controls can make a good game great (Super Mario Bros) or a great game merely good (the Gothic series).  However, controls mean different things for different genres and it's important to note what those things are.

For instance, in a stereotypical RPG, walking around in an overworld or in a dungeon doesn't require fancy controls.  You can get away with weird control quirks, like a slow walking speed or sluggish movement controls.  What you absolutely CANNOT get away with is poor menu design, since 90% of the game resides in those menus, battle or otherwise.  Likewise, a game like Resident Evil can get away with slow movement if you don't have to use fast reactions.  If you have to be able to react fast and you're not allowed to due to the sluggish controls, you've ruined your game.

Conversely, some styles of game rely solely on their controls.  Platformers have to be virtually pitch-perfect with their controls.  There can be no delay, no lag time whatsoever.  You have to have full and total control over the character at all times or risk ruining the experience greatly.  The Sonic games have demonstrated this:  Why the overall idea of the game might be okay, the controls usually lead to Sonic careening off a cliff or making some horrible mistake and getting killed.  Sonic games are now universally loathed.

2)  Challenging yet attainable goal achievement.

We've talked on this blog about the importance of goal achievement and how it adds to the overall satisfaction of a game.  There's a constant push/pull dynamic in gaming.  You want the player to progress, but at what degree and how fast?  Is it complicated or easy to progress?  Make the game too difficult and the gamer feels stupid and stymied.  Make the game too easy and the gamer doesn't feel they did anything special, which is the whole point.  They need to take you along, teaching you the skills necessary to proceed and then making a situation where you're able to use those skills.  Make those skills too complex and you've once again stymied forward progress.

I'm going to hold up Super Mario Galaxy as my example here.  If you take a person who's never played Galaxy and drop them into the final level, they'll be lost and die repeatedly.  Eventually, they'll give up and say, "I hate this game!  It sucks!"  However, for someone who's played Galaxy from the beginning, while the ending is challenging it's not horribly so.  You've been trained transparently throughout the game on what you need to do.  You understand how gravity works, you understand how to get Bullet Bills to work for you, and you understand how to defeat Bowser because you've done it already to varying degrees.

I'm going to use Mario 64 as my bad example.  There's one star on the Rainbow Road level called "Wall Kicks Will Work."  To get this star, you eventually get to an area where you're supposed to leap at a stone wall and hit the B button at the correct moment to send Mario flying in the other direction.  Sounds easy enough, but the timing and angle of the jump has to be perfect or Mario ends up just flinging himself against the wall and falling down.  It's much harder than it sounds because the game demands that you do it in a certain way.  You MUST kick and time your kick at the proper time and angle or risk failure.  It's frustrating and makes you not want to get that star.  Nintendo realized their error and fixed this skill in Mario 64 DS.  Now, the star is called "Wall Jumps Will Work."  You need to merely fling yourself at the wall and let Mario grip onto it as he slides down (which he does automatically), and then hit Jump again while he's sliding.  There's no mystical button press or strange timing involved.

Circling back to controls, this demonstrates that when you make your controls too difficult it stops people from enjoying the game.  When the taught skill is easier and more intuitive to use, goal achievement proceeds, satisfaction in the game rises, the gamer's self-esteem rises, and you've made a fan for life.

3)  Anticipation.

Great controls and good goals mean nothing if there's nothing to strive for.  This is where you can lump all the other supposedly "necessary" things about games:  Story, graphics, music, the works.  Those things are all in service of anticipation.

For instance, let's say you have marvelous bump-mapped graphics with full-screen AA, but everything in your game is grey and brown.  There's nothing special to see, and each level, as beautiful as it is, looks the same.  Will you continue?  Probably not.  There's nothing to look forward to.  Now, let's say that you have a less-detailed world but you're constantly handed new, inventive tools that you can use to manipulate that same environment.  Will you continue?  More than likely.  You'll be looking forward to the next tool and what else you'll be able to do to the environment.

The same applies with story.  The only thing a story is supposed to do in a game is provide anticipation.  That's why Final Fantasy VII's story worked: You wondered where it would go next and what was the true nature of Cloud, the protagonist, and Sephiroth, the antagonist.  That's why you didn't mind grinding levels or sitting through unskippable cutscenes.  They doled out just enough to keep you wondering up until the grand finale.

It's also why Half-Life's story works.  If you take Half-Life out of the video game realm and put it into the same terms of a book or a movie, the story falls flat.  However, in the sense of a video game, it's darn near perfect.  You don't know what enemy or challenge lies around the corner and you're eager to see the inventive nature of the game.  You want to find out what's going to happen next, and that makes the story good.  It's why Suda51's games still attract followers even if the design isn't always right.  You never know what audacious trick he's going to pull out from under his hat and that keeps you anticipating the next twist.  It's also why 2-D platformers really have to bring something new to the table to be interesting.  We've seen ice worlds and fire worlds and desert worlds a hundred times, so there's no anticipation.  They really have to try in order to give us something fun to see.  It's why a game like Kirby's Dream Land 3 is awful:  Once you've gotten past the first world, there are no new powers to see and no new ideas.  You don't care what happens next.

---

If these three things seem a little simplistic, it's because, at it's heart, game design is a simple idea.  Give a person an obstacle course, the tools to manage it, and a reward at the end and they can't resist it.  Give a person a frustrating obstacle course, unwieldy tools and no bonus at the end, and they'll avoid it.  All the ancillary things that people THINK are important: Graphics, music, cool flashy combos, downloadable content and all the other buzzwords of the moment need to be in service to the three things listed above or they are worthless.

Getting Back To Game Theory

I've been blathering on an awful lot about the hideously boring console wars.  I'm going to have maybe one more post up about them and then I'm backing off for a while.  I'm going to try and get back to my bread and butter: Game design.  Stay tuned.

Game Design: Goal Achievement

You can't throw a 360 controller these days without hitting a new scientific study about video games.  "Gamers are addicted!" says one.  "Gamers aren't addicted!" says another.  "Gamers are psychopathic killers!" says another.  "Gamers are totally normal people!" says yet another.  In all of these studies, no one ever asks the question, "Why?  Why do people play video games?"

It's an odd question to ask.  I mean, why not?  Video games are fun!  That's why we play!  It's so simple!  But why are they fun?  Some people find video games mind-numbingly boring.  Why?  Isn't fun universal?  You have people like this 11-year-old kid who says video games are a waste of time.  We don't feel that it is.  Why would someone say such a thing?  The answers to these questions are fundamental to our understanding of gaming, game design, and the industry in general.

Humans are very goal-oriented.  When you waste an entire day watching TV, you don't feel very well afterwards.  You don't feel like you did anything, right?  Our goals are fairly dynamic as well.  In a few minutes your goal may be to read an article or wash the dishes or sell X amount of sprockets at your job.  We have long-term goals and short-term goals.  The more difficult these goals are, the more inward satisfaction we feel once they're completed.

Video games work on this level.  Each game provides us with artificial goals.  If we're playing Halo, our goal may be to win this multiplayer round.  If you're playing Super Mario Galaxy, your goal may be to get to 90 stars.  If you're playing World of Warcraft, your goal may be to use that shiny new bow that's sitting in your inventory.  When we reach these goals, we feel satisfied, secure in the knowledge that we did something.

Now, are these goals necessarily noteworthy?  No, not really.  I mean, in the grand scheme of things, winning a Counterstrike match isn't going to change the world.  There's still a sense of pride that fills us when we do these things.  Why?  Because it fulfills a basic human need, a need to get things done.

This can explain many things.  For instance, why are Diablo and its variants so addicting?  Is it because of the awesome storyline?  No, it's because it continues setting goals in front of you.  They'll give you an awesome new weapon that you can only use once you achieve level X.  You want to achieve that level to use the weapon, and once you do, you feel contented.  However, Diablo doesn't stop there.  It's already given you another weapon or piece of armor that you need to work towards.  It's constantly setting easily attainable goals in front of you and letting you accomplish them.  MMOs do this as well, which explains why they're so very, very popular.

There are two sides to this coin.  When a task is too easy, we don't feel like we've accomplished anything.  I'm playing The Legendary Starfy right now, and I'm bored out of my mind.  It's decent, but it's not difficult at all.  I'm plowing through it easily, and I haven't felt like I've accomplished anything yet.  Conversely, when a task is too difficult or too obscure, accomplishment gets stymied.  We stop playing.  This is why we don't like backtracking and wandering aimlessly.  This is why we like to have current quests waiting for us.  If we don't, we feel like we haven't done anything, haven't accomplished anything, haven't gone anywhere.  It's not satisfying.

This is also why most casual games aren't as bad as you'd think.  Games like Peggle or Wii Fit help someone set goals and achieve them, just like a normal game.  A game like Wii Music is comparatively a flop for the same reason:  There's no goal.  There's nothing to achieve.  You cannot improve with the game.  It rightfully can be called a failure in game design.

This also explains the explosion in motion controls.  Motion controls work because they take away one of the barriers to goal achievement, that pesky little controller.  Now, all someone has to do is mimic the movement that they would do naturally and they're able to achieve a goal.  Natal hopes to further cut down on that barrier to goal achievement.

There's more to this, though.  Consider:  Since we all have this basic need to accomplish tasks, and video games provide us with an artificial sense of accomplishment, what does that mean for our psychological health?  Does that mean that we feel more accomplished than other non-gamers?  Does that mean that we might not try as hard in other facets of our life?  Or do we have a higher self-image that other groups?  Do we become accustomed to achievement so often that we search for it in other parts of our life?

These are all questions for greater minds than mine.  Still, recognizing this truth helps us to understand why certain games and technologies work and others don't.  We understand why we shouldn't fear most casual games.  It also helps us to understand a little bit more about ourselves and why we play.

Game Design: Simplicity

This topic occurred to me the other night. I was watching TV and I found an old episode of The Andy Griffith Show and I decided to watch it. You know what amazed me? How simple it was.

Here's the plot of the episode, which was called "Otis the Deputy": Otis, the town drunk, realizes his family's coming to visit him. They think he works for the sheriff's office, so Andy and Barney feel bad and make him a temporary deputy so that he can impress Otis' brother. It turns out Otis' brother is just as much a town drunk at Otis is, so Otis needn't have bothered.

That's it. That's the whole episode. There's a sequence where we meet Otis' wife, and she makes him throw out his booze because he's a deputy and has to uphold the law, but there were no subplots, no other diversions. There's nothing more to recap.

And you want to know something? It was brilliant. Anything else would have just gotten in the way. They knew they had a good idea, so they just let that idea do its thing. It ended up being an episode that's consistently listed as one of the best episodes of The Andy Griffith Show, no small feat for a show that has some really good episodes.

This got me thinking about game design. I reviewed a game a while ago called Tornado that had a brilliant concept: You play as a tornado and you're supposed to suck up buildings on earth. It was a great game until the developers started throwing more ideas into the mix, like special weapons and opposing tornadoes that tried to bump you out of the way. It almost seemed like the developers didn't trust their idea enough to let it breathe. It ended up being a huge disappointment of a game.

It's really a common danger with game design. Designers are afraid that the great idea they have really isn't so great, so they start trying to mix it up and obfuscate it and end up making things far, far worse than if they had just left it alone.

I'm going to tell all the developers out there something that probably already know: You're all really, really smart. If you have an idea that seems like it will work, it probably will. Trust your instincts.

Look at last year's indie darlings, Braid and World of Goo. What is Braid? A side-scroller with time-controlling elements. What is World of Goo? A building game. Look at the year before, with Portal. What was the concept? When you strip away GladOS and cake and the Weighted Companion Cube, it's a first-person puzzle game.

Now, to be certain, the things that are piled on top definitely add to the game's charms, but would Portal still be a good game without GladOS? Yeah. Would World of Goo be great without all the wacky backgrounds and music? Yes. Why? Because the underlying idea never gets covered over. No matter how out-there the gameplay gets, the developers trusted the idea enough to never bury it under rubble.

Even more mainstream games like Gears of War 2 and Killzone 2 are basically using the same template that was set down way back by Wolfenstein 3D. It's just prettier. They're building on a basic idea, but they never cover over the idea with other flotsam.

So, when designing a game, remember, trust your instincts. If you have an idea that seems to be fun, it probably is. Just remember to let that idea breathe, or you'll be smothering it before it has a chance to grow.

Game Design: The Evolution of 3D, As Explained By 2D

A lot of times, it seems that us older gamers are too hung up on older systems to care as much about new systems. That's not always true, but I can attest that my thoughts are usually more preoccupied with old-school systems than modern systems. Why is it important to care about these older systems? Why not forget about them and focus on modern gaming? What can they teach us about gaming's past and present?

One of the big reasons is that it can show us where we're going in gaming. Most really old school gamers started with the Atari 2600. It was the birth of in-home 2-D gaming, but it was really primitive. Some of us look back on it fondly, but most of the games looked like this:

Tell me what's going on in this picture. Go ahead. I'll wait.

There's a lot of nostalgia for the Atari 2600, but frankly, most of it is unearned. It's only a big deal because it's the first system we played. I know this sounds like heresy, but fire up a 2600 and you'll see what I mean. I'm hearing some sputtering from the peanut gallery saying, "But...but...but Pitfall!" I answer, yes. Pitfall looked good, for an Atari 2600 game. Most everything else was pretty blah.

The next generation fared better, though. 2D finally started coming into its own, but it was still a bit away from being perfect. There were a lot of problems with screen and sprite flicker. Even a well-optimized and polished game like Super Mario Bros. 3 still had the occasional glitch, and they couldn't really help it. There were still too many limitations in the hardware, but you could finally see the potential.

It wasn't until the 16-bit generation that 2D finally came into its own. Things finally looked the way they were intended to. With games like Super Metroid and Sonic the Hedgehog, you could finally get what the big deal was with 2D. Almost every game was drawn relatively well, even the budget ones.

It was around this time that the first tentative steps into true 3D were being made. Some were okay, but even good games like StarFox ran at 20 frames per second and looked like they were made out of cardboard, and not in a good way. The worst offenders, like Stunt Race FX, ran at about 10 frames per second and should never have been released.

In the next generation, 3D started spreading its wings a little. Sure, a lot of stuff looks pretty jagged, and yes, some of it looks ridiculous now. Even a game as revered as Goldeneye looks pretty bad now.
As the above screenshot from Goldeneye hopefully proves, 3D looked best when it was trying not to imitate real life exactly, but when it was doing a more cartoony look.

When the PS2, XBox, and Gamecube hit, 3D finally came into its own. Finally, you could see the full potential of 3D gaming, and you didn't have to squint in order to pretend that you were looking at a space marine instead of a group of polygons.

So what's the next step? What next improvement will take the leap and start rolling out slowly but surely, improving by degrees until it's finally where it should be? Who knows? It could be gaming with 3D glasses. It could be the perfection of motion controls. It could be a technology that we haven't even thought of. It's just exciting to see gaming grow and change over time, and we're all lucky to be able to watch it.

Game Design: Internal Vs. External Characters Part 2

Yesterday, we dissected the difference between internal and external characters, and why it's a big deal to make the distinction. Today, we're going to be seeing some examples of characters done the right way and the wrong way.

The most successful internal character is Mario. One of the reasons for his continued success is because he says very little. When we play Super Mario 64, he only says things like, "Its-a me, Mario!" and "Hello!" They tried giving him more dialogue in games like Super Mario Advance 4 by having him say things like "Just what I needed!" It was an immersion killer. It sold a lot, but you'll notice they've stopped doing it. They've even cut down on the voice samples in games like Super Mario 64 DS and Super Mario Galaxy.

Mario also has very little continuity from one game to another. There's no reason to care if Super Mario Land is canon in the Mario universe, or if Super Mario Galaxy came before or after Super Mario World in a fictional timeline. It doesn't matter. Mario is merely a construct and not necessarily a fully fleshed out person with his own motivations, and it works for that specific character.

Here's another example: Sitting through mountains of exposition is okay when we're playing Final Fantasy VII. We care about Cloud's backstory and his motivations, so we want to know what makes him tick. However, what makes Gordon Freeman tick? What kind of life did he live before Black Mesa? Who cares? He shoots aliens now, and that's the important thing.

You could make the claim that Gordon Freeman isn't an internal character, as everyone calls him "Gordon," and you're playing his story. In response to that, I ask you, when Alyx smiles at Gordon, how do you react? Do you react by saying, "I think she likes Gordon?" Or do you think "She likes me?" Similarly, Alyx can take punishment from enemies rather well. Playing through Half-Life 2 Episode 1, I was still protecting her even though I knew I could use her as a meat shield. Why? Because I myself was emotionally invested in her survival. I had internalized the Gordon Freeman character so that he became me.

Other game developers will gently play with this "internal/external" dilemma. Bioware did this with Jade Empire. When you play as an internal character, you expect that your character is "the one," the main hero who is head and shoulders above everyone else, and for most of Jade Empire they play that up. I won't spoil the game, but those who have played Jade Empire know that it subverts the very nature of an internal character.

Circling back to Sonic the Hedgehog: Sonic started out as an internal character. We weren't just playing as Sonic, we were Sonic. He was an extension of ourselves, and the controls reflected this. Over time, Sega tried shifting him to being an external character without warning and we still see him as an internal character. Therefore, the same things we'll accept while playing as an external character, like endless dialogue and strange controls, become unacceptable when playing a new Sonic game. Therefore, they'll delve into weird diversions like a human/hedgehog romance, and they have no qualms about giving him motivations, hopes and dreams. They tie the games together with needless plot threads, making the transition from internal to external even more jarring.

It's not a bad idea to switch some characters from internal to external. Some characters, like Link or Samus, were originally internal only because it was never really thought of to use external character in action games at that time.

However, Link started out internal and is slowly moving external. When A Link To The Past came out, it wasn't important which game came first in the Zelda canon. Once they started adding more story in Ocarina of Time and Wind Waker, it became more important. It's cursory, but there's a mythology that never existed before and adds depth to the game. We still view Link as internal, but there's no doubt that he's moving to the external side of things.

Similarly, Samus was viewed as internal throughout the entire first Metroid. Then, during the ending, they rip the lid off and reveal that Samus is a woman, thereby opening up tantalizing possibilites for melding internal and external characters together. Metroid games still play as if Samus is an internal character, but Metroid Fusion took a huge step in trying to externalize her by giving her a former commanding officer and more backstory. Now that Retro Studios is done with the Prime series, it's very exciting to see which direction they'll go with the Samus character.

That's a lot to cover, but I hope that my point has been made clear: When designing a game, it's important to decide whether or not your character is an extension of the gamer or separate from them and design accordingly. Otherwise, you can end up making more Sonic games, and who really wants that?

Game Design: Internal Vs. External Characters Part 1

This train of thought all started with Sonic the Hedgehog.

Fewer characters have inspired so much devotion and so much hatred as Sonic the Hedgehog. In the 90's and early 00's, Sonic was the epitome of cool. Sega did what Nintendidn't, and Sonic was a demonstration of that. He ran faster, his games were cool, and Sonic himself was ubiquitous, appearing in several cartoon series. He very nearly could have eclipsed Mario in popularity.

But then something happened. Sonic went from the top of the heap to digging in the trash bin faster than Amy Winehouse. They still make Sonic games, and every time a new game comes out there's a little bit of hype, but when the games get released they usually land with a sickening wet thud. Inevitably, Sonic's fans defend the game to the death, while most everyone else looks at these deluded souls with derision and pity.

How did this happen? Many have focused on laggy controls or the change to three dimensions as being the cause. Others speculate that all the extra characters haven't really helped matters either. I thought it was because "Dr. Eggman" is a stupid name, and he should always and forevermore be known as "Dr. Robotnik."

Another answer came to me, though, and it's an answer that reverberates not only through the Sonic series, but all of gaming. It explains why we are willing to put up with these issues in some games, but they can be completely unacceptable in other games, and it has to do with the way we perceive characters.

Most characters can be split into two groups, internal characters and external characters. When you play as an internal character, that character becomes an extension of self, meaning that you have internalized that character's story so that it becomes your own. When you play as an external character, you are playing THAT character's story and not your own. Examples of internal characters are Mario, Gordon Freeman, old-school Sonic, and the protagonist from Grand Theft Auto 3. External characters would be characters like Solid Snake, Cloud Strife, new-school Sonic, and GTA4's Niko Bellic.

Why is it important to make a distinction between internal and external characters? For the simple fact that it affects everything about the game. I do mean everything, from the controls to the story to the environment itself.

There are benefits and drawbacks to each character type. When you use an internal character, you are able to provide deeper immersion with less exposition. The character becomes whatever the player wants that character to be. The developer provides the blank canvas upon which the player projects themselves, making them more emotionally attached to the character. Instead of being a nebulous "they," the character has now become an "I." I beat Bowser. I passed that level. I distracted that creature with a grenade.

You also have to do less explaining with an internal character. The player assumes some things about an internal character. They assume that the internal character is "the chosen one" upon which the gameworld hinges, so you don't usually have to lay out pages of backstory.

The downside is that you have less storytelling capability. Nowhere is this more apparent that in the Half-Life. We all agree that the story is great, but there are so many gaps in the story because Gordon only knows what he is told. How do you fill those gaps without stepping out of character? It's something that Valve is grappling with, because when you try and cram more story in, it can very easily break immersion.

Another downside can be attributed to developer laziness. The same problem crops up with amateur fiction writers: They don't want to describe a character, so instead they assume that the audience will describe them. They don't want to say that a character has brown hair and blue eyes, so they hope the audience puts that in for them. Similarly, a lazy developer might view an internal character as a crutch to reduce their workload, so that they don't have to explain much about the character.

External characters have their own strengths and weaknesses as well. An external character can have a more involved backstory in most cases, since you're not telling the story from only one point of view. A great example of this is Final Fantasy VII, which tells not only Cloud's story but also Barrett's, Red XIII's, Aeris' and Sephiroth's stories, among others. It makes all of the characters a little richer and involves you more in the gameworld.

You also don't have to worry about control as much. Control is still a big deal, but gamers are willing to accept compromises for more in-depth storytelling. Since we use the character as a tool and not as an extension of ourselves, we're willing to give up a little control. For instance, if Mario couldn't shoot fireballs while walking, it would be a travesty. It's a tiny distinction, but it would affect the gameplay greatly and there would be nerd riots everywhere, including this site. However, we'll accept that Solid Snake and Chris Redfield can't reload while walking. It annoys us, but it's not a gamebreaker since the character is a tool instead of an extension.

There are some negatives to external characters, though. There is much less immersion in an external character, because you don't become the character, you use the character. The developers have to resort to other means to get your attention, like the Sanity meter in Eternal Darkness. Therefore, as a developer, you have to work harder to get the character attached to the game emotionally.

You also must provide a balance between gameplay and exposition with external characters. If we're following someone else's story, we need enough information about the character to provide us with motivation during the gameplay but not too much so that we feel overwhelmed by exposition. This is a trap among many amateur filmmakers: They feel that the way to achieve immersion is through backstory and an opening crawl. The reason why things like an opening crawl work in something like, say, Star Wars is because it's brief and there's action immediately afterwards. The story only gets filled in with more details once we're attached to the characters. Many developers (hello, Hideo Kojima) can't manage that balance and instead provide far too much information about the character and the world, breaking immersion.

So, what are some real-world examples of these types of characters in action, and what lessons can we learn? Check back tomorrow.