Chances of failure (design, long)

Started by
-1 comments, last by JSwing 22 years, 12 months ago
A player attempts an action. We as designers decide the circumstances, chances of success and failure. This post is pretty basic stuff. Most folks here are probably well past thinking about these things, but there are plenty of newbies around. And some of the oldies forget the basics too. The important idea is to remember these decisions as we make a design. I chose the title ''Chances of failure'' because it''s easy to get caught up in your vision of how the game will play and forget to think about how it plays when it doesn''t go right. You know that you''re really designing if you are double-checking your game mechanics for failures. Automatic success Player meets certain conditions then they are automatically successful. If they don''t meet the conditions then they fail. Typical example is a key-lock puzzle. If the player has the key, they succeed, else they fail. Good use: As a reward for perceptive or creative players, allowing them to shortcut a risky or costly alternative. Rather than a single pass-fail criteria, the player has a variety of conditions that can be met in order to succeed. Example: crossing a large pit. The default might be a long side trip, or climbing down and then up the other side. A perceptive player might notice a narrow ledge that can be used to cross, a creative player might fashion a bridge. These activities would be automatically successful as a reward for good gameplay. So-So Use: The standard key-lock puzzle. Sometimes this is necessary, and sometimes it''s a good choice, so I include it here. Poor Use: Over-using a key-lock puzzle design to unduly restrict players. Applying arbitrary limitations to cover up other holes in the design. Always Consider Failure Automatic success also means automatic failure. If you''re not careful, the player can get stuck or be left frustrated. Your players will eventually get somewhere without having the necessary conditions. Hints are good, indicating not only where a player failed, but where the solution might be. Another option is to always have alternate solutions. Either have different sets of conditions for success, or an alternate route with a Cost. If you find yourself trying to prevent a failure by restricting the player''s path, say by adding more key-lock puzzles, then your design is poor. At some point your players will fail. Just make sure they don''t get stuck, unable to go backwards or forwards. This does not preclude ending the game (player death) as an option. Random chance: The random number generator is used to decide on success or failure, usually weighted by some stats in the relevant game tokens. A typical example is combat: Generate a random number and apply some math based on offense and defense values to calculate the result. Because of the random factor, it is almost always possible to fail. The Good: A system that balances the need for randomness versus the player''s need to apply strategy. A distribution system (linear, bell-curve, whatever) that is evaluated for flaws at different points of the game. The So-So: Standard RNG number used for opposed rolls (like combat), a system slapped together with a few holes for munchkins to abuse, or a system used far below the level of player scrutiny (you can get away with more). The bad: This is overused in pencil and paper RPGs. Any significant action had a random roll assigned to it, whether or not it made sense. We are left with this burdensome legacy and it causes trouble. If everything requires a roll, you''re probably overdoing it. Always Consider Failure Player attempts action and fails. Then what? Chances are they will try again. And again. And again, until they succeed. If there are no other considerations (risks, costs, etc) then this becomes tedious. They can simply try until they get bored or until they succeed. If there are other costs or risks, then the ever-present chance of failure on account of our random number generator means the player will eventually pay the cost through no fault of his own. This means that the cost should not be excessive (i.e. losing the game) or else you risk discouraging the player. The player''s strategy is typically limited to maximizing his chances. This implies that the player choices need to have significant weight in determining the outcome. If the weight of the random factor far exceeds any contributions from the player''s choices, then the player''s choices become meaningless; they are reduced to watching rather than playing . If the player''s choices far outweigh the random factor then the game reduces to an absolute success/failure situation above; don''t waste time with the random number if it isn''t going to be significant. If the (player-dependent) values that weight the results have a large range over the course of gameplay then the design needs to be considered at different points to make sure the system remains balanced. What happens to your results when a very strong game token attempts a very easy challenge (or opponent)? Strong versus difficult? Weak versus easy? Weak versus difficult? Strong versus slightly stronger? Do the results still make sense? There also appears to be a blank spot in most designs with failure results. You swing a sword at an opponent. If you succeed, then the game proceeds to along a complicated path of determining damage and whatnot. If you fail, then nothing. Your turn ends and you wait around until you can act again. It seems to me that this is ripe for some development, but I haven''t thought enough to fill it in yet. Cost: Results of the action depend solely on resources allocated to that action. This may be a simple fail/succeed, or it may be a measure of success, or a rate. Typical example: Allocating production in a strat game. The good: This is good when the player can''t predict the long term effects with absolute precision, but instead is encouraged to learn through experimentation. Also good when there is no single optimum point, and the player must adapt to different circumstances. The player never has enough to do everything he wants, but always enough to do what is needed. The So-So: The player''s short term cost-benefit ratios are obvious and there are no significant long term differences. The player has a single optimum path depending on the goal, but a variety of goals at any given time. The Bad: The cost-benefit ratios are not balanced between the different options, leaving some parts of the game ignored and others greatly abused. The resources are so limited that the player has no room to explore or make mistakes. Always Consider Failure One mode of failure is a sub-optimal approach. Players will goof and try dumb things. They will waste resources or miss opportunities. This needs to be planned for. How much slack is in your system? Do the resources (whether rocks or action points) renew and allow the player to try again? On the other hand, is there too much slack? Would optimum play result in massive accumulations of unusable resources? Another failure occurs when a player runs out of resources that they think they need. Whether from poor choices, bad luck, or strong opposition, the player will not have enough to meet the costs of what they need to accomplish. Plan for this eventuality. This does not preclude ending the game (player death). Sometimes there are not very many ways to spend the resources in question. In this case, it''s almost a waste of time to ask the player to repeatedly choose an allocation. Consider a different approach where the player can define a general strategy via script and let them focus on other decisions, or shortcuts to speed up the game. Player dependent: The success or failure of the action depends on something external to the game, such as player reflexes, eye-hand coordination, or knowledge. Typical example: any arcade game. The good: The design makes solid use of the user interface. Players with excellent skills are rewarded with bonuses, and players with less than excellent skills still enjoy the game. The challenges are engaging and require some thought or strategy as well as quick hands. The So-So: The game was designed primarily for one platform and does not adapt perfectly to another, but configurable controls mitigate the flaw. Most actions can be accomplished by an average player but there are one or two places in the game where they will get frustrated. The challenges are a mixed bag. The Bad: The game actively hinders the player. This could be poor camera positioning or clumsy controls. It could also be a challenge that doesn''t identify itself, or obscure trivia that most players would not know. Endlessly repeated actions with a high cost for a single failure (ex: jumping puzzles). Always Consider Failure: If your game depends on external hardware or wetware, assume that people will have a wide range of capability. Players will fail to make the leap. They will fail to shoot straight. What does this cost them? If it might lose them the game, then take that into account when you design the save/load system. If the cost is small (like ammo) then you only risk boring or frustrating the player with repeated failures. Player failure provides direct negative reinforcement. The player has failed the action because *the player has directly failed*. This can get very frustrating very quickly. Some ways to balance this that I have seen in games: 1) Give them hope - maybe they just missed a clue that makes the task easier. 2) Tickle their desire - let them peek ahead and build an expectation, whether a cutscene or a window to the area they are trying to get to. 3) Prod them with guilt - If Lara falls from a great height, she screams all the way down and hits with a rather sickening sound. If a player has no chance of winning the game because they are too slow, then you have just lost a sale. Obviously there needs to be some lower limit to remain a challenge, but your goal is to challenge, not frustrate. Consider having multiple paths of varying difficulty. A technically difficult option would be a system that adapts to the player. Which system to choose? I don''t know of any good rule that says for type of action X, choose method Y. A lot of folks would traditionally break these by genre, but that''s not such a good idea. I think most games should use more than one, especially for complex mechanics. You should use the system that''s right for the game you are building. I''ll return to the example of the large pit. Let''s take our large pit and add spikes and debris in the bottom. We''ll also add a few hidden rats under the rubbish. From there we can design it whichever way makes sense for the game. Are there time constraints to crossing the gap? Is there some enemy that acts to drive the player towards one side or another? What sorts of resources (objects and furniture) have you populated the environment with? Is the game going to have a lot of pits, or is this a special challenge? * Player fashions a bridge or notices a ledge: Absolute success (condition = player behavior), Cost if the player has to sacrifice resources to build the bridge. * Player climbs down then back up: The climbing is trivial, so it should be an absolute success (always). There might be random number system to see if the player awakens the rats, or they could always wake up. Fighting the rats would be difficult, but not impossible. It''s easiest to use a random number combat system because they are easy to tweak with modifiers, followed by a player dependent action (which may have problems getting the camera into position). * Player leaps across the pit: Player dependent action, followed by Absolute success (condition = proper starting point). * Player uses special ability/tech/magic to cross: Cost if recovery is non-trivial, Absolute success (condition = has ability). I''m sure you can think of even more options. There is no reason that you can''t use two or three options for any given challenge, except to avoid design bloat. What are the penalties of failing to cross the pit? For an absolute success, then if the player will go no farther, unless there is another method to cross. For a random roll (combat), then the failures would be accrued damage. I guarantee that some player will die from it, even if it''s only from bad luck on the die rolls. Is it fair to have a player die from rats that were hidden? Maybe the rats are weak, so would only be able to finish off a character who was almost lost anyway. If you think it isn''t reasonable then you need to design around it (maybe disease instead of damage?). For player dependent action, the failure is falling into the pit or dying from the rats. This could mean game over. If pits like this are common, that means a lot of reloading. The penalty could instead be a health reduction, coupled with no healing on the level. The player gets past the pit, but uses up a ''life'' in the process. Or maybe slowing the player for the next N minutes from wounds? For a cost solution, what can the player do if they are out of resources? Are they doomed? Keep thinking about failure, and focus on designing the right solutions for your game.

This topic is closed to new replies.

Advertisement