Behavioral Psychology In Level Design

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.

(continued after the break)

Case Study: Bastion

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.

Boss Battles

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

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

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.

1. Don't be afraid to let go of bad ideas
2. Play testers know best
3. 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

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

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

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

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

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)

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!"

GDC 2011 Quick Update

Hotel's WiFi was just not cooperating with me last night, so I was unable to write up my notes. Tonight I'll try to get up a giant summary of day 1 and 2, assuming I can get online.

GDC 2011 Diary: Day 0

Not a whole heck of a lot to report today. Set out today with my suitcase in hand, and one short flight and a taxi ride later I'm checked into a beautiful hotel in San Francisco.

For one week, I live like a messy king

Before the sun went down though, I walked over to the building where GDC will be held just to make sure I could find it. I registered and got my pass as well as a bunch of crap in a bag. Some of it is interesting, like this game development magazine, but most of it is just ads for various useless junks.

Tomorrow is the first day of the event proper and I'll be clocking in at 10:00 AM to head to the Game Design Workshop I signed up for. It goes 'till 6:00 PM and there's a part two on Tuesday, so I honestly have no idea what to expect in such a large amount of time. I may duck out early in favor of seeing other parts of the show if it doesn't seem like it's worth the time and energy, but I have literally zero expectations for what this will be so I'll play it by ear.

In the coming days I'll write in here about what I spent time doing at the show that day. Never done a GDC before, so we'll see how this goes.

See ya tomorrow!

Game Developers Conference 2011

Next week is a convention in San Francisco in which game developers from around the globe come to give speeches, set up booths, and talk to people about designing video games. I will be attending and attempting to learn as much as possible! The show begins on monday and ends on friday. Each evening I'll be doing write-ups in this blog about what I learned and I'll be shooting out tweets throughout the week as well, so check me out on there as well if you care to follow me.

Here's my schedule for the event.

Session Title	Date	Start Time	End Time	Location
Game Design Workshop	2011-02-28	10:00 AM	6:00 PM	Room 236, East Mezzanine
Edu to Indy: Teaching Students Self-Reliance	2011-02-28	3:00 PM	4:00 PM	Room 301, South Hall
Game Design Workshop	2011-03-01	10:00 AM	6:00 PM	Room 236, East Mezzanine
Distance Education Vs. Brick and Mortar: What Game Courses Work Online and What Don't	2011-03-01	3:00 PM	4:00 PM	Room 301, South Hall
IGDA Indie SIG Social Gathering	2011-03-02	10:30 AM	11:30 AM	IGDA Booth, Lobby South Hall
How to Build a Game Studio: Workplace Design Strategies to Maximize Your Team's Creativity and Productivity	2011-03-02	12:00 PM	2:00 PM	Room 300, South Hall
The 13th Annual Independent Games Festival & Awards Ceremony	2011-03-02	6:30 PM	7:30 PM	North Hall D, Lower Level
The 11th Annual Game Developers Choice Awards	2011-03-02	7:30 PM	8:30 PM	North Hall D, Lower Level
Killer Portfolio or Portfolio Killer: Advice from Industry Artists (Part 1)	2011-03-04	11:50 AM	12:40 PM	Room 303, South Hall
Killer Portfolio or Portfolio Killer: Portfolio Review (Part 2)	2011-03-04	1:00 PM	3:00 PM	Room 300, South Hall
From College to Industry: 20 Lessons for Getting the Most out of Your Early Career	2011-03-04	3:10 PM	4:00 PM	Room 303, South Hall
Breaking into AAA Game development: Ask the Pros	2011-03-04	4:10 PM	5:00 PM	Room 303, South Hall

Nothing scheduled for thursday, so I'll likely end up spending a lot of time on the show floor talking to people and looking at all the booths. Maybe I'll even go to one of the parties, who knows. I'll try to take some pictures, too. This will be fun!

Styles of Storytelling

In narrative driven video games, there tend to be two major schools of thought. On one side you have the "old-school" style of thinking in which stories are presented linearly, much like a book or a movie would be. More recently though, we've seen many games from western developers featuring non-linear stories. What this means is that the player can have a significant impact on when and how certain events play out in the game.

The most notable example of this style of story telling is BioWare's Mass Effect series. In those games, players create a character (male or female), choose their appearance, and embark out into a rich sci-fi universe. Not only do players choose the appearance of their character, but they also choose how their character behaves. Every time you interact with another character in Mass Effect, you choose what the character you made will say, and what you say can and will have a profound impact on the game. Players who choose their words carefully can avoid certain conflicts altogether, while a more aggressive style might earn a few more enemies than other players. Sometimes, your actions can even determine whether or not major characters will die.

An example of the dialogue system in Mass Effect.

The benefit to having a story like this, where the player chooses where to go and what to do, is that it allows the player to truly role-play. That is, they can decide what type of character they want to be, and truly become that character. It offers new levels of immersion in video games when you're playing as a character who is ostensibly just an extension of yourself. It's something really amazing, and it's something that's really only possible through video games!