adventures in game design

moving the blog

Two heads are better than one.

I'm moving the blog to http://www.practicalgamedesign.com/ where I'll be posting with my buddy Patrick. We're good friends, and realized that our blogs were aimed at the same thing, so we decided to join forces.

This means more posts more often! That's good news for everyone. 

Mess Effect

 

This record snowmygawd blizzard gave me plenty of time to play games, and I used pretty much all of that time on Mass Effect 2. I think it's a great game, but I have a lingering thought that frightens me the more that I think about it...

How did this game get a 96 out of 100?

Metacritic currently shows an average rating of 96. For all its cinematic and story polish, this game sure has boring, exploitable, and degenerate game mechanics. 

• The AI has a fascination with hiding "behind" (that's a liberal use of the word) cover in the most awkward and inappropriate times. Difficulty is achieved by giving enemies ridiculous amounts of armor, shields, or barriers, which in the end just drags the badly played battles on longer - especially considering that your abilities for taking them down all use a cooldown timer. The only interesting enemies I fought were husks, and that's because they at least put pressure on me and my squad.
• 60% of the weapons are useless. Only the sniper rifles and hand cannons are worth shooting with.
• Controls are buggy. "Beading in" or scoping with the left trigger repeatedly fails if another action interrupts it. I often found myself holding the left trigger, but having to release it and hold it again in order to properly zoom in.
• No grenades! In a cover based shooter, you need tools to flush the enemy out. I had a drone, but why would Bioware remove this feature from ME1?
• And scanning planets? Presented well, but man that's a boring way to get upgrades. I'd expect a mechanic like that in a subscription game where spending more time in game equals more profits. Dear Bioware, I already gave you my money. Don't make me sit through this sorry excuse for a mini game to improve my ship.

So if the game is so blah, why are journalists giving this game such a high score?

• Choices matter. Mass Effect 2 is the most advanced incarnation of a Choose Your Own Adventure I have ever witnessed. There is a mountain of story content within this game, and each dialog choice really seems to make a difference to how the story is told. I found myself laboring over which dialog choice to make in the most insignificant areas.
• Dialog is second to none. The acting, camera work, and animation are better than any other game out there. The resulting experience reinforces the illusion that each character is real, living, and has a direct influence on the unfolding story.

But I believe there is something else going on here. The good points about this game don't overshadow the mediocre shooter mechanics enough to warrant 4 points from a perfect game. Call me cynical, but I think that because journalists are naturally biased toward writing, they give a game that is so focused on their craft a perfect score and are blinded to the poor parts of design. Likewise, I'm probably reacting to the worse parts of the game because of my designer nature.

At the end of the day, I still loved this game. I'm baffled at how they will make the third installment and keep the same level of choice-dense quality.

Five simple steps to designing melee attacks

Designing melee attacks has been part of my weekly routine for a while now, and I think it's time I sit down and distill the process. Here are the steps, along with an example.

First, I sit down and identify the key points of the attack. What is the primary purpose? Is it a heavy or light attack? Is it part of a chain or series? Does the previous pose matter? How long should it be?

• So lets say that we're implementing an overhead katana attack. It's a one-off attack, but it needs to come from the base-combat pose. This attack should appear powerful, as if the character is slicing through a tameshigiri

Second, we get it to the animators! The important part of the above step is to know ahead of time what is the main thing that needs to be communicated with this attack. The animator will inevitably put his own creativity into this, and needs to know what to keep in mind. I try to act out a couple swings myself, but always try to end with "the main thing is ____". Props are great for this part.

• Makeshift weapons are great props. A nerf sword, piece of PVC pipe, or practice kendo sword works great for this attack. The most important part is to convey the notes we made above. So as I practice a couple swings in front of the animator, I repeat the words that matter most: Powerful, slicing, and from the base-combat pose. As soon as we get that part communicated, get that prop in the animator's hand! He's much better at imagining this stuff than you. Let him work it out. Some animators like to draw the poses out first too.

Third, we have the animators only work on three poses. This is called pose-to-pose animation. What we want to do here is not waste anyone's time. The animator's best use of time right now is getting 3 poses on screen for you and anyone else to critique. The Anticipation, Actualization, and Follow-Through. In fighting game terms, this is the Wind-up, Hit Frame, and Recovery. Eric Williams has a great blog post about this. This lets everyone agree quickly on the framework of the move.

• In our example, we happen to be designing Haohmaru's A+B attack from Samurai Shodown. Here are the poses we end up with:

• Wind-Up/Anticipation  
• Hit Frame/Actualization
• Recovery/Follow Through  
   

Fourth, We plug these poses into the game, hook up damage collision, the necessary input sequence, and the scale the timing for each pose so that we get a basic timeline for the motion. We then report the timeline to the animator in terms of something he can use when he animates the in-between frames. We might also report if anything isn't quite right, like if the sword is going over a short enemy's head. It's very important that the designer has the tools, or the knowledge and authority to tweak and tune the timing of attack animations. After all, you're responsible for making the game play correctly, right?

• So using our example, we'll set it up so that it does damage appropriately, causes the right hit react on enemies, and then we'll adjust the timing between the poses until it plays about right. Once we're set on the timing, we'll report back the animator with something like this: "Hit Frame should be at frame 14, and recovery should end at frame 34".

Fifth, the animator makes everything look awesome using the guidelines we've set. He plugs it into the game, and we play with it and scale the timing one last time.

• We might notice that once the animation is complete that our original timing doesn't work as well now that the animation is fully keyframed. We fine tune the timing this time so that it looks and plays as good as possible. And we're done!

 

These images were taken from Fighters Generation. It's a great resource when you need ideas.
 

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.