Http Omgwtfgames.com 2009 08 Game-design-concepts-mindmap

Designscape - A Suggested Game Design Prototyping Process Tool

This paper is a part of the game studies field from a design perspective. It investigates the computer game design process, focusing primarily on prototyping, as it is being performed in game development today. Prototyping has been studied in other design fields, (Buxton 2007; Arvola and Artman 2007; Lim 2008) but its role in computer game design is relatively unexplored.

Potential users of prototypes and prototyping methods range from the designer and the design team, to beta testers and publishers. The focus in this paper is on internal use of prototypes, where the design team is the target audience. The prototype functions as a tool for getting the team on the same track and to introduce new members to the work. Prototypes and visualizations also tend to replace the game design document more and more.

The work presented here is based on analysis of interviews with game designers. By applying perspectives from rhetoric, the aim is to investigate how the communication around the prototyping process within a design team can be improved.

Prototyping and interaction design in Relation to Game Design

It is a common understanding in relevant literature that prototyping is an important part of game design (Salen and Zimmermann 2004; Fullerton et al. 2008; Schell 2008; Fullerton et al. 2006; Glinert 2010). Digital games are a very complex piece of software to develop, where game mechanics generate emergent gameplay. Even small rule changes can result in drastic changes in gameplay. How the gameplay changes in such cases is hard to predict, even for an experienced designer (Salen and Zimmerman 2004). Games are furthermore considered by many to be a piece of art (Costikyan 2002; Smuts 2005; Tavinor 2009), although this issue has been heavily debated outside the academic field (Ebert 2010; Moriarty 2011). Games design teams need the prototypes to check how emergent gameplay and artistic design choices affect the design. Game design is often described as experience design (Schell 2008; Swink 2008). Game prototypes are generally meant to be experienced or played with, in a lean-forward sense with reference to McLuhan, i.e. by actively consuming the media (McLuhan 2004). The notion is often that the designer, or the team, need to feel the idea. This is valid in general (Arnowitz et al . 2007, Buxton 2007, Snyder 2003), as well as for games in particular (Brathwaite et al . 2009, Fullerton et al . 2008, Schell 2008, Salen et al . 2004), and is also supported by our data.

When you do a prototype, I guess it is connected a bit to…one start to prototype, not always but often, when you're doing your concept discovery and you want to start to feel the things right away. (A Game Director at an AAA-developer)

A fundamental characteristic of a prototype is that manifests an idea. As such it represents something that the designer, or the design team, can reflect upon. It facilitates the simultaneous development of the design problem and its solution (Fällman 2003). In this reflection, a prototype is often used as a sketching tool in Game Design (Manker and Arvola 2011). In the early process of game development, prototypes can take the form of sketch-like games made in, if not minutes, at least hours (Agustin et al. 2007).

The purpose of prototypes may generally differ in interaction design; they can prototype a role, an implementation or the look and feel. The role is the function of the product in the user's life. The implementation is about the construction. The look & feel is about the user's experience of the product. A prototype can explore one or several of these dimensions (Houde and Hill 1997). The two primary roles of the prototypes are implementation and the feeling of the game. When prototyping experiences, the designer can explore questions such as "What would it feel like to play the game if…?".

In game development practice, agile methods have been widely embraced. The most common agile method in game design is called scrum . In these methods the focus is on production in short iterations. The goal is not set from the beginning but explored together during the process, and the team has an agile mindset towards modifying the end goal inspired by changes that new ideas and iterations may bring. In this practice it is common to always have something playable at hand and to constantly playtest the game even at early development stages (Glinert 2010; Keith 2010). The prototype is a playable version of the game or a part of the game that assists in understanding and enhancing the player experience. (Brathwaite and Schreiber 2009). So, prototyping a game is an exploration where the design team gets to test their idea and gets a better understanding of it. It is fair to say that the prototype functions as a tool that deepens the understanding of a game. It is also worth noting that game design teams tend to work autobiographically, leaning primarily on their own conceptions of experiences in playtesting the game or its prototypes (Hagen 2010). In this process it is vital that the game designer and the team she/he works in can arrive at a common understanding of underlying concepts and ideas . Various practices are being used in game design to obtain this common understanding, including The One Question, Key Areas of Focus, Mood Boards, etc. (Hagen 2010).

The development of the game and the team's idea of the game are intertwined with the prototypes. Normally, several people in the design team take part in creating and using the prototype and contribute their different thoughts on how they experienced this. As stated before, the prototype can act as a filter that focuses attention on certain aspects of the design (Lim et al . 2008). The designer should have the audience and the desired focus in mind when choosing what kind of prototype to make (Houde and Hill 1997; Holmquist 2005; Arvola and Artman, 2007; Johansson and Arvola 2007; Sellen et al . 2009). This is true even when the audience is the other team's members, which often is the case in early game development (Manker and Arvola 2011). Since the prototyping process is intertwined with the development, a continuous valuation and negotiation of the experiences takes place during the design work (Manker 2011b).

An important part of the approach presented in this paper is to investigate how theories from rhetoric can be used to improve game design practices. Rhetoric is focused on a production-based view of communication, i.e. how and why the communication works. In rhetoric we also find the most developed theory base concerning negotiation practice. Since a prototype has communicative qualities and since prototyping involves negotiation, rhetorical analysis may be fruitfully used for analysing prototyping.

It is obvious that prototyping, particularly in game design, is a group effort. In this paper, I will look primarily for group-related implications and try to evolve these into a tool meant to be used by a design team. The question is: based on how game prototyping is done today, seen as communicative process, through a rhetorical perspective, how could prototyping work processes increase the teams' understanding of the game design process and the game being deigned?

Method

The study builds on interviews that have been conducted with twenty seven game design practitioners in Sweden and Poland. The data collected has been structured using qualitative content analysis. All of the respondents work primarily with digital games, and come from the following companies and communities:

· (AAA) Avalanche Studios, CD Project Red, Dice, Grin, Massive Entertainment and Starbreeze.

· (Indie) Immersive Learning, Nitreal, Sleepwalker and Stunlock Studios (former Bumblebee Studios)

· (Students) Playground Squad and Stockholm University

The respondents were all lead designers, except for the students and one other participant, a junior designer, who was interviewed under the same session as a senior designer at that company.

The interviews were conducted in just over a year (May 15, 2009 through May 25, 2010). They were semi-structured and the data collection has been qualitative rather than quantitative. Each interview lasted between one and two hours. The interviews were recorded, transcribed and analysed using qualitative content analysis. Some were transcribed in their entirety others only in selected sections. It is worth noting that conclusions drawn are based on interviews in which designers talk about their memories of the prototyping practice, not observed actual practice.

Prototyping and Rhetoric Theory.

A prototype fulfils an important role as a vehicle for communication. As such it is used to negotiate design problems. This was one of the most recurring views the game designers in our study had, concerning the function of a prototype (Manker 2011b). Both communication and negotiation relates to rhetoric. As mentioned in the introduction, another recurring statement was that through the prototype you deepen your understanding for how the game will play out and what kind of experiences it will provide (Manker 2011a).

Well, like, 'you've getted the pic?' What is that? Really?... yeah, but to find a common language is to a large extent what you are trying to do in a prototype I think. (Game Director at an AAA-developer)

[prototypes can fulfil the function as] something you use to communicate with…instead of just talking or showing text you have a prototype so that people can get what you are looking for as a designer. (Game design student)

To communicate using the prototype also relates to having something playable on hand at all times, (Glinert 2010). In game development, iterations generally generate playable prototypes (Keith 2010) and the communication of an idea through these is important. Rhetoric is a term that has had many interpretations over more than two millennia. Here it is interpreted as a field of study which takes an interest in the analyses of our communication, i.e. how and why the communication works and how the communication can be improved. (Jasinski 2001). Rhetoric has a wide variety of analytical tools and terms; some are chosen and used in this paper for analysing prototyping practice, although they were initially intended for spoken language.

A common belief is, in rhetoric, called a doxa. This refers to a collection of viewpoints, the common understanding of something. Those viewpoints are referred to as topoi (topos, singular); a topos is usually defined as a recurring and familiar way to describe, understand and communicate something within a specific culture (Jasinski 2001). Note that the doxa is not the object itself or any clear representation of it. The doxa is the common belief of what something is and can thus never be the thing itself. In this paper, the doxa represents the design team's common understanding of what the game is. Therefore it will be referred to as a game doxa. Consequently, the topos is here seen as one issue in the game being designed and will be referred to as a game topos.

A topos is a way to structure our thinking. The term topos originally means "place", based on spatial epistemology where topoi are places in a cognitive landscape that describes what is important for a group. A doxa is often referred to as a mental landscape shaped by a number of topoi that form hills and valleys in this landscape. To illustrate how this could be applied to a design situation the landscape of a game doxa can be seen as a transparent lens. The game being created is always viewed through this lens and it creates a constantly shifting representation of the game. Furthermore, a topos works as both an aspect and a way to negotiate this aspect. A topos works as a node in which both consensus and controversy can exist (generally not at the same time) (Hellspong 2008; Jasinski 2001). To use a topos creatively is to use it as a tool to expand your own thoughts (Wolrath-Söderberg 2003).

In rhetoric there exist a number of tools, also called figures, which reflect relationships between various parts of a communication. These are a subgroup of topos. Topos exist in three variations, as a value base for discussion, as a point which is up for discussion, and as operations used in the discussion. Figures counts as operations. One figure that resembles prototyping is part-to-whole. Part-to-whole is an understanding of the whole developed by an understanding of parts that are associated with the whole. Conversely, a developed understanding of the whole may deepen the understanding of an associated part of the whole (Dirven et al . 2003). Prototypes generally focus on a distinct part of a game and make this element playable. In itself, the part can be very different from the intended game as a whole, but the experience from playing with the prototyped part develops the understanding of the potential experience from playing the finished game. In short and in this context, a part-to-whole figure is when something provides understanding for the whole game, through parts of the game. So, the prototype works as a part-to-whole when evolving a specific game topos (aspect of the game) in the game doxa (the common view of the game).

As mentioned before, prototyping works as a tool for the negotiation (which takes place in a topos). In a game design process countless design decisions are made, each one perceivable as a topos. When a topos is negotiated it is transformed from a node of controversy to a node of consensus. In rhetoric theory, this is related to trust. Trust may, in a rhetorical context, exist in relation to various objects such as a person, a company, a state, a tradition, an idea, etc. (Jasinski 2001), or, as in our case, in relation to a game or parts of that game. When something is turned into consensus, the participants gain trust relative to it. Trust is needed in negotiation in order to be convinced. At the same time, a negotiation develops trust among and between the participants which also gives it a social importance. (Hellspong 2008) One example could be an object in a game design process, such as an operating mechanism, a level layout, a characters ability, etc. When the object is prototyped due to a design problem, the team don't trust its current design. When the design problem has been solved, the object has gained trust within the team. The team has a consensus around the object, that it is functional and good and trusts it enough to move along.

To prototype is also used to explore the potential game within the idea. The game being designed is hidden behind the teams game doxa and is not accessible, but the team can learn more and more about it through prototyping. People that are familiar to games and experienced in playing games have a game literacy. In a design team the members game literacy affects the game doxa or the game they are making. At the same time , experience from previous design work also affects the teams' game doxa through links to design issues and praxis'. This could be called the design doxa In combination this can be identified as game design literacy . To design is a discovery of the game through an iterative creative process. The team learn through prototyping about their new game and how their design ideas works. When playing a game, game literacy is an important factor affecting how a player learn and develop her knowledge of the game through playing. This affects gameplay and the playing experience. (Egenfeldt-Nielsen 2006; Macklin 2011). Or applied to a design situation; when designing game, game design literacy is an important factor affecting how the team learn about the game they are designing. This affects design choices and the progression of the design work. Through knowledge about the teams game design literacy it may be possible to better determine how much prototypes can teach them about the game being designed and also to better determine how the players will perceive the game.

All the things you [as a player]… the movement of your hand and stuff, it's, it's, it is important to prototype this. To check if it is too hard to press four buttons at the same time. (Lead Designer at an indie developer)

Relevant literature also recognizes the link between prototyping and player experience as important (Fullerton et al. 2008; Salen and Zimmerman 2004). Other research has revealed four aspects identified as factors that can support learning and understanding through games:. challenge, curiosity, control and fantasy (Malone and Lepper 1987; Schaller 2005); such aspects are clearly beneficial to a creative process (Wikipedia 2011). With a deepened understanding, the designer and the team establish a foundation on which trust for the design and the game can be achieved.

Let's exemplify how the trust for a game's aspects can be linked to rhetoric in a game design context. To make a link to the data, prototyping practice, as described by the respondents, is quite uncontrolled, ad hoc, and sometimes messy. Several of them described the process of finding out what the game is:

You can have… effect prototypes were you just have something that… is triggered again and again, just to see how things look…'that looks too bad to be our demolition system' maybe isn't good enough or something like that… and then you get to see what one… want to focus on or how to solve it. (Lead Designer at an AAA-developer)

The prototype adds a layer of interpretation and distance from the idea and from the real game but is, at the same time, a necessary embodiment of the idea in order to be able to fully evaluate and understand it. It is not literally the idea but a version of it; something that makes the team able to grasp it. It is a metonymy rather than a metaphor (Driven and Parings 2003). When the prototype is used, it is tested again and again to understand the player experience generated by the design idea (Schell 2008) When the metonymy breaks, along with understanding and trust in it, controversy has occurred around an aspect of the game, a part of the game, a design problem or the like, in other words a game topos. This game topos stands out from the team's game doxa (the common understanding) and the team does not trust it anymore. It needs to be negotiated and explored. The prototype used for this does not resemble the whole game; it is a part-to-whole figure (Driven and Parings 2003). The prototype communicates the game topos within the team. At the same time it allows the team to explore this game topos and its implications, and learn things about the game that they did not plan for in the prototype. The prototype generates a process within the team which deepens the understanding for the game.

You can have different goals with your prototype, but the most common, one might say, is to get what is going on during most of the playing, I mean, second to second. What is it that you do when you're playing the game? That is what you often want to find out through your prototype. (Game Director at an AAA-developer)

Since the prototype represents a part-to-whole figure, this understanding and the lessons learned usually include aspects of the whole game beyond the prototyped game topos. In this process the trust for game topos is restored (Manker 2011a; Manker 2011b). Thus, game prototyping can be viewed as a process of learning, as well as being a negotiation, where a part of the design is communicated using an interactive artefact until trust in that part is restored. Learning is, in this context, seen as a deepened understanding of the game being created. Negotiation is, in this case, viewed in a broad sense including negotiating within one's own mind (Billig 1996; Mendelson 2002; Wolrath-Söderberg 2008). Game doxa, game topos and part-to-whole figures provide useful tools to analyse the communication functions of a prototype. They are also useful when talking about the prototypes in general as they are concepts that grasp the complex qualities of a prototype in a good way.

In a creative process an element of chaos is needed, but also a framework that generates innovativeness. In many cases, according to the respondents descriptions, the element of chaos is ample while the framework is somewhat lacking. The designscape presented below is intended to be one such possible framework.

Designscape

By and large, except for a few independent developers, (digital) game development is a group effort. Usually, every member in the team counts and everyone's opinion is valued. This is true throughout the development of a game. During production many different prototypes are constructed to address different game topoi where the group lacks trust for the design.

It has become evident that game designers and development teams use a lot of technical tools to make their ideas playable as prototypes but it seems there are no tools that aid in the process of assessment of these prototypes. One might count software support for agile processes, such as scrum, as such an aid but these support softwares tend to focus on task management and time boxing and not on retrospective process and assessment. Here we have potential for improvement. In the interviews no one specifically mentioned the need for such assessment tools but in the analysis of the material it appears clear that such tool would be beneficial. ALead Implementor at a AAA company spoke about the different criteria they need to take into account when making design decisions. Not only the game itself and relations between different aspects within the game, but also the literary original the game is based on, the previous game which the game is being designed as a sequel to, relation between different departments in the design environment, story related consequences, etc. Many of the respondents, in particular the ones from AAA companies, also stated that the team as a whole need to be involved in the decisions and that it is important to find the right mix of people and competences and to obtain good communication within the team. Some model or tool concerning the assessment of prototypes in game design would also serve its purpose if it improve the communication in the team. The tool would then potentially grant both an overview of the opinion and trust in the design features and a deepened discussion around them. Both the present trust and the trust-development over time could be useful information.

Based on the empirical data and the theories described I will here suggest a model, the designscape, that take input from the whole design team into account. In this model, relationships between different game topoi and different team members can be traced over time. The designscape is intended to be a tool for a group with which they can generate knowledge about the prototyping process and increase awareness of how they develop their trust in the games different aspects while prototyping.

Let's visualize the game doxa as a water surface, based on the commonly used image that the doxa is a mental landscape. A water surface can be hilly like a landscape but is at the same time, as the creative process, something flexible and constantly shifting. It is also transparent, like a lens. The game doxa is a landscape-shaped lens. The game vision is seen through this lens. A water surface in turmoil consists of a number of crests and troughs. These are the game topoi shaping the game doxa and its transparent landscape. The image of the game is seen through the game doxa . The heights of the crests and the depths of the troughs would indicate the amount of trust or distrust in specific parts of the design. Deep troughs would indicate a high degree of need to prototype the game topos connected to it. If the amplitude of the crests and the troughs is large, the image of the game is more diffuse. As the development of the game continues the surface will change and along with it the image that the team has of the finished game.

In order to make the designscape a more usable model, let's place it in a coordinate system. A game topos depends on aspects of the game as well as the team members' trust in these aspects. If team MEMBERS (m) are placed on one axis of the surface, the ASPECTS (a) of the design on a second axis and the level of TRUST (t) on the third, the surface will show some facts that may be of value to a design process. The designscape would be able to provide information such as:

Figure 1: The Designscape

· The general formation of the wave's crests and troughs (^u^ ) is an indicator of design state. If there are many crests the general opinion is quite positive concerning the game. If there are many troughs the general opinion is that there are many problematic areas. If the differences between the crests and troughs is big, i.e. some big waves, there are big differences in opinion about the game within the group and if the surface is rather calm the team have more homogenous thoughts about whether the game is on a good track or not (note that this includes the case where most of the team see many problems in the game, which would result in a low, calmer surface)

· The measurement ^u^ might be useful for measuring the relative velocity with which the game progresses, based on team members trust and developed understanding of the game. This would need the assessment of trust to have an absolute scale where the surface in the model for example starts at "it is only an idea", rising as the game develops and (hopefully) reaching the highest level meaning "shippable".

· If the surface shows apparent waves in the aspect-axis or member-axis (≈ (m) and ≈ (a)) it indicates that one member is dissatisfied with many aspects of the game or that one aspect of the game is dissatisfying for many members.

· If the surface is tracked over time the frequency of the ripple (f(u) ) will tell you something about prestige and trust within group. A slow ripple indicates deadlocks whereas faster ripples indicate trust within the group. Although very fast ripples may indicate uncertainties concerning the vision.

· Another thing that could be observed over time is patterns in the ripple (:: (m,a) ). Here, links between how the team members learn about different game topoi could be observed, such as when one aspect of the game is addressed and solved, others arise, and that there is a link somehow between these. The designscape reveals part-to-whole relationships in relation to this. Also, since the members are represented, patterns in the ripple may reveal interpersonal relationships. For example leaders and followers such as when one member of the team is dissatisfied a number of others follow or vice versa.

Other interpretations or extractions of knowledge are possible. The exact implications of the designscape is of course yet to be determined through testing but it would clearly provide information that could be interpreted and traced in order to understand the design process better. The designscape may be more useful during early stages of the game development process however the more agile the process the further along in the process the designscape will likely be useful.

The data for the designscape could collected when using a prototype, embedded in the gameplay (as is usually the case in public beta testing), or in the game world, or as a separate assessment tool intended to be used parallel to the prototype testing. It could also be included in the agile process, at daily scrums, or at sprint planning meetings. (Daily scrums are short meetings with the team, held every morning. Sprint meetings are longer planning and retrospective meetings held at the beginning and the end of a defined time period, normally 2 weeks) (Keith 2010).

The following is an example (partially inspired by an observed student project) to illustrate how the use of the designscape is intended. This is the in accordance with idea of the designscape as it exists now, in an untested state. Note that the ambition is to develop the use of the designscape in iterations and in an agile manner, without rigid pre-defined goals. In this example an Ipad racing game is being developed. There are eight members in the team: two designers, three artists, and three programmers. The team makes use of scrum from late concept discovery throughout the production to release. They have a short statement which they test all new features against: "To drive a car in this game feels fast and crazy and it makes you laugh sometimes". As a part of the scrum process, they have daily meetings. The project is presented in front of the other project groups once or twice a week. As a suggestion, the data that feeds the designscape could be collected through three occasions:

· During the morning meetings the members will, in addition to the regular scrum statements, "What have I done since yesterday? What will I do today? These things may stop me from succeeding?" (Kieth 2010), also state one aspect of the game that they think is going well and one they do not think is going well, and rate them from 1-6 where 1 is "not working at all" and 6 is "Ready to ship". When they state the two aspects, other team members may, if they want, take the opportunity to grade these aspects as well (same scale).

· As soon as a prototype is made in order for the team to test something, the features that are to be tested by the prototype are specified and graded from 1-6 during testing.

· During the weekly presentations a prototype of a part of the game is shown and tested by others, outside the team. A number of features of the game that the team wants to have feedback one (typically 3-5), are made possible to grade on a separate form, for anyone testing this prototype.

During all three of these data collection occasions the grades are collected and inserted into the designscape model by the scrum master. The visualization can be viewed by anyone at any time and the team members are encouraged to bring things they see in the visualization up for discussion. The scrum master saves an image of the visualization every day. An animation of these images can be viewed by anyone in the team at any time.

Almost all game development today is done in relatively short iterations and in agile workflows. To have access to an overview of the teams trust in the design and to be able to track this information and compare it over time have several potential values for the design process and the end result

· Problems in the team concerning lack of trust in the design could be observed earlier and addressed

· Patterns concerning how lack of trust develops in a specific team may be identified. This information is probably more useful for the individual team than as patterns of general nature. But this delimitation is also a value in itself, not the least since it supports the kaizen of scrum, which is the goal to constantly change the group for the better (Kieth 2010).

· Knowledge about a specific group's dynamics is only accessible by studying that particular group. When the data in designscape is stored over time it becomes a valuable source of information for studying such dynamics.

· Team members may feel a closer link between their opinion and the assessment material, making them feel more influential

· In the designscape the status of the design can be communicated in an overview to all members, in the moment, and without extra effort. The whole team will be able to get more connected to how the game is developing.

Conclusion

Various relationships between game prototyping and communication have been presented. Based on rhetorical analysis of interviews with game designers a visualization model, the designscape, is suggested as a tool to better understand the design process and the negotiation process involved in prototyping during game design. This tool builds upon rhetorical qualities of a prototype and is meant to be used within a design team. The designscape has the potential to make a number of facts concerning the design process extractable and visible, such as relative difference in opinions around the game, general level of trust in the game, specific problem areas in the design, how the group dynamic affect the trust in the game, how changes in different design features affect each other, etc. The data collected when using the designscape also has a potential to enhance the prototype's communicational quality and to better and earlier reveal changes in trust and patterns in the dynamic of a specific design team. Over time this would likely improve the team's spirit and confidence and increase the understanding of the games they are developing including the design processes they are a part of.

Acknowledgments

The author would like to thank Ulf Hagen, my research fellow, who has been great to have as a talking buddy and who has taken part in collecting the data and transcribing the interviews; Mattias Arvola, who continuously provides excellent support as my supervisor; Jonas Linderoth, my co-supervisor who gives valuable input when needed and ensures the connection to game studies; Martin Jonsson, my second co-supervisor for his help on-site; and Maria Wolrath-Söderberg who has contributed many brilliant comments in general and in particular on the rhetoric sections. I would also like to thank The Foundation for Baltic and East European Studies which provided the funding that made the collection of empirical data possible and the department of Media Technology at Södertörn University that co-funded my research.

References

Agustin, M., Chuang, G., Delgado, A., Ortega, A., Seaver, J. and Buchanan, J.W. (2007) Game sketching. In: Proc. of the 2nd international conference on Digital interactive media in entertainment and arts, (DIMEA '07). New York : ACM, p.36-43.

Arnowitz, J., Arent, M. and Berger, N. (2007) Effective Prototyping for Software Makers. Amsterdam: Elsevier.

Arvola, M. and Artman, H. (2007) Enactments in interaction design: How designers make sketches behave. Artifact, 1 (2), p.106-119.

Billig, M. (1996) Arguing and thinking: A rhetorical approach to social psychology. New ed. Cambridge : Cambridge University Press.

Brathwaite, B. and Schreiber, I. (2009) Challenges for game designers. Boston, MA : Course Technology/Cengage Learning.

Buxton, B. (2007) Sketching user experiences - Getting the design right and the right design. Amsterdam : Elsevier.

Costikyan, G. (2002) I have no words & I must design: Toward a critical vocabulary for games In: Mäyrä, F. (ed.) Proc. of Computer Games and Digital Cultures Conference. Tampere : Tampere University Press, p.9-34.

Dirven, R. and Pörings, R. (2003) Metaphor and metonymy in comparison and contrast. Berlin : Mouton de Gruyter.

Ebert, R. (2010) Video games can never be art. Chicago Sun Times, April 16, 2010. (Including comments). [Online] Available at: http://blogs.suntimes.com/ebert/2010/04/ video_games_can_never_be_art.html [Accessed 29 March 2011].

Egenfeldt-Nielsen, S. (2006) Overview of research on the educational use of video games. Digital Kompetanse: Nordic Journal of Digital Literacy, 1 (3), p.184-213.

Fullerton, T., Swain, C. and Hoffman, S. (2008) Game design workshop: A playcentric approach to creating innovative games. Amsterdam : Elsevier.

Fullerton, T., Chen, J., Santiago, K., Nelson, E., Diamante, V. Meyers, A., Song, G. and DeWeese, J. (2006) That cloud game: Dreaming (and doing) innovative game design. In: Proc. of Sandbox '06 Symposium ACM SIGGRAPH symposium on Videogames. New York : ACM Press, p.51-59.

Glinert, E. (2010) Rapid, iterative prototyping [Online]. IGDA Webinar. Available at: http://www.slideshare.net/firehosegames/rapid-iterative-prototyping-for-igda-12710-3007252 [Accessed: 2 February 2010].

Hagen, U. (2010) Designing for player experience - How professional game developers communicate design visions. In: Proceedings of DiGRA Nordic 2010: Experiencing games: Games, play, and players (Stockholm, Sweden, 2010).

Hellspong, L. (2008) Förhandlingens retorik: Samtalskonst för arbete och samtalskonst för arbete, skola och samhälle. Lund : Studentlitteratur.

Jasinski, J. (2001) Sourcebook on rhetoric: Key concepts in contemporary rhetorical studies. Thousand Oaks, CA : Sage Publications.

Kaptelinin, V. and Nardi, B. (2008) Acting with technology: Activity theory and interaction design. Cambridge, MA : MIT Press.

Keith, C. (2010) Agile game development with Scrum. Upper Saddle River, NJ : Addison-Wesley.

Lim, Y.-K., Stolterman, E. and Tenenberg, J. (2008) The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction (TOCHI), 15 (2), p.1-27.

Macklin, C. (2011) DataPlay: Experiments in the ludic age. International Journal of Game-Based Learning, 1 (2), p.19-33.

Malone, T. W. and Lepper, M. R. (1987). Making learning fun: A taxonomy of intrinsic motivations for learning. In: Snow, R. E. and Farr M. J. (eds.) Aptitude, learning andi instruction III: Conative and affective process analyses. Hillsdale, NJ : Erlbaum, p.223-253.

Manker, J. (2011a) Game design prototyping. Games and Innovation Research Seminar 2011 (Tampere, May 5-6, 2011) [to be published].

Manker, J. (2011b) Game prototyping - The negotiation of an idea. DiGRA Conference: Think, Design, Play (Utrecht, The Netherlands, September 14-17, 2011).

Manker, J. and Arvola, M. (2011) Prototyping in game design: Externalization and internalization of game ideas. Proceedings of HCI2011: Health, Wealth & Happiness: The 25^th BCS Conference on Human-Computer Interaction (Newcastle Upon Tyne, UK, July 4-8, 2011).

McLuhan, M. (2004) Media. Skarpnäck : Pocky.

Mendelson, M. (2002) Many sides: A Protagorean approach to the theory, practice and pedagogy of argument. Dordrecht : Kluwer Academic Publishers.

Moriarty, B. (2011) An apology for Roger Ebert. Lecture given at Game Developers Conference 2011 (San Francisco, CA).

Salen, K. and Zimmerman, E. (2004) Rules of Play. Cambridge, MA : MIT Press.

Schell, J. (2008) The art of game design: A book of lenses. Amsterdam : Elsevier.

Schaller, D. (2005) What makes a learning game? [Online] Eduweb. Available at: http://www.eduweb.com/schaller-games.pdf [Accessed: 2 December 2011].

Sellen, A., Rogers, Y., Harper, R. and Rodden, T. (2009) Reflecting human values in the digital age. Commun. ACM, 52, (3).

Smuts, A. (2005) Are video games art? Contemporary Aesthetics, 3.

Snyder, C. (2003) Paper prototyping: The fast and easy way to design and refine user interfaces. Amsterdam : Morgan Kaufmann Publishing.

Swink, S. (2008) Game feel. Amsterdam : Morgan Kaufmann Publishing.

Tavinor, G. (2009) Videogames, interactivity and art. APA Newsletter on Philosophy and Computing, 9, p.26-28.

Wikipedia (2011) Creativity [Online]. Available at: http://en.wikipedia.org/wiki/Creativity [Accessed 2 December 2011].

Wolrath Söderberg, M. (2003) Finns det genvägar till klokhet? Lund : Studentlitteratur.

Wolrath Söderberg, M. (2008) Topical learning. In: van Eemeren, F., Williams, D. C. and Zagar, I. Z. (eds.), Understanding argumentation: Work in progress. Amsterdam : Sic Sat Rozenberg.