[size="5"]Intent
[bquote]Provide a simple mechanism for building geometric game puzzles.[/bquote]
[size="5"]Problem
[bquote] Many games, especially adventure games, have a variety of puzzles oriented around movement of the player character. For example: switches, traps, secret doors, mines, guards, etc.
A simple mechanism is needed which allows the game designer to create these puzzles without resorting to specifying coordinates or other programmatic solutions.[/bquote]
[size="5"]SolutionA simple mechanism is needed which allows the game designer to create these puzzles without resorting to specifying coordinates or other programmatic solutions.[/bquote]
[bquote] A trigger "dummy object" is created which automatically instantiates a controller when it is inserted into the world database. This controller checks for some "trigger condition" (for example, if the player character is within a certain distance) each game turn and causes something to happen when the condition is satisfied. Thus, a trigger is analogous to an "if statement" which runs each game frame.
One versatile and clever implementation of triggers is "detect, broadcast, respond". For example, imagine a game puzzle which involved darts flying out of a wall when the player character steps in a certain area. To implement this, a "detect trigger" is placed in the appropriate place and its bounds are set accordingly. Furthermore, the game designer specifies a "broadcast message" which is to be issued when the condition is satisfied. In this case, suppose the message is: "shoot darts". When the game runs and the condition is satisfied (the player character steps into the bounds of the trap), the "broadcast" is implemented by searching the local area for other triggers and passing the "shoot darts" message to each. Some of these triggers may respond to the message, other ignore it. In the "darts" example, two shooting "response triggers" would be placed into the world and would have been instructed to activate (shoot darts) when they received the "shoot darts" message.
Although somewhat limited, a simple trigger system can be surprisingly rich in behavior and is very easy for game designers to learn and use (certainly much simpler and more flexible than custom code or script to do the equivalent). They are also useful for games which allow end users to build their own levels due to their great simplicity.
The properties of triggers (bounds, messages, actions, etc) are usually specifiable in edit mode, and may be visible in debug / edit mode.
Some advanced trigger systems may include "predicates" such as "only if flag X" or other such conditions. In the extreme, a scripting language (See Usecode) may be used to specify the "detect" and "response" criteria.[/bquote]
[size="5"]StructureOne versatile and clever implementation of triggers is "detect, broadcast, respond". For example, imagine a game puzzle which involved darts flying out of a wall when the player character steps in a certain area. To implement this, a "detect trigger" is placed in the appropriate place and its bounds are set accordingly. Furthermore, the game designer specifies a "broadcast message" which is to be issued when the condition is satisfied. In this case, suppose the message is: "shoot darts". When the game runs and the condition is satisfied (the player character steps into the bounds of the trap), the "broadcast" is implemented by searching the local area for other triggers and passing the "shoot darts" message to each. Some of these triggers may respond to the message, other ignore it. In the "darts" example, two shooting "response triggers" would be placed into the world and would have been instructed to activate (shoot darts) when they received the "shoot darts" message.
Although somewhat limited, a simple trigger system can be surprisingly rich in behavior and is very easy for game designers to learn and use (certainly much simpler and more flexible than custom code or script to do the equivalent). They are also useful for games which allow end users to build their own levels due to their great simplicity.
The properties of triggers (bounds, messages, actions, etc) are usually specifiable in edit mode, and may be visible in debug / edit mode.
Some advanced trigger systems may include "predicates" such as "only if flag X" or other such conditions. In the extreme, a scripting language (See Usecode) may be used to specify the "detect" and "response" criteria.[/bquote]
[bquote]Not available at this time.[/bquote]
[size="5"]Examples
[bquote]None at this time.[/bquote]
[size="5"]Issues and Risks
[bquote]None at this time.[/bquote]
[size="5"]Related Patterns
[bquote]Trigger are a special kind of Controller, associated with a special kind of Model object.
Triggers can work to augment or even replace Usecode scripts.[/bquote]
Triggers can work to augment or even replace Usecode scripts.[/bquote]
[size="5"]Uses and References
[bquote]Thanks to Gary Scott Smith, Herman Miller, and Tony Zurovec.[/bquote]