A simple mechanism is needed which allows the game designer to create these puzzles without resorting to specifying coordinates or other programmatic solutions.[/bquote]
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"]Issues and Risks
Triggers can work to augment or even replace Usecode scripts.[/bquote]
[size="5"]Uses and References