Difference between revisions of "Anatomy of a Pattern"

Revision as of 12:51, 19 August 2011

When in this circumstances (context), if faced with this challenge (problem),

Network of patterns

Patterns are by definition related. The specification of those relationships defines the language (of which the pattern names are the words of the vocabulary). The nature of such relationships varies:

• Patterns may contain (non-exclusive) alternative solutions to a problem
  • e.g. Sound Decoys and Sound Suppressing are both usable when willing to design low profile interaction with opponent characters
• Patterns may contain contrasting solutions to a problem
  • e.g. Make sound not War and Sonic Weapons suggest to different approaches to design conflicts
• A pattern may contribute to solve a specific case of a context/problem (i.e. in an included context)
  • e.g. Sound Effects may be used to present an Achievement
• A pattern may present a solution that may integrate solutions to different problems
  • e.g. Heartbeat may used to signal Imminent Death but may also serve as Beacon Locator in a Echolocation approach.
  • e.g. Grunts may signal damage during an interaction (Ouch!) as they may be used to present an Unaware NPC, or to provide auditory feedback on the magnitude of the effort the PC applies in some physical movement, amongst others
• Patterns may be exhibit solutions for possible parts of a "more complex" solution
  • e.g. Relaxation, Anticipation, Engagement and Decay, though being usable in isolation, may be used to create R-A-E-D Iterations
• Complementarity alternative solutions to a problem

Subjectivity and less frequent cases

Subjectivity added to the objectivity of rare (but relevant) exceptions make every setting of relationships potentially arguable. For instance [pending]

• • e.g. consider the patterns Achievement and Failure
    • they could be thought of as parts of an evaluation mechanism
    • they do not necessarily inhibit each other in a same moment

both usable to provide awareness for the outcome of a certain behaviour, but usually they are part of a

Inclusions and Intersections

The fact that patterns are not all at the same abstraction level – because they present different levels of solutions for different levels of problems in different scopes of the context of Sound Design in Games – implies that there cases of overlapping coverage of a particular matter. [pending: graph illustrations allusive to overlapping pattens]

Aggregator Cards

Were are calling 'Aggregator Pattern' to those which exclusively characterise a set of more specific solutions, without present no specific solution per se. Aggregator Patterns evidence Categories of Patterns (a concept that we are considering to explore but did not yet, to date).

Style guide for the card format

The anatomy of card (here illustrated over the card named Achievement), (as of v1.0)

• Name: a token that represents the solution
• Synopsis: the shortest possible sentence that identifies the contents of the pattern
  • In higher level patterns this tends to be kind of problems addressed
    • e.g. in Sound Input
      : 'The way sound enters the gameworld'
    • e.g. in Character Soundprint: 'The set of sounds of a PC or NPC'
    • e.g. in Dialogue: 'All sorts of conversation'
  • In lower level patterns this tends to be the solution, and the problem and/or the context if its not tacit enough
    • e.g. in Eavesdropping]]: 'Adopting behaviours with the intention of gaining knowledge by listening to others' conversations.'
    • e.g. in Sing to Act: 'Performing songs to achieve a purpose.'

Dialogue: the problem and the solution. that presents the solution in a effective way. When 'Adopting behaviours with intention of gaining knowledge by listening to others' conversations.' In many cases we opted by the formula: 'use this solution when faced with this problem'.