     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Decision-based Gameplay Design Examples Examples are always useful, so I'm going to give some, just to elucidate how often decisions have to be made in a good game. My first example will be a round of a decision-laden game that many people are familiar with: Counter-Strike. Our player, Bob, is playing in a 5-on-5 game as a terrorist on the level de_aztec. Bob joins the game. He chooses to join the terrorist team. As the current round finishes, he gathers some basic information about the game. The scoreboard tells him which team is winning, the winning record of the teams, and which players are best. The terrorists have been losing. He notices that a counter-terrorist player named Charlie is dominating the central open area of the map with the powerful AWP sniper rifle. Charlie has a lot of kills, which means he is a particularly good player and has likely been using the AWP in the open area for some time, with a lot of success. Charlie finally kills the last terrorist and the next round begins. Bob quickly analyzes the situation and must make a decision as to his general strategy and chosen route for the next round. While making this decision, he factors in his own team's apparent lack of counter-sniping ability, his inability to afford a flashbang or powerful weapon, Charlie's likely future presence covering the main open area, his own particularly high skill level at close combat, and a variety of other factors. After one second, Bob decides to take the rightmost route across the bridge, avoiding confrontation with Charlie altogether and placing him in an area that hopefully allows him to use his close-quarters combat skills. His most difficult task will be making it across the bridge alive, since he can't afford long-range weaponry. Once he is across the bridge he will be in a close-quarters-combat area, where he will have a skill advantage. The risk of crossing the bridge is significant, but Bob's alternatives are probably worse. Bob spawns. He can only afford basic armor and an MP5 submachine gun - a cheap and utilitarian weapon that is useless at long range. His team moves, and he moves with it. He is at the back of the group. Three members of his team go through the door to the open central area. Bob watches the death announcement as Charlie immediately kills one of them with the AWP. Bob expects the other two to die. However, just as Bob is about to split off towards the bridge route, Charlie is unexpectedly killed by Bob's teammate. Circumstances have changed. Bob must immediately re-evaluate the situation. He is accompanied by only one other team member in his assault on the bridge; less than he expected, which will make it harder to make it across the bridge into his preferred close-combat territory. Also, Charlie's sniping skills have been removed from the equation, making the open central area a much more attractive route. There is also the chance that Bob's dead teammate dropped a weapon superior to his own. Bob makes the choice to abandon the bridge route and join his teammates in the open area. He passes through the large double doors into the open area. His two teammates are 20 meters away, in open territory, as is the dead teammate. Indeed, the dead friendly dropped an AK-47, a much superior weapon to Bob's MP5. The teammates come under weapons fire from an enemy position on the other side of the area. Bob must now decide whether he wants to attempt to retrieve the AK-47 lying out in open territory. This is a complex decision, and Bob will make it in less than one second. Bob must think relatively far ahead to consider the various possible outcomes to either side of this decision. If he doesn't get the AK-47, and his teammates die without his support, he is in a very disadvantaged position, since he will be fighting at most likely 4 on 2 or 3 on 2, with only an MP5. However, if his teammates win the engagement, Bob can simply grab the AK-47 in safety after the fighting is over. He will be able to support the team as they plant a bomb in the open area, and will have a more powerful weapon for free if he survives into the next round. I'll leave it to the reader to consider what might also happen if one teammate dies and the other flees in the opposite direction, if one or both flee towards Bob, if a teammate makes it close to Bob and dies, leaving a weapon near Bob, and so on. There are obviously a lot of possibilities here, and this is a situation that Bob doesn't know much about. If Bob was fighting in a clan match with friends he knew well, the system would be much more complex since his decisions would take into account the specific skills and behavior traits of each of his teammates, and, in case he had studied the other team's record, perhaps his opponents. All Bob really knew about this match was that his team was losing, and that Charlie was a good sniper. Imagine the exponential increase in complexity had the match involved nine known friends and opponents, with pre-discussed tactics and strategies. I hope that this abbreviated discussion of the first 15 seconds of a simple Counter-Strike match, not even including any direct contact with the enemy, has made you appreciate just how complex and numerous the decisions in a good game are. Also, note that the last two decisions, whether to change routes, and whether to grab the fallen AK47, happen within 3 or 4 seconds of each other, and are both made within one second. Both decisions, as obvious above, are quite complex. Counter-Strike is a very good game when it comes to decision generation. Any game of Counter-Strike, analyzed deeply, becomes a series of extremely complex decisions made at intervals generally between half a second and five seconds. Decision Recognition, Evaluation, and Design Game designers need to not only understand how decisions create a computer gaming experience, but also need to be able to create an experience that includes lots of unique, difficult decisions with strong feedback. Creating good decision-based games requires three abilities: The ability to recognize a decision point, the ability to evaluate how fun a decision is, and the ability to design fun decision-making play without compromising other aspects of the game (i.e. without requiring lots of new assets or making the game too complex and difficult to learn). 1. Recognition The first step is to recognize all the decision points. This is not as easy as it sounds, especially in a well-designed game which presents decisions very frequently. When reading a design document, try to imagine playing the game. You are essentially emulating the gameplay in a very inaccurate way using your brain. Think about what's going on, what you know, what you don't know, the challenges being presented, and the rewards sought. Go through the gameplay, step-by-step, instead of imagining the gameplay in an abstract way, or only considering the most interesting parts. Skip nothing; what you skip will most likely be a boring decision void. Get a feel for how much real time everything is taking. Finally, while doing all of this, you must recognize the decision points as the design presents them. Develop a feel for how often decision points come up. If your game is based on gameplay, but isn't presenting a lot of decisions, you have a problem and you need to re-evaluate some aspects of your design. The same process can be more easily applied to a game that is actually functioning, since one just has to play the game with an eye on the choices they themselves are making. Committed designers will pause the game whenever a decision presents itself and note it on paper. Notice how often you are pausing the game. It should be very often. 2. Evaluation Once you have an idea of how many decisions the player is making, and what they are, you can begin by evaluating those decisions. Consider each decision point separately, and determine how difficult each decision is, and how likely it is to recur. If the decision is easy it is worth little. If it recurs a lot, it becomes easy and thus is worth little. Each decision must also be evaluated in terms of cost of implementation. To implement a decision system takes a certain amount of time spent by members of the development team. Many decision-creating systems also suck up CPU cycles. Another very important cost that can be associated with a decision system is the complexity that it adds to the game. A game element that requires the player to know something, or have some skill, or at worst, bind and memorize a key or virtual button, is a game element that is costing something.
One example of a bad system in this regard is one that thankfully never made it into a game. During part of Half-Life's development, the player had the ability to put on or take off his HEV suit helmet. The decision as to whether to change the helmet was generally not very difficult, so it was worth little. This system required coding, code maintenance, and a key bind and memorization as well. Half-Life's designers wisely evaluated the helmet system and tossed it since it wasn't performing from a cost/benefit analysis. An example of a costly system that was worth the cost can be found in any FPS game: the ability to fire a weapon. Players must bind keys to select weapons, fire one or more fire modes, perhaps to reload or change something about their weapon. They must also learn to shoot. Designers need to model and animate guns from first and third person, code them, test them, balance them, and so on. This is a very costly system. However, it is worth the cost because of how many ways the designers can and did use the player's ability to fire a weapon to create decision points. Designers need to carefully evaluate decision costs and must have the discipline to cut game elements that are costing more than they are worth in terms of interesting decision creation. 3. Design Designing decisions is the trickiest part of the process, because the very nature of good decisions is that they cannot be directly defined. Decisions placed directly in the game will either recur too often and become non-decisions, or will only be seen a small number of times. An example of a directly-placed decision would be a situation where a player is presented with two separate attack routes which were both explicitly designed. One route will inevitably be more advantageous for any given player's playing style. Once the player tries both routes, he learns which route is better. Thus, if the exact same routes are presented to him again, this becomes a non-decision, and the player's brain becomes disengaged. All explicitly-designed decision points have this problem of staticity. The solution, of course, is to create a gameplay system that dynamically generates emergent decision points. The goal with emergent decisions is to avoid explicitly defined decisions, and instead create a set of rules, characters, elements, and interaction rules, with a defined goal, such that interesting decisions will emerge from the system. Let me make this very clear: Game designers should rarely be designing decisions directly. The job of the game designer is to develop gameplay systems that present emergent decisions. Only emergent decisions can be unique over a long period of time. Static decisions cannot be relied on to provide gameplay interest, though it should be noted that they cannot be eliminated altogether. Designing the dynamic decision-generating system is the game designer's greatest challenge. I'll leave this to another article. Closing Thoughts Decision making is not the only thing that makes a game. While a game depending primarily on its interesting decisions can be entertaining, good mainstream titles must also incorporate role-playing, socialization, joy of creation, or any of the many other aspects that make good games. Gamers want to make decisions and see results, but they also want to socialize, imagine themselves as fighter pilots, build gleaming cities, or create powerful personas known throughout the land. What is unique about decision-making among all these elements is that it is one of a very small set of elements that are unique to gaming. Only forms of entertainment that contain decisions are called "games", including sports, board games, videogames, or even game hunting. One could then say that the opportunity for the player to make decisions is what defines a game distinctly from non-interactive forms of entertainment. The opportunity to give the player decision-making capability is what game designers have and what Steven Spielberg and Tom Clancy wish they had. Understand this opportunity, and use it to its fullest. If decisions aren't part of your game, you should be making a movie.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|