Alek Hiebert

Behavioral Psychology In Level Design

autobzooty — Tue, 27 Dec 2011 03:11:00 +0000

One of the most useful tools game designers have at their disposal is behavioral psychology. Behavioral psychologists believe that the inner workings of a subject’s consciousness are not important, and that outward behavior is the only relevant factor in predicting or influencing human action. Whether or not one agrees with this school of thought, it’s a highly useful model in game design because the only information that one can reliably observe in the context of a video game is the player’s in-game behavior. How is it possible to use the data from a player’s actions in a game to understand ways to teach them things they need to be taught in order to succeed? How can their behavior be influenced to push them towards or away from victory? Because players have limited avenues of expression in games, it becomes extremely important as a designer to be knowledgeable in the field of behavioral psychology in order to create an effective gaming experience.

In most video games, designers present players with a problem that must be solved. Sometimes this problem is a test of skill or dexterity, sometimes it’s a test of problem solving skills, but for the most part, games can be defined as problems for players to solve. It can also generally be assumed that the designer wants the player to succeed. It’s possible that they don’t want it to be easy, but now that games aren’t built for arcades anymore, there’s nothing for the designer to gain from defeating a player. As such, a designer’s goal should be to influence a player toward success without the player realizing it. How is this possible? The first and often most difficult step is to teach the player the rules the game will operate under.

Shigeru Miyamoto’s classic Super Mario Brothers does this by using ideas from behavioral psychology to design the environment of the first section of the game in such a way that it will limit the actions the player can take, forcing them to succeed. When the game begins, there’s nothing on the screen except for the player controlled avatar and the ground he’s standing on. Nothing will happen at all until the player learns how to move. Of course, given that the controller had only two buttons and a directional pad, this is a process that will probably only take a couple of seconds. But the lack of pressure during these seconds when the player learns the most basic action that can be taken in the game is crucial.

As the player moves forward, the first object in the world they will come across is an enemy. At this point, players might not understand that it’s an enemy, but if they touch it, they’ll die, sending them back a few moments to the start of the level. The player must understand that they can jump over this enemy in order to proceed any further. If they are able to move past this enemy, the designer can be sure of three things: first, that the player knows how to move, second, that the player knows what enemies look like, and third, that the player knows how to jump and avoid enemies. After that, players are presented with floating blocks above their head. At this point, the only way they can interact with anything is by jumping at it, so it’s likely that they will try this to discover what secrets the mysterious question mark block holds. If they jump at one of the plain looking brick blocks, they will see the bricks react to the impact, but nothing will happen. This will make them want to try hitting the shinier blocks to see if those have a more exciting effect, and what they will find is that a strange looking object rises up and begins moving.

This object is a powerup that makes the avatar stronger, but it looks much like the enemies that the player has learned about, and the player might attempt to avoid it. It’s crucial at that moment for the designer to make sure that the player understands that this object is not like the enemies. So in the game, the item will do the following: roll off the block it popped out of, drop off the ledge, hit a pipe, reverse direction, and begin moving towards the player. The subject’s instinct might be to jump over it, like they learned they could do with enemies, but because of the level design, they will hit their head on the blocks above them, bounce down, and collide with the powerup. The avatar grows in size, and the player understands that this object is good, while the other objects are enemies. They have barely traveled across a single screen of the game, but their actions have been manipulated through level design based on behavioral psychology so that they had no choice but to learn everything they need to know about the game.

Let’s take a look at a more modern example, Portal 2. This game’s level design takes the concepts mentioned above in the Super Mario Brothers example to a more extreme level, attempting to introduce and teach players about progressively more complicated mechanics of the game. It usually does this by controlling the environment so that success is inevitable the first time the player is introduced to a new concept. The first chamber of the game is completely empty except for three things: a box, a button, and a door. There is only one possible course of action that can be taken in this room, and that’s to put the box on the button to open the door, and then walk through. This room teaches players that buttons cause things to happen, boxes can be used to act on the environment, and the goal of a level is to walk through the door. Most players don’t realize it, but they learned all these things in that chamber, even though it was a tremendously simple puzzle and virtually impossible to fail.

Because it can be guaranteed that players know these concepts after reaching that point, level designers can then start taking those concepts for granted when teaching players more complicated things. The levels were constructed in this way, in this order, for that very reason. If there are any unknowns involved with the solution of the puzzle, there will be no satisfaction for the player when the puzzle is solved. All the tools and all the information have to be known, and the only way to know what a player is aware of is through observation and interpretation of their behavior. If a player is chasing a red herring solution that the designer does not want them to be pursuing, this can be observed in their behavior and the environment can be adjusted so that the player does not exhibit that behavior in the future.

For example, imagine a puzzle in which the player has to activate a switch to create a platform that bridges a bottomless pit obstructing the goal. Perhaps the player’s first intuition would be to simply jump across it, only to find out that it’s too far, and they would die. Maybe, though, the jump was close enough that they want to try it again. It might look like a very difficult jump, but the player might think that the challenge here is making a difficult jump, not trying to create a platform that would allow them to proceed. The designer wouldn’t want the player to repeatedly die trying to jump over something that they are not supposed to jump over, so how is it possible to manipulate the player’s environment to stop them from exhibiting that behavior? There are a couple of options, even in this simple example. The switch could be placed more in plain sight so that the player experiments with that before repeatedly throwing their life away. An even better solution might be to increase the size of the gap so that players do not consider it possible to jump across. It is clear from this simple example that it is possible to know what the player knows through observation of their behavior, and adjusting the game environment can effectively control that behavior. This is a perfect illustration of one of the major tenants of behavioral psychology.

Players cannot do whatever they want in video games, and probably never will be able to. Their avenues for expressing their thought process are limited to the behavior they’re able to exhibit in the context of the game, and any verbal commentary they might express during or post play-testing. And while player feedback can be a valuable tool at times, it is often very unreliable as players don’t always know exactly what they want or exactly why they felt the way they did while playing the game. Knowing the answers to those questions is the job of a designer, and the only reliable data that can be used to answer those questions is in-game behavior. It’s because of the limitation of actions players can take in game that behavioral psychology is such a crucial tool for any game designer.

Case Study: Bastion

autobzooty — Wed, 24 Aug 2011 04:38:00 +0000

Time for my second case study! This time I’ll be taking a closer look at one of my favorite games to come out all year, Bastion from Supergiant Games.

Bastion is a 2D top-down action game with a strong focus on narrative. In it, you control a little chibi boy known only as “the kid” as you explore the richly beautiful yet disturbing environment around you. The game begins with the kid waking up on a floating rock in the sky and a mysterious narrator talking as you play the game. As you run around and explore, chunks of land fly up and come together underneath your feet. The effect is very striking and certainly piques one’s interest about the strange world the game takes place in.

The narrator points out that the eerie void and floating land are the aftermath of some disaster he calls “the calamity.” And in Caelondia, the ruined city where the kid lives, there was a safe haven where everyone agreed to meet in case of trouble: The Bastion.

Right out of the gate, everything seems bad.

Supergiant Games actually pulled back the curtain and allowed news site Giant Bomb an unprecedented look at the development of the game. Typically, the public doesn’t see a game until it’s polished and pretty, but anyone can go take a look at what Bastion looked like before an artist was even hired for the team. I definitely recommend checking out the video series for anyone interested in what it’s like for a small team to make a project like this.

Bastion benefited greatly from having a small core team of only about 4-5 people. From start to finish, it feels like a product that had very specific goals in mind, and a small team of people each working on a singular goal and nothing else. For instance, virtually all the visuals in the game were created by a single person, Jen Zee, which leaves the game with a very cohesive yet creative and unique visual style. I believe that the larger the team of artists there is working on a single game, the more generic the game’s visuals will become, since each artist will strive to homogenize their ideas in an attempt to make it blend together with the rest of the project.

It’s hard to believe that all these assets could be generated by one person, but Bastion has made me a believer in the idea of giving everybody on the team an enormous yet singular task for the project.

The main reason I wanted to do a case study of this game, though, is the strides it takes in narrative driven games. Video game stories are terrible. But every now and then, a game comes along that seems to figure out what makes storytelling in video games a fundamentally different art from other mediums. Chiefly, and perhaps most obviously, that the player is interacting with the world and can make choices. Bastion is a game that realizes this and constantly gives the player the opportunity to make choices. They don’t always have a direct impact on the story, but the game does a good job of acknowledging that you made a choice and commending you for it. Making you feel special about it. Let me give some examples.

There was a huge amount of dialogue written for the narrator that I mentioned above. He is used as a tool for acknowledging the choices that the player made. There are many games that give players freedom to do pretty much whatever they want, but don’t actually provide any feedback when you do things. Take the popular sandbox game Just Cause 2, for instance. You, the player, might decide to steal a military jet and kamikaze it into its own military base. The game totally gives you the freedom to do that. But the delicious irony of that act is hard to appreciate when the game itself doesn’t appreciate it.

So the team at Supergiant attempted to predict actions that the player would take, and use the narrator to tell the player that, “Hey, I noticed that you did that.” The first weapon you acquire in the game, a hammer, is placed amidst plenty of debris ripe for the smashing. If you hang out there and bust it all up before moving on, the narrator chimes in, “Kid just rages for a little while.” Players probably don’t even realize it, but standing there and breaking everything in sight was a choice that they made, and giving players consequences for the choices they make, even if it’s something as small as a comment made by the narrator, makes all the difference in the world. Moments like that are peppered throughout the entire game, and even though you aren’t always making choices that are going to rock the foundation of the world you’re playing in, it makes the story feel much more organic.

The narrator will also keep you informed about the places you’ll go and the enemies you’ll encounter.

For the size of the team and the scope of the game, there is a staggering amount of writing that was done for Bastion. Supplementary backstories, world lore, even the hints on the loading screen never seem to repeat themselves. This gets back to my previous point about small teams with specific goals. If you have only a handful of people working on a game, and one person’s job is to just write, you can bet that there is going to be a lot of writing in the game. There are no stupid video game contrivances to be found in this game like there are in so many others. All elements of the story and game world were thoughtfully considered and accounted for in game, something that sadly can’t be said for many video games.

But to only praise and analyze Bastion’s story-telling would be a disservice, because the combat is both deep and refined. Somebody somewhere spent a lot of time balancing all the weapons and abilities available to the player, and it paid off. The combat in Bastion is some of the tightest you’ll find in modern video games, and it also feeds back into the idea of the player making choices.

Combat is intense and satisfying.

There are a ton of unique weapons in the game, but the player can only take two with them at a time. In between levels, you can visit the armory to change your loadout, and when you do, the narrator will always have something to say about the choice you made. Every single combination of two weapons in the game invokes a comment from the narrator, usually praising you on your excellent choice. Of course, this would completely fall apart if any of the weapons was obviously “the best” choice, but it was all so carefully balanced that everyone has a different favorite weapon. Both the choice of weapons and the way they inform the way you engage in combat are choices that the game asks you to make, and when the narrator pats you on the back for the decision you made, you can’t help but feel a little special.

Bastion is a huge success, beautifully crafted in all ways. Thanks to a small team, specific goals, and appropriate scope for the game, Bastion is easily able to hang with the giants of the industry. Everyone could stand to learn a thing or two from this game, and I hope that developers take some cues from Bastion’s triumphs. I would be one happy kid if there were more games like this in the world.

Bastion is available for $15 on Steam and Xbox Live Arcade. Do not hesitate to pick it up.

Boss Battles

autobzooty — Wed, 17 Aug 2011 00:07:00 +0000

The boss battle is a concept that has existed for almost as long as video games themselves. It’s such an old trope in video games that I believe many designers have lost sight of what their actual purpose was when they were first introduced, and what that means in the context of modern game design.

To begin with, let’s examine a classic: The Legend Of Zelda.

The first boss of the NES classic

Traditionally, games in the Zelda series are structured so that you work through a dungeon, solving puzzles and defeating enemies to find the treasure of the dungeon, and then proceed to defeat the boss with that very treasure. In all cases, the treasure of the dungeon is also needed to gain access to the boss’s chamber, as well.

As you can see from the screenshot above, boss battles weren’t exactly a spectacle back in the 80s. Instead of merely looking awesome, boss fights served the purpose of testing the skills the player had been accruing in the dungeon up to that point. The rest of the level was just practice, and the techniques the player learned throughout it would be directly applicable to this final challenge.

Zelda has always been decidedly light on story though, and nowadays, boss fights tend to serve as dramatic climaxes or primary forces that drive the narrative. And this is where many modern developers go wrong with the concept.

Lots of games nowadays don’t use combat as the primary mechanic of gameplay. For these games, a classic “David and Goliath” style boss fight is probably not fitting, and it would be a much better idea to have a different kind of boss, or forego boss fights altogether, as is done in Portal 2.

Too many games these days shoehorn in boss fights that simply don’t belong, and this ends up creating boss fights that are the low point of the game, rather than the high point. Case in point: Batman: Arkham Asylum.

Though he is Batman’s main antagonist, the Joker doesn’t really stand a chance against him if put in the same room for five minutes.

Arkham Asylum’s gameplay is split up into three unique categories. The first being sections in which Batman navigates the asylum and tracks down clues to figure out where to go next. The second is basic fisticuffs against unarmed thugs. And lastly, the sections in which Batman must stealthily eliminate inmates armed with guns (which can kill him quite quickly). Exploration, fisticuffs, stealth. See?

Now, the purpose of boss fights in this game is two-fold: to allow Batman a moment of direct conflict with the many supervillains in the story, and to provide a new context for the player to exercise their skill in fisticuffs or stealth. The only trouble is, the new context they provide is generally gimmicky and not as much fun as the rest of the game. For example, the scenes in which you “fight” Batman’s fear based villain, the Scarecrow.

Scary? Subjective. A step backwards in stealth gameplay? Absolutely.

The idea with Scarecrow was to try to create a boss fight centered around stealth, a design challenge I’ve seen many people take a stab at with varying success. The glowing portions of the ground in the screenshot above indicate Scarecrow’s field of vision. Batman must navigate the terrain without being spotted by Scarecrow to win. This means waiting for Scarecrow to follow his rigid pattern of where he’s looking, and making a dash for cover as soon as he looks away.

This is the most primitive and boring form that stealth in can take in a video game. Back when this idea alone was enough to fuel an entire stealth game, there would always be more than one guard that you had to avoid so that it didn’t become so mindless and dull. But here, the player only has to watch Scarecrow as he moves his head back and forth like a robot to allow them to proceed. It’s not difficult at all, and it’s extremely tedious.

It’s especially tragic because the stealth in the rest of the game was so damn good. Let’s take a look at that for a moment.

For the first time in a stealth game, the player is the one who is feared by the guards, not the other way around.

In the regular stealth sequences, players use all of Batman’s gizmos and gadgets to knock out the guards who are looking for him. They must isolate individual goons, pick them off silently, and quickly move away back to the shadows before the other guards notice. With each thug that goes down, the rest of them start to visibly panic, Joker taunting them over the intercom all the while.

It’s a beautifully organic experience that can be approached from a hundred different angles. Batman has so many tricks up his sleeve that deciding how exactly you want to take down each guard is like being a kid in a candy store. For me personally, these sections of the game were the best power-fantasy I’ve ever played in a video game.

This unique, refreshing take on the stealth genre is thrown to the wayside so that we can have a super archaic boss fight with Scarecrow, simply because we need to have a boss fight with Scarecrow. Most of Batman’s villains are very psychological in nature. It’s weird to see him actually fighting any of them hand-to-hand. The conflict for Batman is always how he must stop a complex, diabolical plot that is already in motion, not how can he find the strength to punch some dude’s lights out. I know Batman is a superhero and he technically has a lot of supervillains so boss fights seem like a no-brainer, but every encounter with a boss in that game is a step down from the rest of the game.

I think the developers would have been wise to rethink that whole part of the game. Does this game really need boss fights? Can we create direct conflict between Batman and the villains without pitting them against each other? Can we create climactic moments in the story without boss fights? These are questions that need to be asked when putting a boss in your game.

For Arkham Asylum in particular, it’s hard for me to come up with what I would specifically do to fix these issues, so I’m not trying to say it’s easy. But I’d rather shoot for a product that was good from beginning to end rather than end up damaging the overall experience with a poorly conceived stab at a “high point” for the game.

Adventures In Level Design: The Long Road of a Failed Design

autobzooty — Sun, 24 Jul 2011 11:58:00 +0000

Over the course of the past several days, I’ve been working on a series of puzzles for another Portal 2 map. I had what I thought was an exceedingly clever idea for a mechanic to work a puzzle around, so I got to work right away fleshing it out from the ground up.

I began on paper.

The core of the idea was for the player to jump down a deep shaft to gain speed, and land on a 45 degree slope at the bottom. This would have two effects, as I illustrated crudely above. If a portal was placed on the 45 degree slope, the player could shoot out of a flat surface at an angle. Conversely, if repulsion gel was placed on the slope, the player could bounce off of it and into the 90 degree wall at a perfectly straight angle, allowing them to pop out of a portal with a straight trajectory.

I named it the Repulsive Drop. It worked perfectly on paper, but I had my doubts about the physics engine of the game keeping up. So before I built an entire puzzle, I constructed a prototype in a rudimentary room.

The bottom of the Repulsive Drop. The grey areas are where portals should be placed.

The first problem I ran into was that the player would have to be exceedingly accurate in their plunge, requiring them to not only land on the portal, but land on a very specific spot on the portal. If they grazed the edges at all, they wouldn’t come out at the desired angle. Discouraged but not defeated, I came up with this solution:

A grate at the top of the plunge makes the initial drop more precise, while leaving room at the bottom for the portal to be placed.

Through some testing and fine tuning, I was able to achieve both desired launch angles from this prototype, so I began construction of a test chamber which implemented it.

I had a puzzle completely designed by that point, so I set out constructing it all in the level editor. The last thing I did was install the Repulsive Drop.

Accuracy was still a problem, so I shrunk the drop point as much as possible.

I gave the work-in-progress level to some friends for play testing. It was important that someone besides me could grasp the logic of the puzzle, and also that other people were able to get the desired results from the Repulsive Drop.

It took them a long time to even figure out what the theoretical solution was, and when they did, they couldn’t get the Repulsive Drop to function properly. It turned out that as the designer of the faulty mechanic, I was taking for granted just how tricky it was to get the thing to work properly. No one could make it through the angled portal at the bottom cleanly, and were popping out of it at odd angles.

The nature of Portal puzzles does not require the player to be particularly dexterous or quick with their hands in order to solve a given puzzle. So when they tried to use the Repulsive Drop as intended and it didn’t work, they didn’t try it a second time, they just assumed the solution was elsewhere. I tried desperately to continue tuning the Repulsive Drop so that there would be no room for error on the player’s part, but in the end it was just not possible.

WORK, DARN IT.

Eventually I had to admit to myself that, as much as it pained me to do so, the entire idea needed to be scrapped. Play testers were confounded, and the mechanic was janky in the best of cases. So the past few days of work on this concept have been entirely fruitless, except for the lessons I’ve learned.

Don’t be afraid to let go of bad ideas
Play testers know best
Naming your design ideas makes it that much more painful when they die

With these lessons taken to heart, I move forward to continue work on this map. It’s a tough and frustrating thing to give up on what I still believe is fundamentally a clever idea, but it can’t be helped. I’ll just have to move forward with some better ideas.

Thank you for participating in this Enrichment Center activity

Adventures In Level Design: Wherein I Complete My First Puzzle

autobzooty — Sat, 16 Jul 2011 22:50:00 +0000

With a little bit of elbow grease and some colored lighting, I have successfully designed a puzzle.

In all her glory. I can’t get that potato off the Portal Device, but whatever.

Having learned my lesson about slap-dash level design from my previous failure, I decided to be very careful and efficient when designing this one, but I was also able to retain some of the ideas that I liked from that puzzle. I began by making the following chart:

Switches	Controlled Items	Tools
Floor Switch 01	Angled Panel
Floor Switch 02	Emancipation Grid
Discouragement Beam	Chamber Door
Button	Cube Dropper	Cube
		Excursion Funnel

I divided all the elements I wanted in the puzzle into three categories. First, the various switches that would need to be switched to complete the puzzle. Second, each item controlled by those switches. And third, the tools in the test chamber that would assist the player in interfacing with those switches.

When looking at the puzzle in this model, the way to make a difficult puzzle becomes very clear; create more controlled items and less tools. In my particular puzzle, the Excursion Funnel needs to be used three times for three different tasks, and the Cube (once acquired) needs to be used on two occasions. Tools that have more than one purpose are absolutely essential for making a puzzle interesting and challenging.

However, not all elements of a puzzle can be accounted for using this particular model. World geometry is often a core part of a good puzzle, as what elements you have access to can change depending on where in the puzzle you’re standing. I’m going to try to come up with a different model to design puzzles in that can account for this, besides just drawing a picture, as that requires you to have an idea that is almost fully realized before you can begin the actual work. Not to mention the room for human error it leaves, as I learned the hard way.

If you’d like to download my puzzle to try and solve it, here is a link!

Adventures In Level Design: Portal 2

autobzooty — Wed, 13 Jul 2011 03:04:00 +0000

As I sought out temporary avenues to practice game design without a team of programmers and artists, I suddenly remembered that all Valve games come with the development tools to make mods and custom levels. Feeling emboldened by the amazing entries in Valve’s official mod contest for Portal 2 (a delightfully vexing puzzle game with a simple rule set and some dastardly challenges), I set out to learn to use the tools and practice level design. Here’s what I’ve learned so far.

While browsing the super helpful wiki on the subject, I came across a couple of schools of thought for level design. One method for designing a Portal puzzle is to use a chart to plot out the various states you want the puzzle to go through before you complete it. This can help you design a puzzle before you really have a vision of what it’s going to be. For example…

	1	2	3	4
Emancipation Grid	On	On	Off	Off
Floor Button	Unpressed	Unpressed	Pressed	Cube’d
Storage Cube	Hidden	Out of reach	Obtained	On button
Small Button	Pressed	Cube dispensed	x	x
Chamber Door	Closed	Closed	Closed	Open

This is a simple 4 step puzzle that I designed as a basic way to get started. I selected the elements that I wanted in my puzzle first, and then decided what they should be used for and when they should be used. Apart from knowing what each button actually controlled, I didn’t really have any kind of concrete image in my head of what the puzzle would be at this time. But this simple chart gave me a foundation to work from. I ended up with a puzzle that looked like this:

Prolonged exposure to the button!

Ultimately I deviated a bit from the original chart (you can see there are two floor buttons, and the cube was never out of reach), but the chart was just a place for me to get started.

My second attempt at making a puzzle didn’t follow this methodology at all, and also happened to be a total failure. Perhaps a coincidence.

I had this idea after intense brainstorming, rather than through vague ideas slowly taking shape as I built the level. In this second puzzle, I wanted to make the player use a cube to press a button to reach the exit, but also require the cube to press another button to OPEN the exit. This time, I had a very clear image in my head of what I wanted the level to be, and I drew it out on a piece of paper before constructing it for real, just to be sure it all worked.

This time, the puzzle was more complicated than I could keep track of in my head. I tried to work out the finer details of the puzzle in a similar way one would if they were PLAYING the game. I created a challenge that was literally impossible, and then tried to make it possible with as few changes to the stage as possible. I would also want to try to obscure the changes I made in some way, so that they wouldn’t just point out the answer in a tremendously obvious way. This was the result…

The dilapidated art style of this map is symbolic for my failure.

Much more complicated. It would have been quite a challenging puzzle I believe, if it were possible at all! Sadly, no changes I could come up with would make the puzzle possible without it becoming super simple.

The lesson here is to work backwards. Come up with the solution first, and then build a puzzle to obscure that solution. I’ll update more as I make more puzzles, and I may post links to them if I ever find success!

GDC 2011 Diary: Day 5

autobzooty — Sat, 05 Mar 2011 06:30:00 +0000

No writeup from yesterday since I didn’t actually go to the show. Stayed in to do some school work.

But today! Today, was the last day of GDC, and I wouldn’t miss it for the world. My day was filled with panels designed for students to help them break into the industry. And boy did it ever help.

The first talk I attended was advice on building a good portfolio for visual arts. There was a lot of good tips and good advice that could be applied to job interviews in general. The sample work they showed from various students’ portfolios was all really impressive. Too impressive. By the end of the panel, I had lost all hope of ever becoming a visual artist. These guys are just way too good at what they do, and they’ve been drawing their entire lives. I don’t have the raw experience to compete with them. So it was all a very intimidating and belittling experience. But it also proved to guide me towards the light.

I have respect and appreciation for visual artists, but it was never what I wanted to do. See, I had always been under the impression that “game designer” was a very prestigious position, and you couldn’t just get a job as a game designer. So I figured visual arts would be a great stepping stone to take me where I really wanted to get in the end, which is just to design some GAMES. So after that horrifying panel, I was inspired to do a little Googlin’. I now had some concrete questions I wanted answers to, and that’s basically what I wanted to get out of GDC. Not necessarily answers, just questions. My questions were as such:

1. What is an entry level game design position?
2. What does a game designer do on a day to day basis?

Pretty basic stuff. Not exactly the kind of thing I could feel comfortable with asking a panel of distinguished professionals in front of a large audience. So I found my own answers!

As it turns out, in recent years in the industry, game design CAN be an entry level position. Obviously a student fresh out of school isn’t going to land themselves a job as creative director or lead designer, but they don’t necessarily have to find a weird convoluted path to their dream job by learning unrelated skills like programming and fine arts. The eye opening article I read can be found here at Game Career Guide’s website (the same group that had their logo all over the panels I went to today). Additionally, that article linked me to this article, which was equally eye opening with regards to my second question. Today, these two articles provided me with the knowledge and hope I was craving from GDC.

Later that day, filled with hope and an angus beef hamburger, I went to a lecture which gave general tips on how to break into the industry. It was much more relevant to me, and I learned some more very basic things.

According to the lecturer, it takes three people to make a game. (Or rather, three ROLES.) You need an artist, a designer, and a programmer. However, it takes five people to run a studio. In addition to the previous three, you need a marketing man to make sure your game gets out there, and a business man to handle contracts, publishers, and that sort of thing. Upon hearing this my first thought was, “That’s all?” It seems so simple. So delightfully simple! If I’m a designer, then all I have to do is find four talented people that can fill those roles in order to start my own studio? A five man team means no bureaucracy to get in the way of creative vision. It means that I could be the creative director of a project right away. Sure the scope of the games wouldn’t exactly be enormous, but I’d be making the games I want to make with a wonderfully small team.

But even still, that’s a long way off. I still don’t have the skills necessary to commit to doing something that serious. But all these ideas are buzzing around in my head now that I have a stronger understanding of how the industry works. It’s very exciting to finally figure some of this basic stuff out. It’s so hard to get any insight into the way this industry runs as it’s all shrouded in secrecy from big business. GDC was a great way to step behind the curtain and see what’s going on.

The final panel I attended was a great high note to end the conference on. A collection of huge gaming celebrities took the stage and answered questions about how to get into “AAA Game” development. I.e., your Gears of War, Metal Gear Solid, that sort of thing. The gaming equivalent of a big-budget block buster.

The big names and recognizable faces on stage talked about the difficulties people can face when trying to achieve that dream of directing “the game.” It’s a long road to get there, to get to the point where publishers will trust you with hundreds of thousands of dollars based on your reputation. Honestly, I’m not sure it’s worth it. Yes, it would be like heaven to have that kind of money to make a game with, but the road to get there is so long and arduous, that I wonder if it really is better than being an integral part of a small indie team right away.

My main takeaway from that panel is that big companies are a great place to learn things and gain experience, but huge development studios like that have to deal with a lot of issues that simply don’t apply to indie developers. Maybe it would be good to get an entry level design job at a studio like that, learn as much as I can, and then start my own studio.

But anyways, this post is turning into far too much of me idly day dreaming so I’ll cut myself off here. Coming to GDC has really been an amazing experience and I’m so glad I did. If there’s anyone else out there who gets the opportunity to come, even if you are clueless like I am, I definitely recommend it. It is completely worth while.

So long, GDC.

GDC 2011 Diary: Day 3

autobzooty — Thu, 03 Mar 2011 07:05:00 +0000

Today was the first day that the Expo Floor opened up at GDC. It was way more crowded than it had been on Monday or Tuesday. But when I finally stepped through the doors and into the light, I saw why.

I went to a couple of talks before heading inside, but I didn’t get too deep into them. Suffice it to say that I wasn’t the target audience for the lectures that I saw today. But that was fine, and it gave me some interesting insight into some corners of the development process that I knew nothing about.

I walked around the show floor a little bit and got to see a lot of neat things at the different booths. 3D sure is the hot new thing right now and I got to try and see a lot of it. In the end though, the glasses keep ruining the experience by washing out all the color and just generally being a hassle, especially since I wear a pair of glasses to begin with. Enter Nintendo’s 3DS.

The 3DS is the next handheld coming out of Nintendo. Like its wildly successful predecessor, the 3DS has two screens. Now though, the top screen can display in eye popping 3D. WITHOUT GLASSES.

I got to demo many games on the device today, and the most shocking thing about it all is that it works as advertised. Granted it takes a moment for your eyes to adjust and not fight the dual images they are receiving, and you also have to hold the system in a somewhat fixed viewing angle for the effect to work, but once you take a brief moment to get acclimated, the effect is remarkable.

So while I have nothing but great things to say about the hardware itself, the software is pretty much all middling at best. The best game for the thing right now is a remake of Ocarina of Time. Not exactly the stellar launch one would hope the system to have. I have faith that the software will really start to get amazing later in the year, but for now, there’s not really a good reason to buy the system. Which is a real shame because I REALLY WANT TO.

Apart from that, I just walked around and took some pictures. Nothing super notable happened today, so I’ll just dump all the images I have and write a little note about them. Expect more of the same tomorrow because I don’t have any talks scheduled until Friday.

Nintendo’s 3DS. Smaller than I thought it would be, but it felt sturdy.

A talk I attended on some 3D modeling software that I’ll never be smart enough to use. I think I learned that I never want to be a 3D artist.

Sony’s next portable cleverly named the Next Generation Portable was not playable, but slowly rotating in a glass bubble.

Unlike the 3DS, Sony seems to be pushing their device as something that can offer portable versions of experiences you’d expect to find on home consoles. I think it’s an unwise strategy personally, but it remains to be seen what exactly this device is going to be, so we’ll have to see.

SpeedTree is a hilarious bit of middleware that I first heard about on GiantBomb.com in their coverage of GDC 2010. It’s capable of randomly generating trees for your game based on criteria you feed it. I was tickled that I found this booth.

Some dudes from a press site doing an interview with a developer. I thought it was neat to see something like this happening.

Tomorrow I plan to go back to the Expo Floor and play the rest of the 3DS games I didn’t get to today, and maybe I’ll write impressions of each one on here. But again, they’re not very good, so we’ll see.

‘Till then!

GDC 2011 Diary: Day 2

autobzooty — Wed, 02 Mar 2011 07:53:00 +0000

Decidedly less lectures today. Lots more hands on type activities and a little more faffing about on my part. Spent the entire day at part two of the game design workshop. But before I talk about that, I wanna show and tell some of the neat little things I’e experienced at GDC so far.

After I signed in on Sunday, I received a bag full of what I’ll generously call “swag.” Most of it was garbage trash, but inside it was a single blue square. On the back of the square was a note informing me that it was a pixel, and I needed to put the pixel in its designated place on a mural at GDC. Everyone attending GDC got a pixel, and we’re all going to put them together to create on giant mural. It’s actually a fun and neat idea, I thought.

The work-in-progress mural

I’ll take another photo of it towards the end of the show when it’s complete. If you get close to the mural you can see silly things that people wrote on their pixels. Actually most of them were just plugging their websites, but whatever.

Another neat thing going on is what’s being called the GDC “metagame.” The jist of it is that you go to the booth that’s running it and they give you a hand of cards with the name’s of various video games on them and question cards which ask things like “Which game is more educational?” and that sort of thing. Anyone wearing a metagame sticker on their GDC pass is playing the game, and you can challenge them with a question and a game card. They then take a game card from their hand and play it against the card you laid down, and the two of your debate for two minutes about why you think your game fits the question better (even if you really don’t!).

A winning combination, for sure

After you debate, the bystanders judge who made their case better and declare them the winner. The winner pulls a random card from the losers hand, and the game continues on throughout the show. At the end of the show, whoever has the most “holographic” cards (that is, the ones with the stars in the corner) gets some fancy gift certificate or an iPod Shuffle or something. I forget. It’s a pretty fun way to break the ice or just have an interesting discussion about video games.

Some more of my cards

I also spent about thirty seconds playing my very first 3D game. I haven’t even seen a 3D movie yet so it was quite an interesting experience. I walked up to a demo station running Fable 3 on PC, popped on the glasses, and was washed away by dimensions I barely knew existed.

In all honesty, I haven’t been big on the whole 3D gaming thing, but now that I’ve tried it, I think it might not be a total waste of everyone’s time. I don’t think it’s possible to actually use the 3D as a gameplay mechanic, but there was a marked improvement in visual clarity and depth perception with the 3D, even if the glasses I was wearing did turn everything grey. If there’s ever a cheap, glasses free method of making this the new standard, I don’t think that would necessarily be so bad. Provided they work out the kinks. The 3D definitely had a hiccup or two while I was playing that made my eyes want to explode in pain. It felt like I was crossing them really hard, but they were totally relaxed. Weird stuff.

Anyways, on to the meat of what I actually learned from the show today.

The first project I did today was to modify a board game called Three Muskateers so that it could be playable with 3 or 4 players, rather than just 2, while maintaining the aesthetic qualities of the original game’s design. One of the interesting things about the original game was that it was asymmetrical multiplayer. In other words, each player had different moves and abilities at their disposal, rather than a game like chess or checkers in which both players are identical forces.

One of the important things about the original game’s design was that in the beginning, not many moves were available to either player, but slowly more and more possibilities would open up until the game finally ended. Our instructor for this activity pointed out that the game followed the arc of dramatic progression.

As time goes on, the number of choices slowly increases until reaching a peak, and then quickly dropping off

This was a HUGE deal to me. Dramatic progression is really important to me and dictates a lot of how I think of game design, but I never thought it could apply to anything but an actual narrative. Here we have a multiplayer experience whose story and narrative is basically left at the door as soon as the game begins, and yet dramatic progression completely applies to the spirit and flow of the game. Amazing!

The design me and my group ended up with turned out to be some kind of territory control type experience, and the changes we made turned it into a symmetrical multiplayer experience. In fact, as we went around the room, I found that most groups did the exact same thing. This wasn’t necessarily supposed to be the takeaway from the project, but I certainly found it to be very interesting.

Asymmetrical games are very difficult to make. The key reason for this is that the easiest way to make a game fair is to give both teams the same tools for winning. But if you want to accentuate the differences between players, you’ll have to spend a lot of time tweaking and refining it to balance it, and balance is a really hard thing to measure when the units of measurement are not the same.

In the end, I think the asymmetrical experience was more exciting, interesting, and strategic. It’s extremely difficult to pull off, but worth all the effort. I actually felt a bit of passion for multiplayer game design stir up inside me after this project, when typically the only things I’ve cared to design are single player games.

The last major thing I did at the workshop was what they called a “paper prototype.” Somewhat in the spirit of the case studies I do in this blog, we chose an existing game to strip down into a game played with dice and cards. The idea being that if you remove audio, visuals, and the controller, all that will remain will be the game’s design, and you can learn from it easier.

My group decided to make a paper prototype of StarCraft, a ragingly popular real-time strategy game in which you collect resources, build a base and train an army to defeat your opponent. So we sat down and decided that the most important aesthetics of StarCraft are urgency, secrecy, and strategy. We constructed a card game based around those ideas as quickly as we could, and though we almost ran out of time, when we sat down to play it, I was shocked at how truly fun and engaging it was. By the end, I wanted to keep playing and keep refining it further and further.

The instructors, all successful game designers at various companies, informed us of how useful paper prototypes can be in the early stages of developing a game. Not only is it basically free, but the end result will be an invaluable tool for communicating others what you want your real game to be like. The takeaway from this project was that play transcends media. Very poetic.

After that we all blew off some steam by taking a paper bag filled with random goodies and making a game out of it in a short amount of time. Our game was very close to being fun. And with this last goofy, somewhat noneducational project, the game design workshop drew to a close.

Over the course of the two days, I met and worked with loads of game designers, many from distant countries. One from England, one from Finland, and a couple from Spain! People come so far to go to GDC, it’s really amazing.

Tomorrow I’m going to two talks. One about how to start up your own studio and one about animation software. Second one might be over my head, but I wanted to check it out. I’ll also be attending an award show for 2010 games, which should be fun. Also, the main floor opens up tomorrow and I’ll be roaming around there talking to dudes. So staaaaaaay tuned!

GDC 2011 Diary: Day 1 (Belated)

autobzooty — Wed, 02 Mar 2011 04:47:00 +0000

Only thing on my schedule for monday and tuesday of GDC is the Game Design Workshop, which goes from 10:00-6:00 on both days. Here’s a rundown of what we did and talked about on monday.

Hideo Kojima, my hero, took a picture very similar to this and posted it on his Twitter. *squeeeeeeaaaaaal*

The lecturer opened up by telling us that the most important thing we could do is to iterate frequently and to fail fast. That is, when designing a game, the first version of it is pretty much guaranteed to be terrible no matter what. So rather than spending a thousand hours on the first playable version and putting the cherry on top only to have it fall apart completely, it’s more valuable to spend a short amount of time on early versions of the game. That way, you get actual hard evidence and reasoning to back up the changes you make, instead of playing the game in your head and finding out later that it doesn’t work out quite the way you thought it was going to in the end.

He continued on to teach us about what’s called the MDA Framework. The MDA Framework is a sort of philosophical structure in which you can organize your thoughts and make a better game. Respectively, the MDA stands for mechanics, dynamics, and aesthetics. A game’s mechanics are the rules and systems that make it go. You would find the mechanics of a board game you purchased in that game’s rule book. Dynamics are what happens while the game is actually played. The lecturer made the point that you can’t enjoy a game of chess just by looking at a chess board; you have to actually sit down and play the game. That act is the dynamics of a game. Finally, aesthetics refers to the desirable emotional response to the game. The “fun” if you will. However, we later learned to try to eliminate words like “fun” and “gameplay” from our vocabulary, as they are not helpful in game design. It’s like calling a painting “good.” It might be good, but it’s not a very scientific or informative term.

The MDA Framework can be used to gain a number of different perspectives on a game that one is designing, but the one that seems most valuable to me personally is that it allows you to effectively reverse engineer your game. That is, you start by choosing an aesthetic goal, design the way you want the player to interact with your game, and lastly, refine the mechanics until the game is solid. A to D to M. Depending on what your goals for the game are though, you could approach the MDA Framework from any angle you like.

I mentioned earlier that the word “fun” is bad and should not be used when possible. The lecturer has a personal philosophy he shared with us known as the eight kinds of fun. He listed them as such:

Sensation – The sensory experience a player has with a game
Fantasy – Games as make believe
Narrative – Games as an unfolding story (This is distinct from fantasy in that it’s about the story of the player playing the game, rather than the fictional story the game is telling. A good example of this being the drama of a chess game.)
-Challenge – Games as a problem to solve
-Fellowship – Games as a social experience
-Discovery – Games that contain worlds to explore or systems to learn and become skilled at
-Expression – Games that allow you to create things or express yourself in one way or another
-Submission – Games as a mindless pasttime (see: Angry Birds, Tetris, etc)

He stressed that there were probably more kinds of fun that we could come up with if we really tried, but it was more about finding and using a vocabulary that we’re comfortable with. We can craft our own theories as we make our own games. I found this eight kinds of fun method very useful though and I’ll probably continue to use it.

Later in the day I attended another lecture which delved deeper into the MDA Framework. Specifically, where should the player come into the equation?

Depending on the approach you want to take, you could insert them anywhere. Making the player themselves a mechanic of the game is something that’s become more and more popular in recent years with motion controls and cameras being integrated into party games. You could also view the player as solely a subject which should react to your game, though in my personal opinion, that approach is more suited to passive media such as books and movies. But if the player is considered in a game’s dynamics, you’re accommodating them as they actually experience the game. This is the most logical place to think of the player for most games, in my opinion.

To expand on the player as a piece of a game’s dynamics, the instructor talked a lot about human psychology and how game designers can manipulate the players in a number of ways. The example he gave (conveniently enough since I wrote about this game at length a few posts ago) was Pacman. In theory, the powerups in Pacman should make the game easier, right? You give the player a tool with which to survive and it should make it easier for them to win, right? Well in the case of Pacman, it causes players to play much riskier and greedier. A real world example he gave was when several groups of people were asked to build a tower as tall as they could using only marshmallows and dry spaghetti. They performed decently under normal circumstances, but when a large sum of money was offered to the winning team, not a single team was able to construct a qualifying tower. This psychological phenomenon is called the greed catalyst.

Later he talked to us about something called a self-serving bias. I’m sure everyone has experienced this before, “I lost because I was unlucky, I won because I am skilled.” People have a tendency to attribute their success to themselves, and their failures to forces outside of their control. This is called the gunslinger’s alibi. This is actually useful in friendly multiplayer games because it allows one player to feel good without the other player feeling bad. Wizard’s of the Coast (a notorious maker of trading card games such as Magic and Pokemon) have an internal philosophy with their magic series called the 70/30 rule. A more skilled player should win 70% of his matches against a less skilled player due to events in the game that he could not possibly foresee or prepare for. This is a great rule of thumb for casual multiplayer experiences, though the audience of a highly competitive game like StarCraft might cringe at such a deliberate imbalance.

The lecturer reached a point that I couldn’t help but strongly disagree with, though. He said that players are more tolerant of failure that can be blamed on bad luck, or random failure. As long as they are not blaming themselves, he claimed, they won’t become frustrated. Before coming to this lecture, I specifically carried a design philosophy very close to me that stated the exact opposite. The player should ALWAYS blame themselves for their own losses. It makes them feel like the game is worth playing, worth mastering, worth another round. The phenomenon of losing a game to something you should have known about is called a purloined letter. If you doze off while playing and forget a particular rule and lose to that rule, you can’t really blame anyone but yourself. The instructor said that the gunslinger’s alibi plus a purloined letter equals a rage quit, since it becomes impossible for the player to escape their own ineptitude.

It may be true that players are more accepting of random defeat, but I would argue that the only reason for this is low investment. Low investment means that they are dangerously close to getting bored, and a bored player is dangerously close to quitting. Also, if a game glitches out and shuts down, I would put that in the category of random failure. Losing to a coin toss. For me personally, nothing makes me angrier, so I was surprised to hear the lecturer speak in favor of such a thing, but I guess I’ve been playing video games for almost all my life so perhaps my perspective is in the minority. It’s certainly more punishing and games I make might be less accessible for it.

Even I’ll admit that it’s somewhat of an unsolved mystery in game design. Mastery through repetition is one of the oldest themes in video games, but is it obsolete? Is it engaging? Is it appropriate for game design moving forward? Should trial and error really be the way a player is taught to get good at a game? Particularly in competitive multiplayer games, I’m quick to criticize games like StarCraft and Street Fighter for failing to teach the player how to actually get better at the game. Learning by going online and getting destroyed by more experienced players is incredibly discouraging, and it led me to quit competitive StarCraft, even though I love the game to death. It’s a tough case to solve to be sure, because weakening failure also weakens success.

So that’s basically a summery of GDC day 1 for me. Hotel internet has me behind schedule on these writeups unfortunately, and I’m far too lazy to do much proofreading on this. These are just meant to be quick summaries of my experience at the show, and jotting down what I’ve learned. Hopefully it’s not too longwinded and boring. I certainly didn’t take enough pictures to sprinkle through these articles.

Not too busy for now. That will probably change when the expo floor opens.

Anyways, I’ll write again “tomorrow!”