As per the criteria of the paper sampling process, all papers included empirical findings from game developers. This naturally meant that the reviewed papers were highly reliant on case studies (e.g. Amanatiadou and Van De Weerd 2009; Cohendet and Simon 2007; McAllister and White 2015; Myllärniemi et al. 2006; O’Hagan and O’Connor 2015; Vanhala and Kasurinen 2014). There were, however, some examples of research conducted on individual developers independently of any ongoing projects or studio work that dealt with experiences and attitudes towards their craft in a more general sense (e.g. Murphy-Hill et al. 2014; Wang and Nordmark 2015). As for data gathering methods, most of the reviewed papers relied primarily on qualitative methods, and semi-structured interviews were particularly common (Kasurinen et al. 2013, 2014; Kultima 2010). Some papers also used surveys, often to supplement or support the material gathered through interviews (Koutonen and Leppänen 2013; Murphy-Hill et al. 2014; Wang and Nordmark 2015). There were also a couple of examples of ethnographic research, in which the authors either recounted their own experiences working in development teams in the past (Walfisz et al. 2006) or kept journaled accounts of on-going development processes (Bryant et al. 2010; Cohendet and Simon 2007; Nelson and Palumbo 2014).
The vast majority of studied cases focused on what could be classified as more “straight forward” entertainment products for various platforms. There were a few exceptions, however, that focused on development of serious games (Ruggiero and Watson 2014; Tran and Biddle 2008). In this review, we do not make a particular distinction between the genres of games being developed, and we consider serious game developers to also be part of the broader games industry.
The investigated game companies in these papers have a varied international spread. Research studies in northern Europe and Canada constitute the largest portion of the reviewed set, while other regions are more sparsely represented. For example, no papers mention anything about Australian or African game development, making them the only excluded continents. Several papers investigate several game studios from different countries simultaneously (Chung and Fung 2013; Musial et al. 2015; Stacey and Nandhakumar 2008), while the most common approach seems to be to focus on one particular region; this is likely due to the researchers’ chosen methods (interviews) making it preferable to confine their study to one region (Hotho and Champion 2011; Zackariasson et al. 2006). Some of the papers do not include any descriptions of where the study was conducted (Drachen et al. 2013; O’Hagan et al. 2014; Tran and Biddle 2008).
The game studios studied in the reviewed papers differ from one another both in terms of size and organizational structure, ranging from small startup companies with a few people working on a single project (e.g. Llerena et al. 2009; O’Hagan and O’Connor 2015; Tran and Biddle 2008) to large established AAA studios with hundreds of employees working on multiple projects, sometimes across international borders (Cohendet and Simon 2007; Drachen et al. 2013; Walfisz et al. 2006); a number of studios fell somewhere in-between the two extremes (Hotho and Champion 2011; Myllärniemi et al. 2006; Nelson and Palumbo 2014). The studied game studios also worked with different platforms, such as PC (Kasurinen et al. 2013; Walfisz et al. 2006) mobile (Kultima 2010; Llerena et al. 2009; Myllärniemi et al. 2006) console (McAllister and White 2015) and web-browsers (Tran and Biddle 2008). It is difficult to determine whether there is a significant weighting towards any particular platform as many papers did not clearly state the examined studio’s target platform, and many studios also worked across many different platforms simultaneously. Thus, the set of reviewed papers seem to represent many different types of game development situations.
Creating an Experience
The first main theme in the studied material relates to how the game experience is created. This includes questions such as: how game ideas are born; when and how is the game design made; and what is the role of game testing. Testing, design, and ideation may not be exclusively relevant to game development as they, for example, happen in software and information system development as well. They are, however, uniquely approached in game development in that they are considerations that extend beyond functionality and effectivity. Many of the reviewed papers aimed to understand this distinctive characteristic of game development, making it a frequently recurring and nuanced theme in this analysis.
Creativity and Ideation
Creativity is an aspect of game development that is addressed in a majority of the papers. In many of them, there is an explicit focus on creativity and innovation in game development (Hagen 2012; Hodgson and Briand 2013; Hotho and Champion 2011; Kultima 2010; Lê et al. 2013; Llerena et al. 2009; Musial et al. 2015; Tschang and Szczypula 2006).
One theme that is present in most articles relates to knowledge architecture and the flow of ideas in game production. This includes the inspiration of original game ideas (Hagen 2012; Kultima 2010), how ideas transform during the process (Kultima 2010; Tschang and Szczypula 2006), and how ideas are formed in the interplay between different development groups and testers (Cohendet and Simon 2007; Lê et al. 2013; Simon 2006; Stacey et al. 2007; Wang and Nordmark 2015). There are strong indications that the creative endeavours in the game industry involve many individuals, and that collaboration is important:
The sources of creativity as well as efficiency at [Company] rely on a subtle alchemy among communities of scriptwriters, game-designers, graphic artists, sound designers, software programmers and even testers. The team is important for the creative process. (Cohendet and Simon 2007, p. 591)
Not only are interpersonal relationships important for this type of creative ideation, but several studies (Lê et al. 2013; Stacey and Nandhakumar 2008, 2009; Tschang and Szczypula 2006; Wang and Nordmark 2015) also report how the interplay between ideas and the technology used to realize them affect the process. New technological possibilities, as well as limitations in the technology and even bugs, can give rise to new game concepts. The creative game development process is non-linear, whereby ideas evolve during the development and test process: “Game ideas are prone to be altered in one way or another during the design process. This was emphasized by virtually all of the interviewees” (Kultima 2010, p. 36).
A related issue observed in a large number of papers (Cohendet and Simon 2007; Hotho and Champion 2011; Kultima 2010; Musial et al. 2015; Simon 2006) is how creativity affects management of the game development process. These studies give a uniform message that creativity implies the need for more flexible processes, room for collaboration, and openness to change. As stated in one paper, “Management of creativity at work is merely seen as the art of setting the material, social and symbolic limits of the workspace collectively experienced as a creative play-ground” (Simon 2006, p. 121).
The auteur tradition, which is strong in the movie industry, has very limited support in the game industry. Only one study (Hotho and Champion 2011) reports on a case where one person tried to control the whole creative process. This study reports on how this effort had several negative consequences. In summary, the empirical studies on game development give a relatively uniform picture: that creativity is achieved through a collaborative, test-driven process where structure, documentation and control are de-emphasized.
Testing and Player Experience
Despite the lack of standard development methods and loose requirement specifications, game features, feature changes, and development goals still have to originate from somewhere. Play testing is an activity that is highlighted in many studies as one of these origins, and is often described as tightly connected to the “player experience” goal that many game developers pursue. As summarized by one interviewee in Kasurinen and Smolander (2014), “You can plan for a large number of things, but ultimately the final decision is made when actual people try out the idea.” Overall, developers are highly aware of, and accepting towards, change, and it is treated as an inevitable part of the process and crucial for honing the experience: “The game experience rules. Change is imperative” (Walfisz et al. 2006, p. 492).
This has implications on the conception of a product, and in particular how developers discuss the scope of a prototyping process. In game development companies the term ‘prototype’ is used in broad sense to refer to a game under development and its large number of different incarnations throughout the development process:
Further, the first prototypes produced by the R&D team are replaced by others (including the one working with the SDK), which will subsequently be replaced by game prototypes. In a sense, there are only prototypes in videogame development. (Lê et al. 2013, p. 55)
The role of testing and player experience strongly influences the way game development is organised. Many studies report that companies adopt some kind of staged process. A common structure is to have the following four stages: ideation, pre-production, production, and post-production. A stage-gate methodology is discussed in some cases (Cohendet and Simon 2007; Hodgson and Briand 2013; Zackariasson et al. 2006), but it appears that the nature of game production makes it hard for developers to adhere to it even at its most general formulation. Play testing is conducted in all stages of the development process, and the result of these tests can have an impact on the product, irrespective of phase. As stated by an interviewee: “If a tester comes to say that this does not work, there is not fun in it, you really cannot leave that in the game, you have to fix it” (Kasurinen et al. 2013, p. 14).
The testing of the game may also lead to the identification of new ideas (see Creativity), which were not possible to foresee at an early ideation stage. Ideas can appear in all stages of game production, and they can originate from any of the involved actors, including testers: “You never know where the next great idea is coming from—as we saw at Goo, some even came from secretaries” (Stacey and Nandhakumar 2008, p. 145).
Interestingly, only a few studies (Koutonen and Leppänen 2013; Petrillo et al. 2009; Walfisz et al. 2006) discuss the concept of ‘feature creep’, which is a risk that arises when changes are allowed during all stages of production. Since it is difficult to clearly identify which features (e.g. themes, game mechanics, aesthetics, technologies, etc.) will ultimately result in the desired player experience, game developers often remain open to new ideas late in the production process (Petrillo et al. 2009). The main downside of this open-ended ideation is the high risk of feature creep, which is present in game development to a larger degree than in, for example, software development (Wang and Nordmark 2015). Developers try to minimize this risk by emphasizing a flexible and comprehensive early stage of game production (Cohendet and Simon 2007; Schmalz et al. 2014). Companies can have several potential products in the ideation and pre-production phases, and early and frequent playtesting of these prototypes will determine which should go into production. One of the papers conclude that the open-ended nature of game development is inherently risky, but that “the project structure itself often mitigated risk by emphasizing prototyping, pre-production and the early jettison of troubled projects” (Schmalz et al. 2014, p. 4332).
Requirements, Subjectivity and Flexibility
The vast majority of papers that discuss requirements as an aspect of game development characterize them as being highly subjective (Alves et al. 2007; Kasurinen et al. 2014; Murphy-Hill et al. 2014; O’Hagan and O’Connor 2015), unpredictable (Kasurinen et al. 2014; Tran and Biddle 2008), and flexible (Daneva 2014; Schmalz et al. 2014). The subjectivity is often tied to the artefact itself, as gameplay goals (e.g. aesthetic goals, or gameplay goals such as being fun or thrilling) are mentioned as something that is difficult to approach in a formalized and well-defined way (Kasurinen et al. 2014; Murphy-Hill et al. 2014). While the subjective concept of “fun” has often been described as something defined by the developers themselves in smaller studios (Zackariasson et al. 2006), larger studios have used identified subjective preferences and usability concerns of their target audiences as a guiding requirement (Alves et al. 2007; Bryant et al. 2010; Murphy-Hill et al. 2014). The unpredictability and changing nature of requirements are mostly discussed in terms of how they necessitate iterative working processes (Schmalz et al. 2014). Constant team communication (Land and Wilson 2006; Tran and Biddle 2008) and testing (Cohendet and Simon 2007; Kasurinen et al. 2014; Tran and Biddle 2008; Walfisz et al. 2006) are often mentioned as efficient means in scoping out and identifying requirements as production progresses. In essence, the nature of requirements in game development is often seen as one of the primary causes for why game development processes turn out the way they do.
This subjectivity is what distinguishes game requirements from other software development practices. For example (Murphy-Hill et al. 2014) highlight this stark difference through interviews with game developers who have also had non-game software development experience. According to their work, game requirements differ from those of regular software development, and requirements also vary from game to game, meaning that there are few, if any, constant transferable requirements between games (Murphy-Hill et al. 2014; Wang and Nordmark 2015). A developer interviewed in (Murphy-Hill et al. 2014) for example, stated that:
… in an e-commerce application, a user has a task to complete that typically takes only a few minutes. … the requirement for games is that the user should be able to stay engaged on multiple timescales, and the mechanism to achieve that will vary from game to game. (Murphy-Hill et al. 2014, p. 4)
When requirements are mentioned, they are often seen as a necessity due to their prevalence in traditional software development (Kasurinen et al. 2014; Land and Wilson 2006; Murphy-Hill et al. 2014); however, their merits and actual practical application in game development is debatable. In one of the reviewed papers, for example, developers were asked to evaluate how applicable ISO standardized software development processes were to their own working processes, to which they responded: “The first thing I see here is that requirement analysis is completely done before construction. So design is finished before anything is implemented… that’s just not the way it happens” (Kasurinen et al. 2014, p. 13). For most game developers, requirements are rarely seen as an identified goal that must be fulfilled, but rather something that is to be discovered during the development process (Daneva 2014; Tran and Biddle 2008).
The Technology and Creativity Schism
The general ebb and flow of control and unrestricted creativity constitute a common thread in the material, and has often been described as a source of ambivalence and conflict:
We also found that conflicts may occur between designers and developers. This happens because game designers, who are especially creative individuals, generally try to include features that are very hard to implement. They argue that such features may improve the gameplay and the overall look and feel of the game. However, there is no formal process to assess that; just common-sense is used. Normally, the final game is the result of trade-offs among creative design, technical constraints and platforms constraints. (Alves et al. 2007, p. 279)
A constant thread is the strong emphasis on the importance of a communal, democratic, and flexible production pipeline (e.g. role overlap, informal communication, team-based decisions, and shared knowledge architecture). Creativity was also equally emphasized as the driving force, and ultimate outcome, of game production (Kasurinen and Smolander 2014). There were, however, a few notable exceptions to this openness and flexibility: developers working with the software and technology aspects of game production had a comparatively protective approach to their work and contributions. Programmers in game studios could, for example, regard management with various levels of distrust if they were perceived to lack the necessary technological know-how to make realistic decisions (Murphy-Hill et al. 2014; Wang and Nordmark 2015).
In some cases, this concern was proven to be well founded, as managers sometimes professed to lacking the necessary understanding of implementation for making sound evaluations and management decisions regarding software aspects of game development; this could sometimes jeopardize a project’s success (Schmalz et al. 2014). Programmers sometimes held a similar level of distrust towards their peers working in different disciplines of production—perhaps more so towards graphics artists and designers—whose creativity could seem detached from realistic implementation (Alves et al. 2007; Kasurinen and Smolander 2014; Stacey and Nandhakumar 2009):
When a game-designer asks a programmer to design an animated “rope” as a decorative object in a virtual setting, he thinks its a very simple task and does not understand the rebuttal from the programmer, rather promoting a stick. (Simon 2006, p. 120)
In essence, programming and technological knowledge seem to be under-appreciated and misunderstood in terms of their contribution to creativity (Kasurinen and Smolander 2014; Musial et al. 2015; Simon 2006; Wang and Nordmark 2015). In a study by Kasurinen and Smolander (2014), this was coupled with a sentiment that programming was the linchpin making the creation of games fundamentally possible: “…In their perspective the software development work was the actual requirement to create a game; without programming skills there would be no game product, but even without a competent artist you could create at least something.”
While input and ideas from designers and artists are of course seen as an important part of the production process, they could be regarded with increased skepticism if they came from colleagues with little programming knowledge.
Creating a Product
The second main theme in the studied material concerns the industrialization of game production. This theme is focused on how production aspects, applicable in most production processes, are approached in the games industry. This includes project management, documentation, planning and the role of tools used during production.
Methods in Theory and Execution
One theme that emerges clearly from the studied papers is that there is no standard for game development, and that developments methods are applied differently from how they are prescribed (Kasurinen et al. 2014; Kasurinen and Smolander 2014; Koutonen and Leppänen, 2013; Lê et al. 2013; Murphy-Hill et al. 2014; O’Hagan and O’Connor 2015; Schmalz et al. 2014; Stacey and Nandhakumar 2008; Walfisz et al. 2006; Zackariasson et al. 2006). Developers’ reasons for deviating from established project management and software engineering methods mainly stem from the focus on player experience (Kultima 2010; Murphy-Hill et al. 2014; Walfisz et al. 2006; Wang and Nordmark 2015). As stated by Hodgson and Briand (2013): “Our results suggest that game developers focus on soft values such as game content or user experience, instead of more traditional objectives such as reliability or efficiency.”
Many companies’ working methods are based on concepts from Agile development philosophy (Kasurinen and Smolander 2014; Murphy-Hill et al. 2014; Nelson and Palumbo 2014; Schmalz et al. 2014; Stacey and Nandhakumar 2008; Walfisz et al. 2006), but there are indications of challenges and problems when Agile is put into a game development context. One reason identified for this is the mix of professions involved in game production:
We’ve got so many specialists on the team, so the kind of planning that you usually do in Agile doesn’t work quite so well… You know [specialists] are more concerned about the creative process than an engineering process. (Murphy-Hill et al. 2014, p. 7)
The Agile methods are thus applied unorthodoxly, compared to the “regular” software industry, which regards Agile, and associated processes such as Scrum and eXtreme Programming, as being flexible but relying on an underlying structure and framework of planning, iterations, and backlogs (Hodgson and Briand 2013). This is, again, exemplified by studies which have analysed the applicability of ISO development standards in game development, and which conclude that the standard is difficult to implement in game companies (Kasurinen et al. 2013, 2014). Interviewed developers in other studies state, in clear terms, that Agile is unsuitable for their working processes: “We have a problem because the artists aren’t Agile. They detest it! … That’s a problem. There’s a dual system happening here.” (Hodgson and Briand 2013, p. 320).
The challenge of controlling and standardizing the process of creating a product that is largely unpredictable and open to creative input until a very late stage of development is an issue that has been discussed in many papers (Cohendet and Simon 2007; Murphy-Hill et al. 2014; O’Hagan et al. 2014; Tschang and Szczypula 2006; Wang and Nordmark 2015), and these discussions are anchored in many different parts of the development ecosystem. It has been described as an issue with requirements, creative autonomy, technical constraints, or as a management issue, which might suggest that game development does not easily adhere to one particular methodological framework.
Documentation and Shared Objects for Collaborations
A strong trend in the game development literature is a very low focus on documentation and a strong focus on playable prototypes. The most frequently mentioned documentation (Alves et al. 2007; Kasurinen et al. 2014; Stacey and Nandhakumar 2009; Wimmer and Sitnikova 2011) is the game design document. It is worth noting that several of these studies more often identify shortcomings than benefits with the documental approach to game design. For example: “Even an apparently complete [game design document] is likely to change during the development process” (Alves et al. 2007, p. 278). Or, as stated by an interviewee: “When the production started, the specifications went out of the window… There simply is not enough knowledge to make a full design at the early stage.” (Kasurinen et al. 2013, p. 14).
In place of an agreed-upon design document, one important element of the development process that is addressed in several studies comprises the softer aspects of team cohesion and interdisciplinary collaboration (Cohendet and Simon 2007; Murphy-Hill et al. 2014; Tran and Biddle 2008; Wang and Nordmark 2015). Frequent and open knowledge-sharing (Cohendet and Simon 2007; Dezso et al. 2010; Llerena et al. 2009) and continuous informal dialogue (Tran and Biddle 2008) emerged in the papers as more widely used methods of keeping a team’s collaborative creative vision intact during development. For example:
It’s very much a dialogue, we try not to have too formal split between tech and creative team when thinking about this, but prioritize what the user experience should be and when we can ship at target quality. (Wang and Nordmark 2015, p. 279)
Learning about experiences from others exposes each member to the different aspects of the game development process. As a result, the team is more empathetic to different disciplinary perspectives and approaches. (Tran and Biddle 2008, p. 51)
It is also important to note that the producer is sometimes highlighted as having an important role in facilitating these processes; however, almost none of the reviewed papers focused on describing the role of the producer in game development, with only Schmalz et al. (2014) being a notable exception.
The Tools Used in Game Development
Software tools within game development are sparingly discussed in the reviewed literature. The papers that discuss software tools to a larger degree (Kasurinen et al. 2013, 2014; Kasurinen and Smolander 2014; Llerena et al. 2009; O’Donnell 2011; Wang and Nordmark 2015; Vanhala and Kasurinen 2014) clearly highlight the differences between game studios and how they use them. Some game studios create their own development tools from scratch, some modify existing ones, and some use third-party tools to create games. There is a difference between how these tools are selected and used, depending on company structure and size (Kasurinen et al. 2013, 2014; Stacey and Nandhakumar 2009). Small-to-medium sized game studios in particular outsource their game engine development (Kasurinen et al. 2013, 2014; Kasurinen and Smolander 2014; Wang and Nordmark 2015; Vanhala and Kasurinen 2014). The tools used in larger organizations reflect a more structured and formalized development process. Development support tools such as version control and file-sharing services, however, are commonly used in game development organizations, irrespective of size.
The articles that do discuss software tools often focus on the importance of an effective tool pipeline, tool selection and usage, and game developers’ experience. The use of software tools is very dependent on organization and surrounding circumstances. Therefore, they are often used differently.
Requirements, Structure and Formalization
There are a few specific areas in game development in which requirements are described in a more “traditional” manner as a list of fixed, objective, necessary goals that developers need to achieve. In papers dealing with large development projects, for example, AAA studios working with external stakeholders such as publishers, platform holders or investors, technical requirements seem to become significantly more explicit and static (Cohendet and Simon 2007; Hodgson and Briand 2013; Walfisz et al. 2006). For example, games released on major hardware-specific platforms (e.g. Microsoft, Sony, or Nintendo consoles, or different brands of phones) need to adhere to rigorous lists of requirements on performance, compatibility, and usability; in essence, software architecture seems to be one of the main areas of games that have rigorous requirements (Alves et al. 2007; McAllister and White 2015; Myllärniemi et al. 2006; Stacey et al. 2007; Wang and Nordmark 2015).
In situations where spontaneous communication is difficult, there is a need for formalized documentation and requirements (Alves et al. 2007; Schmalz et al. 2014; Stacey et al. 2007). In companies that did extensive outsourcing, or engaged in other forms of cross-company collaborations, requirements are often described as a crucial tool to ensure that the—normally quite messy and informal—act of game development could be channelled towards a clear goal (Hodgson and Briand 2013; Stacey and Nandhakumar 2008). In these cases, requirements seem to be used as a form of risk management, as it gives stakeholders an opportunity to present their expectations on developers’ performances, which developers then become beholden to (Hodgson and Briand 2013; Stacey et al. 2007; Walfisz et al. 2006).
In summary, there is no real consensus on the exact requirements for game development. The use of formalized requirements in development seems to be closely tied to a game studio’s size and “maturity”.