adventures in game design

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.

open worlds without meaningful player choices

Assassin's Creed has taught me yet something else: The more open-world you are creating, the greater need you have for varied and interesting systems gameplay.

I don't have a definition handy, but if I had to define systems gameplay on the spot, I would call it "the set of rules and actions that the player interacts with in a game".

Let's quickly sift through a few examples, and rate them at Low, Medium, and High for "Openness" and "Systems Density"

GTA 3 Series
It really doesn't get more open than any of the GTA titles. The systems include an elaborate and varied vehicle system, a varied combat system, dozens of mission types, an economy, and an escalating warrant star system, with underlying systems like stunt scores, and even gang territories to create positive feedback loops that all tie the game together.
Openness: High
Systems Density: High

Assassin's Creed
There's an awesome openness to this world, and it's probably the best game that features a player who is primarily on foot in an open world. Most of the systems work is visible in the movement of Altair, while impressive, doesn't offer much meaningful choice to the player. Additional systems include a great combat system that sadly creates a negative feedback loop, and a few mission types.
Openness: High
Systems Density: Low

Bioshock
Bioshock is not as linear as a side-scroller, but as for level progression and layout, it falls into the low category for me. The underlying systems are not too numerous, but they offer a lot of diversity of choice, and they all feedback into each other. Main systems include a deep combat system, tonics, plasmids, camera research, and hacking.
Openness: Low
Systems Density: Medium

Tony Hawk's Pro-Skater Series
Openness: Medium
Systems Density: Low
THPS has open levels, but the size of them keeps me from placing this in the high category. Systems used are limited to about 4 trick types, a good scoring system, and a skill-development system.

All in all, it's really the 'bad' example of Assassin's Creed that ends up helping my argument the most. I strongly believe that the addition of an economy, and a positive feedback loop to combat (or hiding) could have harvested a metacritic score of 90 or more for Assassin's Creed as opposed 81 (metacritic.com).

Knob Twiddling. We all love to do it.

Sometimes, I catch myself tweaking values just for the sake of tweaking. Surely, most systems designers probably do this - and in most cases it's probably harmless. One of the pitfalls I've come across with this addiction to tweaking parameters is this:

I tune parameters because they are there, without considering if they fit the game in the first place.

It's so easy to get caught up in the simple fun of changing values and often I forget that maybe - just maybe - I might be over-designing. Let's look at one of the most common examples - guns.

When tuning a pistol for an FPS, a typical list of tuning parameters might include:

• damage
• firing speed
• reload time
• clip size
• ammo type
• accuracy
• recoil effect
• damage fall off
• bullet drop
• loudness

Reason 1: The tuning parameter isn't appropriate
Before diving into the tuning, consider whether some of these categories should even be used. For instance, if the shooter you are making is for a casual audience, then you probably don't need bullet drop, as accuracy tuning and damage fall off gets a similar effect without complicating the tuning.

Reason 2: The tuning parameter conflicts with others
Does one parameter directly conflict with another? Some games include a reticle 'kick' where the effect is that the camera angle is nudged up slightly with each shot. This feature can amplify the effect of any accuracy tuning. It might be better for your game to only use one of these variables. If not, you may want to use a graphing tool so you can quickly see how adjusting each value affects accuracy over time.

Reason 3: The tuning parameter adds 'bad' ambiguity.
Many games have weapons that randomize damage values between a min and max range - why? I can understand why a D&D game uses dice rolls: to simulate accuracy, recoil, etc. But if your game already includes accuracy, recoil, and every other possible tweak, what is the point of random damage?

Another example of 'bad' unpredictability is a damage ramp for explosive weapons. Grenades may have a max damage at the center of a radius, and a min damage at the end. But in practice, this gives a sliding scale of damage where it's difficult for both you and the player to determine at which distance a grenade will kill an enemy. I argue in these cases that it's better to have damage steps rather than ramps - even that a single damage value for the sphere is better.

I wonder if games that embrace ambiguity are using it as a sort of 'blur effect' to cover up potential oversights and poor attention to detail.