Difference between revisions of "Pattern Relations"
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Pattern Related Notes]] | [[Category:Pattern Related Notes]] | ||
== On the ''Can Instantiate'' and ''Can be Instantiated by'' relationship == | == On the ''Can Instantiate'' and ''Can be Instantiated by'' relationship == | ||
| − | + | For these relations, the possibility of one pattern instantiating another is just this, a possibility. In many cases a collection of patterns with a common ''can instantiate'' target pattern are needed for the pattern to occur but even so there may be no clear relations between the patterns that are "collaborating" to create the target pattern. | |
| + | |||
| + | Besides this, it is important to note that the relations are between patterns and not instantiations of them. This means that while completing a specific [[Quests|Quest]] may provide a specific [[Rewards|Reward]], this does not mean that the pattern [[Quests]] instantiates [[Rewards]]. In contrast, [[Game Items]] may be [[Rewards]], so [[Game Items]] can instantiate [[Rewards]]. | ||
| + | |||
| + | Another point related to the relations between patterns is that some pattern instantiate others because they are more specific versions of them, e.g. [[Avatars]] is a specific form of [[Focus Loci]], while in other case a pattern typically gives rise to the presence of another pattern, e.g. [[Dice]] typically gives rise to [[Randomness]] but [[Dice]] is not a specific form of [[Randomness]]. | ||
| + | |||
| + | A third point related to these types of relations is that the intention behind using a pattern may lead to some ''Can Instantiate'' relations being described in the ''Using the Pattern'' section rather than what at first glance seems more natural, the ''Consequences'' section. This is because some patterns are often put into a game design for the reason of making another pattern appear rather than being a more or less guaranteed effect that may or may not be wanted. For example, the [[Traverse]] goal is typically used to create [[Races]] in games. | ||
Latest revision as of 09:39, 8 July 2014
On the Can Instantiate and Can be Instantiated by relationship
For these relations, the possibility of one pattern instantiating another is just this, a possibility. In many cases a collection of patterns with a common can instantiate target pattern are needed for the pattern to occur but even so there may be no clear relations between the patterns that are "collaborating" to create the target pattern.
Besides this, it is important to note that the relations are between patterns and not instantiations of them. This means that while completing a specific Quest may provide a specific Reward, this does not mean that the pattern Quests instantiates Rewards. In contrast, Game Items may be Rewards, so Game Items can instantiate Rewards.
Another point related to the relations between patterns is that some pattern instantiate others because they are more specific versions of them, e.g. Avatars is a specific form of Focus Loci, while in other case a pattern typically gives rise to the presence of another pattern, e.g. Dice typically gives rise to Randomness but Dice is not a specific form of Randomness.
A third point related to these types of relations is that the intention behind using a pattern may lead to some Can Instantiate relations being described in the Using the Pattern section rather than what at first glance seems more natural, the Consequences section. This is because some patterns are often put into a game design for the reason of making another pattern appear rather than being a more or less guaranteed effect that may or may not be wanted. For example, the Traverse goal is typically used to create Races in games.
