Difference between revisions of "Underlying Assumptions and Concepts"
(→Players) |
|||
| (28 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Pattern Related Notes]] | ||
== Assumptions == | == Assumptions == | ||
| − | |||
=== It is possible to name re-usable gameplay design concepts === | === It is possible to name re-usable gameplay design concepts === | ||
| − | This | + | This assumption builds on similar assumptions from other design disciplines, most specifically the design pattern approach introduced in Architecture<ref name="Alexander"/> and commonly used in object-oriented programming<ref name="Gamma"/>. To support this assumption each pattern should include several examples, from different types of games when possible (as the examples used have a tendency to be those played by the authors there is a natural bias but additional suggestions are warmly welcomed). |
| + | |||
| + | ==== One can find likely relations between gameplay design concepts ==== | ||
| + | As a follow-up to the assumption that one can identify re-usable gameplay design concepts, there is also that the patterns do not exist independent of each other and how they affect each other can be generalized. While some pattern are likely to give rise to other patterns, others mainly affect how other patterns are realized, and some patterns are difficult to have present together with other patterns. See the pages on [[Pattern Relations]] and [[Using Patterns and Consequences of Patterns]] for more details about this. | ||
=== Games can be described as an Activity-Based Framework of Game Components === | === Games can be described as an Activity-Based Framework of Game Components === | ||
| − | The original gameplay design patterns collection<ref name="Bjork & Holopainen 2004"/> was created from analyzing specific ways game components could be instantiated in a game design. To support this, a framework describing generalized game components on different levels of abstraction was identified<ref name="Bjork & Holopainen 2004, chapter 2"/> | + | The original gameplay design patterns collection<ref name="Bjork & Holopainen 2004"/> was created from analyzing specific ways game components could be instantiated in a game design. To support this, a framework describing generalized game components on different levels of abstraction was identified<ref name="Bjork & Holopainen 2004, chapter 2"/>. |
== Concepts == | == Concepts == | ||
| − | |||
=== Agents === | === Agents === | ||
| − | Making choices is often seen as one of the most important characteristics of games. Having this | + | Making choices is often seen as one of the most important characteristics of games. Having this agency<ref name="Agency"/> is typically at first assumed to relate to humans. However, given the presence of [[Algorithmic Agents]] and humans' tendency to anthropomorphize<ref name="Anthropomorphism"/> (including doing so for computer programs<ref name="Eliza"/>) and taking intentional stances<ref name="Intentional Stance"/> people often ''behave'' as if non-humans also take decisions between choices. Several of the patterns relate to making choices or the impression of others doing so without requiring that it is actually humans involved, and due this the concept of agents is used instead. |
=== Gaming === | === Gaming === | ||
Although one typically say that one is ''playing'' a game, this can create confusion since this may be interpreted as having the same characteristics as the unstructured and non-goal-related activity done by (primarily) children. Rather than try to relabel this more common use of the word as for example ''free play'', we use gaming as the structured goal-oriented interaction that games are designed to support. Note that games can support other types of activities as well, so not everything done while interacting with a game is gaming - other examples include socializing, teaching, and playing. Note also that gaming can be doing using other artifacts than games; games are simply the artifacts whose primary intended use is to support gaming. | Although one typically say that one is ''playing'' a game, this can create confusion since this may be interpreted as having the same characteristics as the unstructured and non-goal-related activity done by (primarily) children. Rather than try to relabel this more common use of the word as for example ''free play'', we use gaming as the structured goal-oriented interaction that games are designed to support. Note that games can support other types of activities as well, so not everything done while interacting with a game is gaming - other examples include socializing, teaching, and playing. Note also that gaming can be doing using other artifacts than games; games are simply the artifacts whose primary intended use is to support gaming. | ||
| − | This distinction between playing and gaming may be due to a cultural bias from the researchers involved in the project. As native speakers of Swedish and Finnish where there exists different words for the two types of activities, it has been conceptually natural to take this view (''to play'' and ''to game'' translated to the Swedish ''att leka'' & ''att spela'' and the Finnish ''Leikkiä'' & '' | + | This distinction between playing and gaming may be due to a cultural bias from the researchers involved in the project. As native speakers of Swedish and Finnish where there exists different words for the two types of activities, it has been conceptually natural to take this view (''to play'' and ''to game'' translated to the Swedish ''att leka'' & ''att spela'' and the Finnish ''Leikkiä'' & ''Pelata''). |
| + | |||
| + | === Gameplay === | ||
| + | Gameplay is said to mean "[t]he structures of player interaction with the game system and with other players in the game" for the context of this collection of design patterns<ref name="Bjork & Holopainen 2004"/>. There are however other definitions and descriptions focusing on other aspects of what experiences on can have with games<ref name="Gameplay"/>. In our work we see gameplay are the quintessential characteristic of a game, but see [[No Direct Player Influence]] and the category of [[:Category:Experimental Art Games|experimental art games]] as well as work on ''playfulness''<ref name="DeKoven"/>. | ||
=== Players === | === Players === | ||
| + | A human participating in a game is the common notion of what a player is. Due to the presences of [[AI Players]], [[Player Augmentations]], [[Game Masters]] and this notion can be questioned, and many game designs use players as a concept regardless if it is a human (or several) or a machine performing actions. Adopting this view, this gameplay design pattern collection sees a player as an abstract construct related to the specified ways of interacting with the game system and related to how the valorization<ref name="Juul"/> of the outcome of the game instance is determined. Although needed for the activity to occur, they are ''not'' seen as being part of the game itself, just like a driver is necessary for driving but is not seen as a part of a vehicle. However, designers still need to consider them and in some cases they ''do'' become part of these design as automated processes. | ||
| + | |||
| + | In fact, gamers is used relatively often in the collection instead of players. This is to make more clear that one is referring to an agent performing the activity of gaming rather than the common sense concept of a player or the more specific use describe above (which can engage in other types of activities than gaming). | ||
| + | |||
| + | === Play Sessions === | ||
| + | A concept from the conceptual framework<ref name="Bjork & Holopainen 2004, chapter 2"/>. A continuous period of gameplay for a player, where it typically is the player that decides what is continuous or not. | ||
| + | |||
| + | === Game Sessions === | ||
| + | A concept from the conceptual framework<ref name="Bjork & Holopainen 2004, chapter 2"/>. The complete set of actions for a player in a game instance, in principle the sum of all play sessions for that player. Note that not all play sessions do need to affect the final game state directly, as [[Save-Load Cycles]] may make the action and events of some play sessions not part of the complete chain of game state updates concerning that player. | ||
== References == | == References == | ||
<references> | <references> | ||
<ref name="Agency">[http://en.wikipedia.org/wiki/Agency_(philosophy) Wikipedia entry for Agency].</ref> | <ref name="Agency">[http://en.wikipedia.org/wiki/Agency_(philosophy) Wikipedia entry for Agency].</ref> | ||
| + | <ref name="Anthropomorphism">[http://en.wikipedia.org/wiki/Anthropomorphism Wikipedia entry for Antropomorphism].</ref> | ||
<ref name="Alexander">Alexander, C Ishikawa, S. & Silverstein, M. ''A Pattern Language: Towns, Buildings, Construction''. Oxford University Press. ISBN-10 0195019199, ISBN-13 978-0195019193 | <ref name="Alexander">Alexander, C Ishikawa, S. & Silverstein, M. ''A Pattern Language: Towns, Buildings, Construction''. Oxford University Press. ISBN-10 0195019199, ISBN-13 978-0195019193 | ||
</ref> | </ref> | ||
<ref name="Bjork & Holopainen 2004">Björk, S. & Holopainen, J. (2004) ''Patterns in Game Design''. Charles River Media. ISBN 1-58450-354-8.</ref> | <ref name="Bjork & Holopainen 2004">Björk, S. & Holopainen, J. (2004) ''Patterns in Game Design''. Charles River Media. ISBN 1-58450-354-8.</ref> | ||
<ref name="Bjork & Holopainen 2004, chapter 2">Björk, S. & Holopainen, J. (2004) An Activity-Based Framework for Describing Games. Chapter 2 in ''Patterns in Game Design''. Charles River Media. ISBN1-58450-354-8.</ref> | <ref name="Bjork & Holopainen 2004, chapter 2">Björk, S. & Holopainen, J. (2004) An Activity-Based Framework for Describing Games. Chapter 2 in ''Patterns in Game Design''. Charles River Media. ISBN1-58450-354-8.</ref> | ||
| + | <ref name="DeKoven">De Koven, B. (1978) The Well-Played Game - A Player's Philosophy.</ref> | ||
| + | <ref name="Eliza">Wikipedia [http://en.wikipedia.org/wiki/Eliza_effect entry] for the Eliza Effect.</ref> | ||
| + | <ref name="Gameplay">Wikipedia [http://en.wikipedia.org/wiki/Gameplay entry] for Gameplay.</ref> | ||
<ref name="Gamma">Gamma, E., Helm, R., Johnson, R. & Vlissides, J.M. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. ISBN-10: 0201633612, ISBN-13: 978-0201633610.</ref> | <ref name="Gamma">Gamma, E., Helm, R., Johnson, R. & Vlissides, J.M. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. ISBN-10: 0201633612, ISBN-13: 978-0201633610.</ref> | ||
| + | <ref name="Intentional Stance">[http://en.wikipedia.org/wiki/Intentional_stance Wikipedia entry for Intentional Stance].</ref> | ||
| + | <ref name="Juul">Juul, J. (2003). [http://www.jesperjuul.net/text/gameplayerworld/ Keynote presentation] at the Level Up conference in Utrecht, November 4th-6th 2003.</ref> | ||
</references> | </references> | ||
Latest revision as of 10:11, 25 July 2014
Contents
Assumptions
It is possible to name re-usable gameplay design concepts
This assumption builds on similar assumptions from other design disciplines, most specifically the design pattern approach introduced in Architecture[1] and commonly used in object-oriented programming[2]. To support this assumption each pattern should include several examples, from different types of games when possible (as the examples used have a tendency to be those played by the authors there is a natural bias but additional suggestions are warmly welcomed).
One can find likely relations between gameplay design concepts
As a follow-up to the assumption that one can identify re-usable gameplay design concepts, there is also that the patterns do not exist independent of each other and how they affect each other can be generalized. While some pattern are likely to give rise to other patterns, others mainly affect how other patterns are realized, and some patterns are difficult to have present together with other patterns. See the pages on Pattern Relations and Using Patterns and Consequences of Patterns for more details about this.
Games can be described as an Activity-Based Framework of Game Components
The original gameplay design patterns collection[3] was created from analyzing specific ways game components could be instantiated in a game design. To support this, a framework describing generalized game components on different levels of abstraction was identified[4].
Concepts
Agents
Making choices is often seen as one of the most important characteristics of games. Having this agency[5] is typically at first assumed to relate to humans. However, given the presence of Algorithmic Agents and humans' tendency to anthropomorphize[6] (including doing so for computer programs[7]) and taking intentional stances[8] people often behave as if non-humans also take decisions between choices. Several of the patterns relate to making choices or the impression of others doing so without requiring that it is actually humans involved, and due this the concept of agents is used instead.
Gaming
Although one typically say that one is playing a game, this can create confusion since this may be interpreted as having the same characteristics as the unstructured and non-goal-related activity done by (primarily) children. Rather than try to relabel this more common use of the word as for example free play, we use gaming as the structured goal-oriented interaction that games are designed to support. Note that games can support other types of activities as well, so not everything done while interacting with a game is gaming - other examples include socializing, teaching, and playing. Note also that gaming can be doing using other artifacts than games; games are simply the artifacts whose primary intended use is to support gaming.
This distinction between playing and gaming may be due to a cultural bias from the researchers involved in the project. As native speakers of Swedish and Finnish where there exists different words for the two types of activities, it has been conceptually natural to take this view (to play and to game translated to the Swedish att leka & att spela and the Finnish Leikkiä & Pelata).
Gameplay
Gameplay is said to mean "[t]he structures of player interaction with the game system and with other players in the game" for the context of this collection of design patterns[3]. There are however other definitions and descriptions focusing on other aspects of what experiences on can have with games[9]. In our work we see gameplay are the quintessential characteristic of a game, but see No Direct Player Influence and the category of experimental art games as well as work on playfulness[10].
Players
A human participating in a game is the common notion of what a player is. Due to the presences of AI Players, Player Augmentations, Game Masters and this notion can be questioned, and many game designs use players as a concept regardless if it is a human (or several) or a machine performing actions. Adopting this view, this gameplay design pattern collection sees a player as an abstract construct related to the specified ways of interacting with the game system and related to how the valorization[11] of the outcome of the game instance is determined. Although needed for the activity to occur, they are not seen as being part of the game itself, just like a driver is necessary for driving but is not seen as a part of a vehicle. However, designers still need to consider them and in some cases they do become part of these design as automated processes.
In fact, gamers is used relatively often in the collection instead of players. This is to make more clear that one is referring to an agent performing the activity of gaming rather than the common sense concept of a player or the more specific use describe above (which can engage in other types of activities than gaming).
Play Sessions
A concept from the conceptual framework[4]. A continuous period of gameplay for a player, where it typically is the player that decides what is continuous or not.
Game Sessions
A concept from the conceptual framework[4]. The complete set of actions for a player in a game instance, in principle the sum of all play sessions for that player. Note that not all play sessions do need to affect the final game state directly, as Save-Load Cycles may make the action and events of some play sessions not part of the complete chain of game state updates concerning that player.
References
- ↑ Alexander, C Ishikawa, S. & Silverstein, M. A Pattern Language: Towns, Buildings, Construction. Oxford University Press. ISBN-10 0195019199, ISBN-13 978-0195019193
- ↑ Gamma, E., Helm, R., Johnson, R. & Vlissides, J.M. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. ISBN-10: 0201633612, ISBN-13: 978-0201633610.
- ↑ 3.0 3.1 Björk, S. & Holopainen, J. (2004) Patterns in Game Design. Charles River Media. ISBN 1-58450-354-8.
- ↑ 4.0 4.1 4.2 Björk, S. & Holopainen, J. (2004) An Activity-Based Framework for Describing Games. Chapter 2 in Patterns in Game Design. Charles River Media. ISBN1-58450-354-8.
- ↑ Wikipedia entry for Agency.
- ↑ Wikipedia entry for Antropomorphism.
- ↑ Wikipedia entry for the Eliza Effect.
- ↑ Wikipedia entry for Intentional Stance.
- ↑ Wikipedia entry for Gameplay.
- ↑ De Koven, B. (1978) The Well-Played Game - A Player's Philosophy.
- ↑ Juul, J. (2003). Keynote presentation at the Level Up conference in Utrecht, November 4th-6th 2003.
