Patterns in RPG

Just like any other technical project that might have patterns defined, an RPG can also utilize similar patterns that have been documented by Whitson John Kirk III in his book titled Design Patterns for Successful Role-Playing Games.

Note

Note: Whitson was inspired by the book Design Patterns: Elements of Reusable Object-Oriented Software. His objective was to see if any special patterns existed in existing RPGs, and he approached this by examining specific patterns in successful games in the genre to detect and identify them.

In this section, we will be looking at some of the design patterns that have been identified, and that can be utilized for your own games.

Anytime you start a new project, regardless of what type, you need to have some clear idea of what exactly it is that you are trying to accomplish. This is even truer for designing a game. Since designing a game has many different components to it, you will need to identify what your game is going to be about. Some questions to start the thinking process are as follows:

• What are you trying to accomplish?
• What mood are you trying to evoke?
• What do the characters do?
• What do the player or players, in a multiplayer environment, do?
• What kind of activities do you want to reward and what kinds of reward do you want to provide?
• What age group does your game targets?
• Is your game going to have sequences?
• Will the game and the story extend with supplemental assets?

These are all important questions that will affect the design of your game. As you read this chapter and the book in general, keep a pen and paper handy so that you can write down all ideas that flash into your mind. This way, you can keep track of all your thoughts, and if you need to expand on them you can do so at a later time.

 

 

Terminology

Every discipline has its own terminology. The following is a list of terminology that is used in RPG games. It is a good idea to take a moment and study them, to expand your vocabulary or to refresh your memory:

• Attribute: A gauge that is a common characteristic, a commonality.
• Character: A person in a game portrayed by a player, including, possibly, the Game Master.
• Characteristics: An aspect of a character. A character's name, height, age, beauty, and strength are some possible characteristics.
• Common Characteristics: Characteristics common to all characters of a given type in a game. A character's name, height, age, beauty, and strength are frequently common characteristics.
• Conflict: Contention between characters, players, and/or game forces, especially contention that shapes the game's plot. This includes oppositions between two or more players concerning what facts should be introduced into a game world.
• Contest: A conflict that is resolved through mechanical means.
• Derived Attributes: An attribute whose value is determined by a formula. Typically, the formula uses other attribute values to generate a number.
• Drama: an outcome-based purely on story consideration. Outcomes in a drama are exclusively determined by what would be most entertaining for the participants.
• Flaw: a selected characteristic that is specifically not also a gauge. A character either has a flaw or he does not. Flaws are structurally very similar to gifts. But, flaws are generally considered detrimental to a character rather than beneficial.
• Fortune: An outcome that is at least partly based on random factors. This may include rolling dice, drawing cards, or some other random value generator.
• Game Master: Traditionally, a player assigned responsibilities to manage the game flow. With computer RPGs, the Game Master (GM) is the glue that holds everything together.
• Gauge: A graduated value generally associated with a name. Commonly the graduated values are numeric values.

 

• Gift: A selected characteristic that is specifically not a gauge. A character either has a gift or not. In general, gifts are considered beneficial to a character's well-being.
• Karma: An outcome based on non-random value comparison. A karma-based contest directly compares two values to determine an outcome.
• Non-Player Character (NPC): Any character portrayed by the Game Master as part of the role.
• Optional Characteristics: A characteristic that is not common to all characters of a given type.
• Player: Any person participating in a role-playing game.
• Player Character (PC): a character portrayed by any player while not assuming the role of a Game Master.
• Primary Attribute: An attribute whose value is set directly by a player rather than being derived by a formula from other attributes. Commonly, primary attributes are used in formulas to determine the values of Derived Attributes, but their own values are not determined by formulas. Typically, they are generated by random numbers or set by spending some resources.
• Rank: The specific value of a gauge skill, handicap, or ranked trait. Also used as an adjective in place of gauge when describing such skills and traits.
• Ranked Trait: A trait that is also a gauge.
• Selected Characteristic: A characteristic selected from a pre-defined list of choices.
• Shared Gauge: A gauge that is shared by many characters.
• Skill: A selected characteristic that is also a gauge and is generally considered beneficial to a character.
• Trait: A characteristic made up by a player without drawing it from a pre-defined list of choices.

To get a better understanding about the relationships between the attributes and characteristics, we have put together a visual help explain it:

Contest tree

The intent of a contest tree is to provide a mechanical means to create rising tension within a game. This is also known as Escalating Conflict.

Contest trees are high-level conflict resolution systems made up of many levels of contests arranged in a hierarchical fashion. The way they work is that lower-level contests feed into the higher-level contests and hence affect the outcome of the higher-level contests.

In other words, the higher-level contest could be to kill the big boss, but before you get to the big boss, there could be other mini battles that you will have to complete, and the outcome of the mini-battles will drive the outcome of the big battle. A simple example would be the amount of experience points you have gained before reaching the main boss.

Since the higher-level contests are somehow related to the lower-level contests, players do pay attention to the outcome of the lower-level contests; therefore, tensions arise concerning the eventual success or failure of a higher-level contest as a lower-level contest succeeds or fails.

 

 

It is best to use a contest tree when you want to create a sense of rising tension in your game. This can be achieved by applying different mechanics as the player progresses through the levels. Creating suspense in a cRPG is very simple, as you have a lot of control over the way levels and game play are designed. Since we have the ability to create our 3D worlds as we like, it would be easy to incorporate suspense into the game.

A few key points for creating tension in your game are as follows:

• The hero and enemy should be evenly matched.
• The hero and enemy should both periodically fail in their attempts, providing they are worthy adversaries.
• The hero and enemy's successes and failures are never so great that all hope of success of attaining the high-level goals is eliminated from either side.
• A highlight concerning contest trees is that it can only resolve high-level conflicts dealing with the mechanical inputs by the system. That is, if Damage and Remaining Hit Points are the only gauges used as an input into a conflict resolution, then the mechanics can only resolve issues dealing with Damage and Hit Points. To design a flexible contest tree, you will need to consider both the inputs as well as the outputs.

Last Man Standing

The Last Man Standing conflict system provides a generalized contest tree to resolve which side attains victory in battle.

The Last Man Standing is also one of the most traditional forms of generalized contest trees. The basic idea behind the pattern is to identify who the winner is by the simple fact of who manages to destroy the opponent. He who does is the winner. This is also one of the simplest ways to implement a contest tree.

It is used when there is a strong emphasis on tactical combat. Keep in mind that you are not obliged to use one pattern or the other. You can very well combine several patterns together, and you should, to make it more interesting. For instance, if your game has a great emphasis on combat, but you want to also introduce some negotiation into the conflict resolution, you can very much do so. Again, it all depends on you and your game design.

Something to keep in mind: if the only way to resolve a high-level contest is through battle, then players will focus their efforts on being the best they possibly can at winning battles. In other words, if a game only provides a single tool to resolve disputes, then you can be assured that players will become very adept and focused at using that tool.

 

Negotiated Contest

A Negotiated Contest provides a mechanical means to resolve disputes where the set of inputs and possible outcomes is negotiated by the player and non-player characters specifically for the conflict.

Designing and developing a Negotiated Contest mechanism is pretty complex. In order for the pattern to work properly, you will need to consider all of the inputs and outputs of the negotiations. The challenge of developing such a system is not so much the actual technical implementation, but the database that you will have to create and retain, based on the available selection by the player and the outcome of each input.

The implementation of the mechanics can be as simple as a few options and outcomes, and as complex as a variety of options and their eventual outcomes down the line. The important point is that you will have to introduce a negotiation mechanism after a conflict has been introduced, but before any action has been taken! The outcome is obviously what a win/lose concerns with, based on the negotiation before the conflict.

Note

Note: The Negotiated Contest pattern requires that players be allowed to negotiate the effects of success and failure before the conflict is mechanically resolved.

Use the Negotiates Contest pattern when your design goals include one of more of the following:

• A desire to unambiguously decide whether the outcome of a contest means a player wins or loses his stated goals, rather than whether or not his character succeeds in performing discrete actions
• A need to scale the resolution of contests to levels of granularity different than that of individual actions
• A willingness to allow players a great deal of narrative freedom in describing the results of contests, both good and bad

For computer role-playing games, the negotiated contest will have some restrictions, as we cannot afford to create an AI system to be open-ended. But we can design a simpler means to provide the player a sense of some control on the negotiations, as part of the game play.

 

 

Negotiation can be a great mechanics for exchanging information, and good with non-player characters in your role-playing game. There are three parts to a Negotiation pattern, as follows:

• Initiation: This is the phase at which a character action is introduced into the game world
• Execution: This is the phase in which the success or failure of a character action is determined
• Effect: This is the phase in which the results of a character's actions are determined.

Here are some questions to consider when designing a Negotiation system:

• What does the winner get?
• What does the loser get?
• How do we know who's the winner and who's the loser?
• What do we need to establish before resolution begins, and how?