Anatomy of a Pattern

This page is still being written. Please bare with us while we solve bad structure, uncompleted sentences and unchecked content.

Network of patterns

In a Pattern Language, patterns relate to each other, by definition. 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 Weapon 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 far fetched cases

Subjectivity added to the objectivity of rare (but relevant) exceptions make every setting of relationships potentially arguable. The expression of the set of relationships for a pattern is invariably the outcome of a compromise. For instance [pending]:

• • e.g., consider the patterns Achievement and Failure. Both usable to provide awareness for the outcome of a certain behaviour, but usually they are (...) . Still:
    • they could be thought of as parts of an evaluation mechanism
    • they do not necessarily inhibit each other in a same moment

Unions 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

We 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).

On the boundaries of the global scope

On the higher level

The highest level is symbolised by the card Sound Design in Games
which is assumedly a card aside others. The next level of patterns are those that exclusively aggregate others, without carrying any specific exploration themselves. These aggregator patterns are relevant but not effective when expressed as deck cards (see the rationale). As such this is a level that interests us when considering patterns but which is out of boundaries when considering their representation as cards.

Stop before going implementational

For instance, when we first presented the seminal collection of patterns we included the pattern Horse Hooves that was meant to illustrate a low illustrate the specification of a low-level pattern. This tentative pattern addressed solutions for the problem of producing the sounds of the hoofbeats. Meanwhile we realised that we are not willing to specify patterns of this nature/level in the scope of this initiative, for several reasons, including the fact that they address implementational matters that come further the design decisions. Our mindset at the time was that, if we trying to contribute to the empowerment of small game developers to perform sound design, it would make sense to also provide information regarding to the implementation of those ideas, so that while designing they could ponder the feasibility or predicted cost of those ideas. Yet, we now understand that mixing the two levels in the purposed collection is not interesting (please see details about this matter.).

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 many cases we opted by the formula: 'use this solution when faced with this problem'. Still particular cases call for adaptations. For instance:
  • In higher level patterns this tends to be kind of problems addressed
    • e.g., in Sound Input : 'The way sound enters the game world'
    • 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.'
• Relationships: