adventures in game design

Shut up and listen!

So on the subject of iteration...

Listening to criticism from my peers is extremely important. It is our jobs as designers to meet the expectations of the player - and every comment a co-worker might give me can be extrapolated to be hundreds of paying players or game journalists. I love getting praise as much as anyone, but when I hear that something doesn't feel right - I pay attention. Here are some tricks I use when taking criticism:

• Write it down
  • I want to keep the feedback channel open as much as possible. When co-workers see that I'm serious about taking notes of everything they say, they're encouraged to come back later. The last thing I want is to ship a game where everyone hated an attack or mechanic, but never talked to me about it. Also, I forget things very quickly :)
• Identify the real issue
  
  • Sometimes the issue is obvious - like when someone complains that they want to see how much health they have before going into a combat scenario, but the health UI only shows up after combat is initiated. Other times it is buried under many layers - like when someone suggests to make sprinting be automatic after a few seconds of running. When asked why, the answer might be to move the throw button to the right trigger. When asked even further, it may come out that this person wants to add a toggle health UI button to the directional buttons and is just suggesting how to change the control scheme to accommodate. Smart people have a tendency to realize the problems their suggestions might create, and instead suggest solutions to those problems. See my post on "What is the problem you are trying to solve" for more.
• Take the time to explain
  • A lot of the time, I don't have a decent answer or plan for the criticism. But that's ok! I've found that explaining the constraints of a problem turns the sourest critic into a powerful ally. It's truly awesome to have that same person come in a few days later with a great solution to the issue. Also, that's the true fulfillment of anyone giving criticism - seeing positive change, and knowing that they helped bring it.

Blast from the past - old Blood Omen 2 combat feedback

Been a while! I moved to Downtown Baltimore (Canton really), built a new computer, etc. But the moving process is done, and I have lots to write about.

I was filing (throwing out) some very old papers, and I came across some pages of combat feedback I had written up when I was testing Blood Omen 2. This was back in late 2001, so I was just a young QA know-it-all. Very little of this feedback was implemented, but I was surprised at how spot on some of this still is even for games that are coming out now.

Here's a few nuggets from that doc, and my reflection:

[little bazooie from 2001] "Enemies block, and do not stop blocking [highlighted as a problem]. Once an enemy blocks an attack from Kain, the enemy continues to block until the user gives up and stops attacking for a long period of time or walks away. Enemies (especially early, weaker eemies) should miss opportunities to block, tire from blocking, and try to evade or interrupt Kain's attacks. Also, enemies should block at the the incorrect time, giving Kain the opportunity to grab or attack the enemy."

[big bazooie from 2009] Even now I still see this as broken, and the game shipped this way. The best strategy was to jump left or right immediately after an enemy began blocking because that would force it to walk to face you and exit the block behavior. Once an enemy entered the block motion, nothing could harm it, and it would take about 5 seconds before it exited the block motion to try attacking. I would first solve this by making enemies counter attack after blocking Kain's larger combo ending attacks. This would keep players from repeatedly attacking, and teach them by example of how to use block properly.

[little bazooie from 2001] Attacks do not collide with multiple enemies enough. Many times, Kain's sword appears to pass through two enemies and only one is affected. Attacking multiple enemies with one attack is an exciting part of combat games when all are pitted against one (ex. Double Dragon, Final Fight). I have seen this happen once, but this could be tweaked to occur more often.

[big bazooie from 2009] One enemy at a time is BORING, especially when the attack chains are limited to three hits like in BO2. It was rare for 2 enemies to attack simultaneously, the pace was slow, and the game needed some excitement.

[little bazooie from 2001] Enemies' weapons should break as well. It seems that weapons only break if Kain is holding and blocking with them. Weapons should take damage on all hits and blocks regardless of who is holding them. This is too advantageous for enemies.

[big bazooie from 2009] Hah. Well, the producer in me now knows the reason for this (more animations and more costly AI behaviors for not much gameplay gained). It's good to keep in mind that players don't think in terms of production cost. I think this wouldn't have been an issue if enemies didn't block so much.

[little bazooie from 2001] Kain's weapon draw animation is too long. More often than not, Kain is getting hit before he can pull his weapon out. If anything, the weapon-draw needs to be faster. A weapon-draw attack would be incredibly useful (pullng out a sword and slicng in the same action).

[big bazooie from 2009] This problem was at its worst when Kain was knocked down. He would play his get up animation, and while drawing the weapon before attacking, he would be knocked down again. In addition to the solution above, I would now have implemented a timer on enemy attacks to wait until the player could properly perform an action after getting up.

There's much more from the doc, but I'm not really going anywhere with this.

Responsiveness, feedback, and iteration. Part three.

Well, back in Part One, I promised my perspective and methods on iteration in Part Two, but I took a detour to write about feedback since it's often overlooked and given a back seat to fidelity. Anyhow, I'm back on track with iteration.

Most of the game dev world agrees that iteration is the correct way to make good games. The more time we have to iterate, the better our games are. There's a dirty secret that designers don't like to admit. Iteration automatically assumes that we are wrong - otherwise, we would have no need to iterate. Most designers, including myself, love to be right. But embracing iteration as a development method means we must assume that we will be wrong multiple times before getting it right.

Iterative design in the hands of an always-right designer can be a bridge-burning overtime-crunching game-killing nightmare! The always-right designer doesn't design a system to handle the possibility that he might be wrong, and specs out all aspects of a system to painstakingly perfect detail. When the programmers, animators, and artists are done, and the game isn't fun, the always-right designer has no proper understanding of why. This is because the system came online in uncontrolled waves based on whatever was done first, or because he believed that everything would be right when all the parts were completed, and he didn't pay attention to the problems until everything came online. The always-right designer also doesn't have a sense of responsibility for why the system is wrong, and has no problem starting over from scratch with a completely new idea while relying on "Iteration" as an excuse for wasting everyone's time.

Iteration is like a number guessing game, where we make our best guess, determine whether we are higher or lower, and then guess again. The best designers understand this, and design systems so they can make new guesses quickly. Technically, this is a binary search pattern. Personally, I learned this strategy in 1990 by playing Teenage Mutant Ninja Turtles: Fall of the Foot Clan for GameBoy. At the end of each level, Master Splinter gives you 9 guesses to guess a number between 1 and 99. With each guess, he lets you know if the number is higher or lower. If you guess the number, you get extra lives. I couldn't beat the game without the Splinter bonus, so after a series of mixed successes by randomly guessing, I quickly learned that if I always guessed half of the value range, I would always guess the number. The only reason I write about this is to get an excuse to put an image on this post:
 
OK - I am oversimplifying just a tad. Iterative design isn't really like a number guessing game. It's like an array guessing game, and instead of a number, we're trying to find fun. And instead of "higher" or "lower" we often don't get anything at all!

So us designers don't know have to know everything, but what we do need to understand is when to add or remove each part of a system, and when to turn the knobs.

In practice, whenever I begin working with animators, artists, programmers, audio, etc., I always make it a point to let them in on the dirty secret of iteration: That I will be wrong, and I'm only guessing. But also that I value their time, and I my decisions are always based on getting the game to be fun in shortest possible path.

Next post preview: Filtering feedback on the dev side, so you can be as responsive as possible. See what I did there?

Responsiveness, feedback, and iteration. Part two.

    Pro Evolution Soccer is a great game series, but it is absolutely horrible in regards to responsiveness. In PES, the designers went to great lengths to get the actual feel of a soccer game by perfecting the soccer ball physics and taking into account each player's particular strengths and weaknesses, but they sacrificed responsiveness along the way. When you press the X button to pass the ball in PES, the game stores that input as a request and then you have to wait until the kicker has caught up to the ball, gained control of it, and placed his foot before the actual kick animation begins. Sometimes this can be 3 seconds away if the player is far from the ball. However, the X button also happens to be the command for canceling a pass. You can see where this is going right? Many times a player will press the X button to pass, and the game quietly buffers the request and continues to simulate the game. Meanwhile, our player notices that his command didn't execute, so he pushes the X button again. Now the game cancels the kick request, and when the striker gains control of the ball and stops moving, the pass never happens.

    To the untrained player, this is simply a broken experience. The punishing situation above teaches the player that the X button does nothing. However, eventually that player might learn the nuanced use of the pass mechanic. But this still causes trouble for me even though I understand the mechanic. Often I will press the X button to buffer a pass, but then while I'm waiting for the action I wonder "did I press the button hard enough?" and I'll press it a second time. Other times I'll mash the X button in a tense moment, only to realize afterward that I have no idea how many times I pressed the X button so I don't know if the last press meant Pass or Cancel Pass.

 

   The decision Konami made with PES was a more realistic soccer game instead of a game that responded instantly to player input like World Cup Soccer for the old school Nintendo. The interesting thing about PES is that it is still a highly regarded game despite it's lack of responsiveness. I appreciate the attention to detail of kicking with the left or right foot, how the placement and spin of the ball have just as much effect as the weather and team's energy levels. I agree with the decision to sacrifice instant responsiveness for more realistic kicks and sprints and nuances of the real game reflected in the simulation. The problem with PES is not the lack of responsiveness, it is the lack of feedback to the player.

    Imagine being at a fancy new restaurant and ordering food through a computer at your table. You press the cheeseburger button, the onion rings button, and the Guinness button while the computer screen shows you a message that says, "Welcome to fancy burger! press the buttons below to order!". Well, imagine that the fancy restaurant doesn't confirm your order until a cashier behind a curtain actually accepts the order at another computer terminal. Since your order hasn't confirmed your button pushes immediately, you would logically think that the order wasn't going through. Thinking that the computer isn't working, you might end up pushing the cheeseburger button 5 times before any sort of confirmation comes up, at which point it will say "5 cheeseburgers, 3 fries, 3 Guinnesses - would you like a shake?". The system works, but it doesn't fulfill the communication requirement of letting the person making the requests that their request has been logged and is waiting for execution.

    Like the above example, in games we omit the essential part of communication from our system. If our responsiveness is not instant, we must let the player know "action confirmed, just a moment". We've taken great strides in making games more realistic. Jumping, running, throwing, and virtually any action we can think of an avatar doing (besides maybe pulling a trigger) has some time cost now, and often we pad additional time in to get the transitions to look smooth.

    All PES needs is a UI element on the screen to let me know if the pass action has been buffered. Draw the X button image when true, and remove the image when canceled. I haven't even said the word yet, so here it is: Feedback. It's what makes games games and not interactive movies.

Intermission. New Job. New Location.

Just thought I would explain the 2 months of silence.

I took a new job at Big Huge Games just north of Baltimore, Maryland to work on a semi-announced RPG. It's been an exciting time since the last post; Saying goodbye to friends, family, co-workers, a wedding, a car accident, moving across the state, meeting new co-workers, catching up with east coast friends and family, and I think things are starting to settle a bit now.

Responsiveness, feedback, and iteration. Part one.

"Responsiveness" is a popular topic among designers lately, and I get the impression that the conversation is spreading. Our industry is focusing so heavily on looking good, that playability is taking a back seat to sub 60 frame rates and animation bound motion.

I understand that good looking screenshots and trailers attract people. And smooth, proper animations with weight and character are great to watch. But the last time I checked, we're in the business of making games. What sets games apart from photos and movies is interactivity. When we make looking good the priority, interactivity falls by the wayside.

And then some designer complains about responsiveness.

But haven't we already made this mistake before? In the early 90s, the industry was falling over itself on the buzz of interactive movie-games. With the introduction of the CD-ROM, games would be able to be made up entirely of full motion video with 16 bit audio. Everything that Hollywood had to offer could be made available with the added experience of interactivity. Maybe you remember such titles as Critical Path and Night Trap? No? How about Mad Dog McCree? This experiment has failed. I'll concede that this was fine for adventure games and puzzle games, where action on screen happened between player interactions (ie MYST, 7th Guest, Blade Runner), but the games where this is an issue are games that require constant input from the player.

So we find ourselves tripping down the same trend again. GTA4, Assassin's Creed, Tomb Raider, Mass Effect, Bioshock (360): All these games are running at perceivably slow frame rates, and all of these suffer from varying degrees of unresponsiveness. Do your own tests by running in one direction, and jam the stick in the opposite direction. You'll notice a distinct difference between the time when you hear the clack of the stick and when the avatar actually moves in the direction you commanded. For a scientific approach, see Mick West's post on Gamasutra.

We're working in a world where each piece of hardware and software is adding response time to every interaction, and every frame of animation in the name of fidelity is chipping away at the playability of our games. Designers need to place a stake in the ground early to mark the minimum bar. For some games like Devil May Cry or Okami, creator Hideki Kamiya expects that the animation bar to be at 3 frames, and the games he makes run at 60 fps. Maybe your game isn't as fast paced, but what you need to do is play the game and establish a metric. If your animation team is fond of interpolation (adding frames to transition between animations), play with different values and give the animation team a value that works. Play at different frame rates, and lock down that metric early (especially hard to do since you are most likely up against senior programmers and art directors on this one).

Every animator that I end up working with hates me for the first couple of weeks, and rightly so - I always feel like I'm dropping a bomb when I let them know that an animation needs to be 4x faster, or that an animation is simply unusable. In the end it's the animators that make the game look awesome, all I do is try to make it play awesome. However, when we're able to succeed at both, the result is better than the sum of the parts. In Part two, I'll go into methods I have used to marry the goals of fidelity and playability, and ways I've found to work harmoniously with artists, programmers, and animators.

For now, think about the game you are making or want to make. Think of the competitive bar, and where your game will stand in relation to responsiveness and fidelity. Most importantly, think about the player's experience.

Additive design

I tend to do this one a lot. In my quest for solutions that tie a game together, I naturally lean toward adding completely new mechanics that are completely arbitrary and contrived for the sake of adding meaning and balance. Part of this tendency in me is to put a visible stamp on my work. It's easy to point to an entire system that ties everything together and think "I did that". Whereas pointing to a piece of a piece of a bunch of systems that work well together is much more difficult to have personal pride in. Admittedly, this is a huge fault of mine, and as one of 7 kids, I should be better at sharing. Games, especially now, are the product of hundreds of people. So why should I favor my own ideas with so much nepotism?

In any case, despite my own tendencies to do this, I see a problem with additive design. We talk about iteration a lot, but I think often we mistake addition for iteration. Additive design lends itself to convoluted mechanics, and eventually confused players. Where the goal of iterative design is focused, intuitive, and deep.

Can't agree on a solution to your game design problem? I have just the answer.

I always hated showing my work in math classes. What a waste of time. I've noticed a similar tendency in... well, everyone when it comes to problem solving that causes even more wasted time, and sub-par solutions. I call it Solution Prescribing. It's a design vice, and should only be used in moderation.

In game design, and probably every other problem solving job, us humans are prone to say "here's the answer". Some of the more humble people will say "here's an answer". But inevitably, we go back and forth suggesting solutions until we feel the best solution has been put forth, or someone up top decides on the best solution. My issue with this is that the problem (or goal) has not been defined (or is only partially defined). Everyone has their own perception of what they're trying to solve.

Master producer, Sam Newman, puts it like this: "What is the problem that you are trying to solve?". These beautiful magical words, when spoken to any group or individual, immediately cut the crap and get straight to the point. I've seen hours, weeks, and man-months saved by this question. It can be used internally too to great effect. The nugget of truth that I've been able to pull from the process is that it's impossible to agree on a solution without first agreeing on the problem. The next time you find yourself or anyone prescribing a solution, make sure that you agree on the problem

bazooie's Top 10 Favorite Games!

M.E. has a fun post about her top 10 favorite games (defined on a purely subjective level). I really identify and agree with her observation of how her favorite games correspond to personal connections. It didn't take me long at all to come up with my top 10. So here are my top 10 favorite games in order of hours played (shortest to longest)

Maniac Mansion 2 - Day of the Tentacle: Frozen Hamsters! Time Travel! George Washington's Wooden Teeth! I fully credit this game with my knowledge of computers. My desire to play this game gave me the motivation to learn how to bend DOS to my will in order to get this game to play correctly on our 386 with 1 MB RAM. Oh how I bent it.

Space Quest 2: Vohaul's Revenge: I was the primary player, but it took my whole family to solve this game. I still remember my Mom, sisters and I spending weeks trying to figure out how to cross a bog with a man-eating monster.

We <3 Katamari: Boldly, definitely foolishly, I took this on my honeymoon with a PS2 as an attempt to get my new wife into games. Now Lindsay and I have fond memories of the music, and learning how to steer a katamari together (after much arguing on which direction to go). This game enhanced our communication skills!

Toe Jam & Earl: I loved playing this as a lad with my friend Jason Marlis, and even now I play with Lindsay. It used to be so hard to resist the urge to open every unknown present! I would always end up scrambling the gifts and dying early. The randomly generated worlds, and focus on escape rather than combat make this game still fun.

Halo: I hated this game at first because it was so SLOW compared to the PC shooters that I played. But Halo magically broke down the 'nerd' wall, and brought my roommates and friends into the hardcore gaming world. We had late night house meetings discussing strategies on Blood Gulch, and went through hoops and hacks to play online. Joyous celebrations, and loud arguments all stemmed from our experiences with this game.

Street Fighter 2: This game changed my life. I had a competitive nature already, but when SF2 came out, it gave me a community and a vehicle to feed my competitive side (turned me into a monster!). Despite being 10 and 11 years old, Jason and I could hold our own. That fact alone broke down a lot of self-esteem issues I probably would have had, and changed my paradigm of what age meant.

ATV2 Ice Hockey: This remains the only game that I ever worked on that I continue to play. The Ice Hockey mini-game in ATV2 has the perfect proportions of skill and randomness to make for one of the best competitive multiplayer games of all time. Patrick Connor and I have spent easily over a thousand hours playing this game head to head, and it doesn't get old. He just left to work in Maryland. I miss you, Pat.

Diablo 2: This was my first RPG ever, and it sucked me and my life away. This game taught me how to be efficient with my time. Seriously. I was the biggest slacker before Diablo 2. In fact, I stopped playing it because in the grand scheme of things, it really was a waste of my time since I didn't play with friends. Eventually, Pat and I had bots play Diablo 2 for us, and sold items on Ebay.

Counter-Strike: When I started as a tester at Crystal Dynamics, I was invited to play CS with the dev team during lunches. They were good. I sucked. As co-workers laughed and sent me screenshots of my avatar getting knifed and blown to bits (I'm looking at you Benny and Billy), they had no idea how much my internal competitive monster was stirring. I played religiously until I was top tier at work, and I was hooked from then on. Useless Trivia: I am one of the guys getting yelled at in the legendary song by Kurt Harland, The Terrible Mr Grimshaw.
 
Tekken Tag Tournament: This game truly is a part of me. It's competitive, it's technical, and plain fun. Without Tekken, I wouldn't be in the industry, or wouldn't have half the friends that I know and respect now. I've easily spent thousands of dollars and hours on this game, and I love it despite it's many flaws. It has become a method of communication between myself and anyone I play with: all over the US, in Korea, and in Japan. I started playing because it looked cool, and I continue playing because of the community.

 

Show me, don't tell me

Yes, it sounds like something a righteously angry significant other would say when you're trying to smooth things over. There's probably a nicer way to say this in the workplace that doesn't conjure up feelings of defensiveness and guilt...

I just wanted to document the merits of prototyping something as opposed to discussing at length what something might look or play like. Typically, designers like to postulate, theorize, discuss, argue, blah blah - we talk a LOT. Including my own desire to be always accurate, this can lead to some really long conversations about how to implement a particular system. Inevitably we end up talking so much that we could have developed the ideas on screen in the time we spend talking about how to develop our ideas.

Back when I was an aspiring graphic design student, I recall discussing next steps with my professor after a critique. I had a great idea on how to improve a particular composition and was describing how it related to my most recent work. About two sentences in, he said "It all sounds great - but I really can't judge until I see it. I need to see it." It was one of those mini-life lessons that 10 years later means even more to me when I think about it.

In the past few weeks I've been working in prototype pie in the sky anything goes land, and also in deadline driven get it done land. In both situations, I've noticed this tendency to debate being destructive to creative development. The only thing I've noticed that it improves is persuasive communication skills. In an effort to combat this tendency, many of us have committed to simply proving out our ideas in tandem; sometimes sacrificing our own biases to help someone else get their idea working. The end result has been absolutely amazing: discussions typically pockmarked with opposition and contradicting ideas give way to strong shared conclusions. Not only that, but the amount of trust and respect that is built between designers that originally had differing opinions only to reach a refined conclusion through this process is inspiring and powerful.