Playing Like a Designer - II: How to Analyze Game Design - Extra Credits

Hey guys, welcome back to talking about how to play like a game designer. We left off having talked about observing while you experience and getting past your learned biases. This week we're going to talk about what types of games you should play. Simply put, a good designer has played and can reference a bit of everything. I don't care if you hate football games or first-person shooters or RPGs or whatever. There's something to learn from everything. A good designer plays all types of games and never dismisses anything out of hand. You can't just look at FarmVille and say, "It's an awful game. I'm not going to play that." If you think there's nothing to learn from a game which a hundred million people played, you've got some rethinking to do. Now, I'm not going to lie to you. Playing these probably isn't going to be a fun experience for you. In fact, it might be excruciating if you're just playing from the regular player perspective. Being a game designer is work, but if you're playing like a designer, the experience will be edifying and you'll be a better designer for it in the end. You can learn just as much from a genuinely bad game as you can learn from a good one.

In fact, it's generally easier to learn from the bad ones. In a well-made game, all the elements are tightly sewn together in a well-designed hole. But in bad games, everything tends to be a little less cohesive and it gets easier to pick out and trace all the flaws. A designer never just says, "This sucks" or "This is good." Remember, one of a designer's principal roles is that of a communicator. Whenever you find yourself describing something simply as lame or cool, try to really drill down and express why those elements in a game were positive or negative and how all the pieces fit together to deliver the experience they did. If you can't do that, go and replay the experience till you can. All right, we're past the high-level stuff now, onto the nuts and bolts. The first thing a designer does when sitting down to a new game is check out all the menus and press all the buttons. This gives you a little bit of insight into what the game designers felt was the most important. The most accessible keys or buttons should generally be mapped to the actions that the designers felt were the most important, the actions that they're having the player do the most often in the game. The menus will tell you what features the designers felt needed to be adjustable because they couldn't agree on a single best option. This can be for technical as well as design reasons. Difficulty is often one such feature,

but so is gamma. It varies. Next, the designer looks for first order optimal strategies. First order optimal strategies are gameplay choices or strategies with a low ratio of skill in to power out. Or, put a little more simply, first order optimal strategies are tactics which are very powerful, but are easy to do. Noob strategies, basically. These are the things like the hundred hand slap in Street Fighter, the noob tube, the zergling rush. The reason you look for these is because they're one of the most important things for a designer to understand. Players will find one of these first order optimal strategies and just use it over and over again unless something forces them to do otherwise. PvP games naturally force players to evolve past first order optimal strategies, as they're never truly the most powerful tactics in the game. They're just the tactics with the lowest skill to power ratio. In a competitive environment, players naturally develop their skills and constantly adapt new techniques in order to beat their friends. But many single player and co-op games don't have that constant drive to adapt, which means a first order optimal strategy Okay, we've seriously got to find a shorter term for that. Hmm. First order op What about food strategy? We're going with food strategy. Anyway, a food strategy can

completely break a single player or co-op game. If the designer creates a food strategy in his game without realizing it, all the depth he worked so hard to build in there is just going to go completely unnoticed because the player's likely to just hundred hand slap their way through all the levels. But food strategies can also have positive effects, and these are equally important. For example, the noob tube in Call of Duty is there to give inexperienced players a fighting chance. Without it, new players would just be jumping into a meat grinder, dying left and right at the hands of better equipped veteran players. Spawn, die, spawn, die, spawn, die, quit. The noob tube makes the novice player feel like they're at least a little competitive and allows them to get over that initial hump and get to the point that they can actually hold their own against the veterans. Yeah, the vets may gripe about tactics like these, but the benefits outweigh the negatives. The noob tube's negative impact on high-level play isn't going to be enough to make somebody who's played for hundreds of hours quit the game, but getting killed 30 times in a row before you can even get a feel for the controls, that just might. Food strategies give new players a point of entry, which ensures that new players will stick around long enough to get good, which in turn ensures that veteran players will have a large and evolving

community to play with. As a designer, we must be aware of food strategies and take careful note of where they're being used intentionally versus where they're simply the result of sloppy design. Wow, okay. We better move on before this turns into a three-parter. So, after hunting for first-order optimal strategies, the designer then begins looking for breakpoints, places where the game doesn't function as intended. The first of these are systemic breaks, places where the interplay of systems combines to do something that the designers didn't intend, something that functions directly in opposition to what appear to be the design goals of the game. Example, James was once playing a trading game, I won't mention which, where if you bought the ship with the most cargo room and got all the cargo expansions for it, you could dock at a port and buy so much cargo that you actually inflated the price, allowing you to sell it back for a big profit. Infinite cash, basically. Kind of a game breaker. But, these systemic breaks can be much simpler than that. Take the Final Fantasy series. I consider the way that money works in most Final Fantasies to be systemically broken. Why? Because of the inordinately vast sums of gil you acquire just by playing the game normally. To progress past any given area in a Final Fantasy game, you need to grind for experience. The only way to get experience is by killing monsters,

which means that the designers can make a reasonable estimate of how many monsters you'll have to kill before you're ready to progress. But, monsters also drop gil, and killing that many monsters almost always leaves you with so much gil that you could dive into it like Scrooge McDuck. Since the designers know roughly how many monsters you're going to be killing, they could easily balance the amount of gil monsters drop to ensure the player has roughly the amount of gil he's going to need for that area. Now, obviously, it's not a problem that ruins the game experience or anything, but it's a good example of the kind of system breakpoints to look out for as you play. Next, the designer looks for technical breakpoints. This is any point where the technology breaks down. When you clip through the world geometry, when the camera gets stuck in a corner, when your character decides to spontaneously turn inside out, there are two very important reasons you need to look for these. One, to understand which bugs destroy a user's experience. The sad truth is that you're never going going able to avoid all of these problems. It's damn near impossible to create a 100% bug proof game, so as a designer, you need to understand how these bugs impact the user, so you can know which ones you can afford to leave in and which ones you need to really, really focus on fixing or designing around. Which leads us to two. Most of

the bugs you find in a game aren't just there because the dev team sucked. Most of them are in there because a series of design decisions actually made these bugs the best possible solution the team could deliver within their schedule and budget. This is especially true of camera issues. Many teams lock themselves into a bad camera from the start with their design spec alone. As a designer, you look for these things and trace their roots in the mechanics so that you can learn how to avoid them yourself. As we've mentioned, a designer builds for production. They make their choices in order to build a game with a real team in the real world. So a designer is always on the lookout for interesting ways other designers found to work around the limitations of their technology, team, and budget. So when you're playing these games, look for ways that the camera was constrained so that the team didn't have to build or render their models to be viewed from certain angles. Did the game choose to go with a hovering robot instead of a guy with a gun so they wouldn't have to rig or animate a bipedal enemy? Practical solutions to overcome limitations. Look for them when you play. One of the best examples of this is the first Silent Hill. The team wanted a level of graphical fidelity that the PS1 simply could not deliver. So one day someone said, "Let's just add fog and reduce the player's clipping

plane to like 5 ft in front of their face. That way we don't have to render the rest of the scene." And with that, a franchise was born. Another good example, EVE Online. We're totally running out of time here, but give it a look-see sometime. The game is filled with neat little production tricks. Lastly of all, the thing you have to remember as a designer is that you are playing to learn. This means that you're only playing most games for maybe an hour. Of course, some games will merit several hours of play, and occasionally you'll find that very rare game worth playing all the way to completion because it's packed with learning material throughout. This is the only practical way to experience a truly broad range of games. The majority of games reveal all of their systems in the first few minutes of gameplay anyway, so a good designer can understand their interconnections rapidly and move on to the next interesting treasure trove of play. Don't worry, this won't take too much time away from your regular play schedule. Even if you just drop one 80-hour RPG from your to-do list, that'll give you time to absorb knowledge from 60 to 80 other games that you would otherwise have never touched. Trust me, as a designer, the trade-off is worth it. Well, that's about all we got. Go to it, future designers. See you next week.