Serious games design knowledge - Experiences from a decade (+) of serious games development

INTRODUCTION: Serious games is an effort to combine the engagement and motivation from games with some sort of utility beyond mere entertainment. OBJECTIVES: The objective of this paper is to revisit and analyse six projects to explore the design space for serious games and derive design guidelines for serious games. METHODS: We analysed our project portfolio to identify a set of projects which satisfied well-established guidelines for design science research. By analysing these projects as well as their outcomes we generated a set of design principles for serious games. RESULTS: The results from this study is a conceptualisation of the design space for serious games and seven design principles. CONCLUSION: By explicating the game design component in serious games and relating it to the utility dimension we add to the understanding of the serious games from a game perspective, which is relevant to any development effort intending to use the persuasive and motivational power of games.


Introduction
During the past decades, developing serious games as solutions to a variety of problems in different application domains has been a continuously growing trend. Looking beyond the last decade, the same line of argument has been used even earlier. In fact, the term serious games is most often attributed to the book Serious Games [1], which renders the concept a history of at least 4 decades not counting ancient games such as Go or Chess which have also been attributed to learning (strategy for warfare). [1] states: "Games may be played seriously or casually. We are concerned with 'Serious Games' in the sense that these games have an explicit and carefully thought-out educational purpose and are not intended to be played primarily for amusement. This does not mean that serious game are not, or should not be, entertaining." Even though [1] focused on educational games, several application areas have since been introduced using the same line of argument. Examples include: marketing, training, healthy living, social change and more [2]. Hence there is a clear trend towards a variety of application areas which calls for a broader definition.
Based on, and in line with the previous works above and in accordance with the DIN specification [3], we define Serious Games as "games that engage the user and contribute to the achievement of a defined purpose other than pure entertainment (whether or not the user is consciously aware of it)." [4, p. 147]. This purpose may be formulated by the users themselves or by the game's designer, which means that a commercial off-the-shelf game used for non-entertainment purposes, as described by [5], may also be considered a serious game. Furthermore, it should be noted that even though neither [1] nor several other game scholars restricted serious games to being digital, it is digital serious games that have been mostly addressed, e.g. [2], and are in focus in this paper.
In essence, serious games are not only games, they are also utility systems. According to [6] IS researchers have the appropriate background to research serious games and to develop principles for their design and use. However, in this paper we argue that this is not necessarily the whole truth. Development of serious games should include knowledge of game design. Game design is an area of knowledge in itself and when introduced into the sphere of utility systems it should be treated with the same significance as any other disciplinary perspective of information system development. Therefore the gap is notable, and even in [6] game design is not listed among the sample of relevant disciplinary perspectives.
The utility aspect is at the core of the problem of serious games since it introduces a new aspect of playing which is incongruent with traditional philosophical stances about games. For example, [7] writes that a game is a voluntary, enjoyable and unproductive (in the sense that it does not produce any goods of external value) activity separate from the real world. This idea is central in game development, i.e. the value of playing a game is in the engagement and challenge and in creating an experience with the user. This makes games similar to other creative expressions such as literature, movies and music. It should be noted that game development is different from those in that it concerns creating gameplay experience [8]. In this article we view gameplay as interaction between the player and the game world, systems or rules, e.g. [9]. Playing a game is a meaningful activity in its own [9]. However, when the utility aspect is added the activity becomes similar to those typically addressed in the information systems community. This paper addresses the complexity of combining the two spheres of utility and gameplay experience and what challenges it introduces. We do this by discussing how serious games development can be framed as a specific case of design science research (DSR) combining game design with the utility aspects as typically framed in information systems research. In our case, this refers to the design and development of serious games and their application in various contexts. Any significant DSR program involves many researchers over several years. It is an evolutionary effort with a number of intermediate research results [10]. The serious games research discussed in this paper spans 14 years (2004 -2017) of applying serious games to different domains such as education, vocational and professional training, and rehabilitation.
The main contribution of this article is a conceptualisation of serious games development and a set of design guidelines for serious games, which are derived from our research projects.

Serious games from a utility perspective
Information system development (ISD) and computerized information systems are well-established areas of research and development. They have roots in engineering, i.e. the development of computerized systems to handle information and organisational data. Many of the early systems were transaction systems and as such, parts of the core of a company/organisation. Initially, they may best be characterized as systems for experts developed by the experts themselves. However, as computerization became ubiquitous there was an important shift towards developing systems for users that were not necessarily experts or colleagues with the same background and hence the term (end) user received a new connotation. For example, a skilled worker in his or her domain but not necessarily a person with deep knowledge of IT. This emergence of the field of information systems has since then developed into a multifaceted field of research.
The knowledge associated with developing information systems is captured in ISD methods aiming to organize and convey the complex combination of skills that are needed to develop an information system. This is proposed as the body of ISD knowledge (BoK) consisting of five ontological domains [11]: • IS development process knowledge (associated with the tools, techniques, methods and approaches used in systems development). Classified as a core competence area for IS developers in the IS BoK; • IS application knowledge (associated with typical IT applications and their use in a given domain) Classified as a core competence area for IS developers in the IS BoK; • Application domain knowledge (associated with the actual domain for which the system is built). This knowledge is most likely to reside with the domain experts working in the domain and absorbing it is a learning process throughout a project; • Technology knowledge (associated with different types of hardware and software and how they may be applied, examples are computers, operating systems and peripherals.); • Organisational knowledge (associated with the social and economic processes of the organisation in which the system is used). The organisational domain also includes human beings as stakeholders (the users, developers, managers) involved in ISD and use.
Obviously it is not possible to possess equally deep knowledge in all these areas. Hence, ISD development process knowledge and IS application knowledge are the two candidates for the core competence of IS experts [11]. Figure 1 summarizes our interpretation of IS development as an interplay between a developer organisation and a user organisation to produce a system where the main goal is to provide utility to the user/user organisation.

Figure 1. A typical IS development situation
If we perceive serious games development from an IS perspective, that is to solve an organisational problem and create value, they should share these features. The step between IS development and serious games should perhaps not be perceived as so dramatic if taking a starting point in IS BoK [11] and apply it to the serious games. The relation between the core competences of IS development and serious games development will be addressed in more detail in Section 2.1.

Game design and game development from an ISD perspective
In the subsections of 2.1 we give a short background to games and game design and how these areas relate to the ISD domain.

Games and game design
There are several definitions of games covering a variety of aspects. The diversity of definitions can be described in terms of a composite of aspects ranging from the artefact itself to its social and cultural use [12]. The complexity of the concept is illuminated by a thorough review of definitions to identify "points of interest" in the game design research community which characterize the phenomenon [12, p. 500]. Some of these are: rules; purpose and function; artefact or activity; the role of the player; (un)productiveness, competition or conflict; and, goals and end conditions. Some of these items concern the artefact and its anatomy, for example that games are rule based systems and that they are digital or physical artefacts. Other items concern their use and the role of the player, for example that games are unproductive [7] and that they are about competition or conflict between players. As is obvious, different definitions cover different aspects. We view a digital game as a digital artefact which is developed for the enjoyment and engagement of players. The Mechanics, Dynamics and Aesthetics (MDA) framework to capture this [13]. The main difference between games and other entertainment products is that their consumption is unpredictable since the chain of events that occur during gameplay and the outcome of those events are unknown at the time the product is developed [13]. This is described such as that the game designer construct the mechanics (the rules and interactions available to the player) which form a basis for the dynamic behaviour of the system during runtime, which in turn gives the emotional response evoked in the player when interacting with the game [13]. This makes game design a second order design problem [9], which forms a different type of design challenge from other entertainment products.
Game design is a central competence in game development. The first textbook on game design was published in in 1984 [14]. Four years later, the Game Developers Conference (GDC) was founded by its author. GDC is now the largest professional venue for game developers. Game design is the second largest track at GDC with more than 100 sessions each year [15]. Game design bears similarities with architecture and other types of design in that it is deeply interdisciplinary, combining elements of art, mathematics, engineering, social sciences and more. As an example, one of the first digital games in the Nordic countries was created by Piet Hein [16]. Apart from being a game designer, Hein also made contributions in mathematics, literature, furniture design and architecture. A more recent Scandinavian example is Josef Fares, who has been successful both as a film director [17] and as a game designer [18].
Academic studies of game design have mainly been conducted within the field of Game Studies. The focus of such research has mainly been on analysing existing games or gaming rather than studying the game creation process in its organisational setting [15,19,20]. The academic conception of game design is to a large degree influenced by textbooks authored by practitioners [21]. Some of the more influential such books include: Rules of play [9]; The art of game design: a book of lenses [22]; and Characteristics of games [23]. The ideation process in game development is to a large extent a collective effort [24]. Since game design is an integral part of game production and a game designer collaborates with other disciplines we claim that attention needs to be paid to game design in its organisational setting and that the same holds for serious games development.

IS development and games
Much like IS development, game development is also a multidisciplinary effort in itself and the game research landscape clearly reflects that [19]. Interdisciplinarity is necessary for any deeper understanding of digital games [19]. Hence, serious games share the quality of being multidisciplinary with the field of IS, even though this quality is not as well-captured and established under a specific field of research as is the case with IS development.
Digital games are software products and aspects of game development and game development processes have been somewhat addressed in the IS community [25][26][27][28]. The game development processes has been compared with other software development processes but with an addition of fuzzy requirements related to game design as opposed to defined user needs [25]. This means that the creative aspects of game development somehow complicate the development process. One of these aspects is referred to as gameplay requirements which is conceptualized in three ways: as a process; as an artefact; and as a relationship between the game creators and the players [26]. The first EAI Endorsed Transactions on Serious Games 07 2019 -08 2022 | Volume 6 | Issue 1 | e4 conceptualisation refers to the process that a player has to go through to achieve the end of a level. This is a series of tasks and challenges that the player has to carry out and overcome. The artefact view of gameplay is the set of rules, penalties and awards that constitute the game structure (composition of game mechanics to use the concepts of [13]). Viewed as an artefact, gameplay describes the admissible actions and constraints of the game. The relationship aspect refers to the unique and individual experience that occurs when the player interacts with the game. Other aspects of games are graphics, animation, storytelling, sound and music, which are fields of specialization in themselves to be integrated in the development process.
There are several generic descriptions of the game development process which commonly share the high-level phases: concept/ideation, pre-production, production and post-production.
However, digital games are multidimensional complex systems in themselves subsuming software complexity as well as artistic expression [9,29]. Similarly, there are additional challenges associated with coordinating multidisciplinary teams working towards fuzzy requirements such as creating a gameplay experience rather than fulfilling a functional requirement [30]. We are aware of fuzzy requirements in regular system development as well but gameplay requirements add to that complexity due to the nature of game desing being a second order design problem [9]. Gameplay experience is hard to define but we lean towards the definition: "the gameplay experience can be defined as an ensemble made up of the player's sensations, thoughts, feelings, actions, and meaning-making in a gameplay setting." [8, p. 091]. Due to the complexity of games and game development, the process of creating them is often quite unique as it involves technical as well as artistic aspects that have to be integrated and orchestrated to provide the intended gameplay experience.
Gameplay is an example of one distinguishing feature of games which is not easily captured within traditional requirement engineering [26]. Consequently, we claim that developing serious games is a huge challenge in combining game design with the utility aspect. Not only is it a matter of combining two areas of research and practice. They are also two multidisciplinary areas in themselves. Moreover, "[…] game development is not "just" software development, video games are not just games and the video game industry is not the software industry." [29, p. 17]. Figure 2 summarize our view of a typical game development situation in which the development team tasked with developing a game that should provide a compelling gameplay experience for players.

Figure 2. A typical game development situation
What we propose in this article is a marriage between the information systems development discipline, as an area covering the development and utilization of IT artefacts to create organisational value, and game development as an area in which serious games has its roots. The main line of argument for this marriage is that they share many traits, in particular serious games needs to incorporate the utility aspect of organisational value which is at the core of IS development. Indeed, a serious game is a utility system and has to fulfil all criteria associated with such a system while at the same time having, at least some, of the qualities associated with games. These qualities stem from the area of game design and there is a need for a deeper knowledge in game design and, above all, how to apply it in a context outside its original purpose. Even though this seems fairly straightforward, it is likely to be more complex than anticipated.

Research method
The purpose of research is to produce useful knowledge. DSR also has a component construction [10]. The artefact should be evaluated by means of a well-executed evaluation method [31]. In most cases the evaluation in a relevant context is to be preferred. Especially to determine the practical relevance of the artefact. Furthermore, as DSR is about designing solutions to problems in context, additional complicating factors are introduced. That is, the nature of the solution and the domain to which it is applied. The following seven guidelines for design science in IS has been proposed [31]: (i) Design as an artefact: a viable IT artefact in the form of a construct, a model, a method, or an implementation should be produced. An artefact instantiation is a way to demonstrate the design process and the designed product. In this paper we revisit our serious games project portfolio (20 projects between 2004 and 2017) and select six projects and analyse them through the lens of the IS BoK [11]. All our projects contain some design and development and can from that perspective be characterized as DSR. Due to practical limitations we settled for six projects that are representative over time, scope, organisational involvement and diversified publication and dissemination of results.

Procedure
We apply six steps to identify lessons learned from our previous research from which we conceptualize serious games development and derive a set of design guidelines.
(i) Identification of the total set of development projects in our project portfolio. (ii) Selection of representative projects for detailed analysis based on the following two criteria: a. Either of the authors of this paper should have been personally involved. b. The project should satisfy the guidelines in [31].
A written summary of each project was condensed by analysing the outcomes, i.e. artefacts and publications. The summaries were organized according to the guidelines in [31]. (iv) Each project summary was amended with notes on the five ontological domains from the IS expert BoK [11]. In addition, central themes from the project descriptions that did not fit the five ontological domains were categorized as other.
Each ontological domain was analysed across all projects to determine to what extent it could be observed. The other category was thematically analysed to reveal recurring patterns.
Finally, a design theory for serious games development was proposed.

Contexts and case descriptions
In order to give an overview we present the artefacts, their relevance to the respective domains and the main research contributions.
The Sp&Ts project (2004 -2006) explored the relation between digital games, traffic safety and traffic behaviour [4,32]. Two major aims were to understand the relation between game mechanics and their effect on player behaviour and the mapping between game mechanics and real world driving variables. The project developed a midrange driving simulator (Figure 3), with a real car as the control unit, using off-the-shelf hardware and game development software [33]. The partners in the project were a group of driving educators who were looking to explore the potential of digitalization, simulation and game-based learning to their domain.
The goal of the SIDH (2006 -2007) project was to develop and evaluate a training game for fire fighter training. The project was specified and developed in close cooperation with the Swedish Rescue Services Agency. One main challenge was to balance game content and game design with training goals so that the game challenges would motivate voluntary training as a compliment to regular training [34]. Hence, one important goal of the game is to support extracurricular training which poses high demands on the capacity of the game to function as a stand-alone solution, i.e. a play session has to be selfcontained even though the game itself is an integrated part of the overall training program. This was solved by introducing a virtual coach in the game. The project developed a cave ( Figure 4) and a modification of the Half Life 2 game to suit the purpose (creating relevant training scenarios based on pedagogical goals) as well as porting it to the cave with 4 walls visualization [35].  The Elinor project (2007 -2009), explored game-based stroke rehabilitation in a home environment [36][37][38][39]. The goal of the Elinor project was to provide home-based and self-administrated training. This means that all instructions and interactions have to be very clear and all interactions have to be intuitive and easy to learn, especially with respect to the target group of non-gamers. The project was conducted in collaboration with the stroke unit at a regional Hospital in Sweden. The development process included a complete hardware platform (the Elinor console, Figure 5), 20 motion-controlled mini-games, as well as monitoring and analytics functions. The focus on stroke rehabilitation is motivated by the fact that rehabilitation pays off for a long time after the patient has been released from hospital. However, motivation drops quickly and the challenge addressed by the project was hence to extend the time during which patients were active in rehabilitation. The motivation goal was met by designing games that required movements that were desirable from a rehabilitation perspective. The utility dimension was supported by logging functionality that supported healthcare professionals in their work tasks to make the game an integrated part of the rehabilitation process. The Testament project (2008 -2010) targeted gamebased learning for confirmation classes [40]. The project was conducted in collaboration with the Church of Sweden. The project included the development of an action roleplaying PC game ( Figure 6) using the Old Testament as its context. Although the Church of Sweden has high membership numbers, the participation in confirmation classes has dropped in practice constantly the last 50 years (from 81,000 in 1970 to 27,000 in 2017). The Church of Sweden puts efforts in finding new ways to make the confirmation classes relevant for new generations. The game included stories from the Old Testament and was set in an environment that reflected the time of those stories. However, the intention of the game is to provide inspiration for discussion, i.e. a way to reach the target group. The game was accompanied with a teacher's manual.

Figure 6. Screenshot from Testament
The SAREK project (2012 -2017) developed a simulator training environment (Figure 7) to improve live-role play training in a prehospital context by means of using sound and visualizations as well as challenging scenarios which incorporate contextual factors to have an effect on the work tasks [41][42][43][44]. The project was initiated by the initiative of the ambulance unit at a regional hospital. Medical simulation is an important field in medical training. However, its main focus is typically on the medical aspects whereas prehospital care taking is complex also in its varying contexts and environmental factors. The SAREK project is an improvement of the way that simulation based prehospital training is traditionally carried out in that it provides a flexible way to place medical scenarios in different contexts as opposed to only focusing on the medical treatment. From a prehospital perspective this is important since the context (scene of incident) has an impact on treatment options and this is not captured in traditional simulation training. The KidCog project (2014 -2015) developed a game called Hidden in the Park (Figure 8) to be used as a basis for discussion about grooming with the intention of raising children's risk-awareness related to online interactions [45][46][47]. The project developed a novel combination of a classic board game and Augmented Reality (AR) that works as a way to catch and keep attention. The AR functionality was used as an integral part of the gameplay while at the same time serving as some sort of "wow factor". The project was conducted in collaboration with an organisation working against child abuse. Sexual grooming is a sensitive topic which is typically addressed via information and discussion. One unique feature with the game is that is does not ever mention the topic of grooming. The gameplay is based on grooming processes as they appear in real chat logs [45]. However, the processes that occur in the game are placed in another environment and the transfer of topical knowledge is achieved via discussion. This means that the usage context, i.e. the teaching situation in which the game is used is an integral part of the game. This is achieved by adding a teacher manual on how to discuss the topic and how to connect that discussion to the game.

Case analysis
As already stated, serious games are utility systems with additional features. In this section we use the ISD BoK [11] as a framework to analyse our projects. The goal is to evaluate its applicability and to identify additional factors that come into play in serious games development. Table 1 shows a summary of the representation of the BoK dimensions in the studied cases. In addition to the original five dimensions the table also shows a proposed dimension of game design knowledge. The detailed discussion is presented in sections 4.1, 4.2 and 5.

Serious games development from an IS BoK perspective
IS development process knowledge is an IS expert core expertise. This has also been at the core in most of our projects. We have observed success factors as well as failures that are commonly reported in IS literature. We have mainly utilised a prototype driven and iterative development approach; and in several projects with a major component of hardware development. One specific observation concerning the prototype driven approach is the added complexity of the mutual learning process associated with the co-design of a serious game. As developers, we have had to gain understanding of the application domain (i.e. building our application domain knowledge as a part of the development process) as well as informing domain experts of the potential solution sphere.
In the case of serious games development, the latter does not only include the possibilities and limitations of the actual system but also to convey an understanding of games and game design on a more general level. Cases where the client interest in the gaming aspect of a serious games project is low may be dealt with as any other conflict of interest and requirements. However, the specific knowledge of game design and its application in the domain will need to reside with the developer, as clients could normally not be expected to have that kind of competence. As a general observation we see that the rapid prototype driven approach both aided in our understanding of requirements and in the clients' understanding of the solution as well as the benefits of the game based approach, i.e. their understanding of game design. The uniqueness of serious games development process knowledge hence lies in that it combines (traditional) IS development process knowledge with game design knowledge. We observe that this knowledge can reside EAI Endorsed Transactions on Serious Games 07 2019 -08 2022 | Volume 6 | Issue 1 | e4 with different team members but the team must have the ability to combine them into the unique development process of serious games, thus adding complexity to the development process knowledge domain. We observe that the game designer must reach at least some level of understanding for the "serious utility" aspects of the project. In the same way, the team members specializing in other areas must have some understanding of the implications that the game design aspect has on the project. One central aspect being that games are about creating gameplay experiences. From our projects we observe that the orchestration of the development process knowledge has been a crucial task of the project management. As an example from the KidCog and Elinor projects, the project manager had a central task in balancing the utility and game design aspects residing in different parts of the teams.
Viewing the IS application knowledge, another core IS expertise, there is a clear tendency in our projects that this dimension has not been strongly represented, apart from the Elinor and SAREK projects. This dimension address typical IT applications in an application domain [11]. The information processing in the cases has mainly been related to the instructors' role to moderate and monitor play sessions. As an example, the administration mode of Elinor (analysis of patient behaviours) is a utility function that supports rehabilitation professionals in their work tasks. Another example is the control system developed in the SAREK project to manage and supervise training scenarios. These examples share characteristics with other IT applications in the domain of medical training and rehabilitation.
The importance of application domain knowledge has been apparent in all our projects. In several cases it has been a significant component where developers have conducted field studies of professional activities (e.g. ambulance missions in the SAREK project) and even participated in training programs (e.g. fire fighter training missions in the SIDH project). The development process has also included a large fraction of user tests in the target domain. This was, for example, the case in the Elinor project where the games and console, at the early stages, were evaluated by both rehabilitation experts and nursing students in order to gain a better understanding of the health care domain. Subsequent early stage evaluations were done with relatively healthy stroke patients to gain better understanding of the target group. These activities all contributed to application domain knowledge in the developer team.
The technology knowledge domain has been a central aspect and object of study in most of our projects. In fact, it has been a main object of study in some projects, notably the Sp&Ts project had a strong component in technology development as it aimed to demonstrate the possibility of providing advanced driving simulation capacity with the help of consumer hard-and software. In the Elinor project the actual solution was in the form of a novel gaming console (hardware) with specifically developed games as content, which makes it an integrated solution. These examples also illustrate the combination of custom made hardware and software solutions that have been at the core of several projects. Throughout our research activities, we have become more and more aware of the peculiarities of the game development pipeline and the tools commonly used there. This has led us to understand that the technology domain includes new types of tools for (serious) game development.
In several projects (e.g. SAREK, SIDH and Elinor) we developed advanced logging functions and analysis tools that assist in understanding both performance and behavioural aspects. We have also applied technology domain knowledge to provide a "wow factor" to some projects, e.g. the AR part of the Hidden in the Park game. It is important to note that the "wow factor" is a double edged sword. Technology for the sake of technology can be problematic, which has been observed in the IS community for a long time. However, in serious games development it can be used to catch attention and novel applications that are, as in the example of Hidden in the Park, well connected to the gameplay may serve its purpose. Obviously, the quality and utility of the overall product should not be sacrificed. Finally, the technology driven "wow factor" should not be over-emphasized as it is expected to pass quickly in a fast moving area as IT.
Organisational knowledge of the areas of use has had various levels of importance in our different projects. The health care sector (Elinor and SAREK) poses specific requirements, especially ethical considerations that come with any engagement. Overall, the alignment with the organisational processes that a serious games has to support can be challenging as the additional dimension of gameplay is not typically associated with the utility dimension of a work process. Generally, when working in the health care sector ethical considerations become an issue. Health care professionals are used to these requirements but for a serious games developer they may be novel. Also, the strong demand for evidence based interventions make health care a challenging sector to enter.
Overall, we conclude that the IS BoK is applicable to serious games development and many of the challenges identified clearly sort under the different ontological domains. However, there is a missing link: How to deal with gameplay experience. Creating interesting gameplay for players is at the core of game design but is not a part of the original IS BoK and has fundamental differences to the typical IS application knowledge.

The missing ontological domaingame design
A serious game is a product that mixes utility and gameplay to achieve some additional goals or values. In this sense, the IS development process knowledge does not seem to capture the potential conflict between gameplay experience and utility. We claim that this is actually a conflict that is not well captured using the traditional tenet of conflicting requirements in IS development as the creation of EAI Endorsed Transactions on Serious Games 07 2019 -08 2022 | Volume 6 | Issue 1 | e4 designing gameplay is more comparable to an artistic or aesthetic dimension. The IS application knowledge domain is applicable in serious games development with respect to the utility aspects. These typically relate to collection, processing and representation of information in an organisational context. This dimension and perspective is definitively needed for certain elements in a serious game usage context. The understanding of games and gameplay experience is however also needed but is not well captured in terms of information processing. Games are characterized by that they are unproductive and that the main goal is player engagement and enjoyment. The competence required to develop a game cannot be reduced to IS application knowledge. Hence, there is a need to extend the original IS BoK dimensions as well as introducing the game design knowledge domain. The implications of the gameplay experience dimension have been highlighted in several previous studies of "regular" game development [30,48,49]. The hedonic usage context as well as the dual-purposed context for information systems was identified in one survey [50]. However, it refers to the hedonic use of an information system whereas we shift perspective and propose that development of serious games is rather about using game design to create additional value to a utility system. Hence, the application of game design knowledge is more deliberate.
Notably, the game design aspect is not taken into account in propositions for why IS researchers are the most suited to develop and research serious games [6,51]. The findings from our projects rather highlight the fact that the game design dimension is important and fundamentally different and needs to be handled differently than utility aspects. In fact we argue that the game design dimension needs to be thoroughly incorporated into an extended body of knowledge for serious games development. This is applicable to obvious things such as balancing mechanics and scoring systems as well as to more fine-tuned challenges such as redesigning tasks to make them more engaging to provide appealing gameplay experiences.
We observe that some projects have had a high acceptance for, and willingness to explore the game design component among the clients or have had a very clear vision of creating a gameplay experience as an integral part of the project. Since the gameplay component has been an important starting point for us in all of our projects we early on became aware of the need to "measure" and understand the subjective experience of using our systems. That is, to explore it beyond traditional user acceptance models, such as the Technology Acceptance Model [52]. Enjoyment is pointed out as an important antecedent to IS success [53]. The user experience is important in most applications, and it can be argued that games are not different with regards to this. This is however contradicted by studies of game production, for example: "Because of this fundamental difference between games and productivity software, many researchers have tried to formulate a specific definition for usability in computer and video game context, but there are not yet any commonly agreed on definition for it" [54, p. 2-3]. Studies carried out in North American and Northern European game studios reveal that some elements of traditional usability is applicable in the game industry but also that there are additional elements e.g. related to the controls, game design, and storyline that make games different [54,55]. In some cases, companies make a distinction between usability issues and gameplay issues. Irrespective of the terms used, it is apparent that games contain elements different from those found in utility software.
The evaluation of gameplay experience has been central in all of our studied cases. In the early projects (Sp&Ts, SIDH and Elinor) we explored time as a potential measure of engagement, i.e. longer playtime in uninstructed situations of play should indicate interest. As an example, we could show that playtime is useful as one measurement of satisfaction [4,38]. Since we introduce game design to the IS domain we also introduce the more multifaceted concept of immersion, which is a common way of addressing engagement and enjoyment among game scholars, as a feasible instrument. We also explored several means to study immersion e.g. [56], which is a concept commonly used to study the involvement and engagement of players in the game development community by means of questionnaires. However, we observed some problems with such questionnaires, primarily the fact that the act of answering them becomes an immersion breaker. This led us to explore less intrusive means of studying immersion. As a result, in the SAREK project, we developed the Immersion Score Rating Instrument [43] which could be used to analyse the immersion of participants in live role playing scenarios [42]. Moreover, the identified importance of understanding immersion and how it manifests itself in players led to a PhD project in which a tool for automated analysis of player emotions was developed [57,58].
This need to take the gameplay experience of the player into account is not well captured in the IS BoK and hence forms an important extension for methods targeting serious games development. In fact, immersion is at the core of engagement with games [56]. Even though fuzzy and hard to define and even harder to measure, it has shown to be a useful concept to understand the complexity of effect and effectiveness in serious games [44].

Design principles for serious games
As can be seen from our analysis, the original IS BoK is applicable to serious games. There is plenty of evidence reported in the ISD community that IS development is a hard enough challenge and success is not at all given [59] (e.g. Yeo, 2002). Moreover, game development is not trivial either and success is uncertain and determined by unforeseen factors [30,49]. There are at least two additional complicating factors in game development ( Figure 2) compared to traditional IS development ( Figure  1): the scale of the multidisciplinarity in the development team and the fact that the user is a player. The set-up of the team adds complexity to the development process, as it has EAI Endorsed Transactions on Serious Games 07 2019 -08 2022 | Volume 6 | Issue 1 | e4 to orchestrate a variety of professional and artistic traditions. The fact that the player expects a gameplay experience entails new expectations from the user/player. There is a difference in producing a result and having a gameplay experience. In fact, this inherent conflict is addressed already by [7] who states that playing a game is a voluntary activity with no worldly outcome. Therefore, we argue for the addition of a sixth ontological domain to the IS BoK. The core of that domain should be game design. Hence, we end up with a new situation which introduces additional complexity to the development process (Figure 9).

Figure 9. A typical serious games development situation
The requirements on team organisation differs from traditional IS development as it needs to cater for all of the artistic and aesthetic dimensions of game development while at the same time solving the organisational problem. The majority of the people involved in the development of a serious game may not consider themselves to be IS developers and may not orient towards the IS BoK. Moreover, the user is not only a user but rather a user/player with potentially conflicting goals. From the utility perspective, the game cannot be unpractical with respect to how it contributes to the work situation. There is also a risk that game features interfere with the serious goal. This has been observed and termed gamer mode to describe a situation where a player of a learning game tend to focus on beating the game rather than reaching the learning goal [60]. This is not a matter of game design only, but rather its application for a different purpose, which may even be in conflict with the original purpose of games, that is to create an entertaining and engaging gameplay for the only purpose of being just that. This additional challenge constitutes a further motivation for this distinct ontological domain.
Our findings are condensed in seven design principles for serious games presented in Table 2.

# Design principle
Relating to 1 Game design expertise is crucial and needs to be an integrated part of the process of developing serious games.
ISD process knowledge 2 Games are not typical IS applications and cannot be understood as such. There is a conflict between the fundamental tenets of games and organisational IS applications that needs to be considered.

IS application knowledge
3 The gameplay experience and the utility of a serious game are determined by the organisational usage situation. This entails that the design space for serious games ( Figure 10) is different from both games and utility software.
IS application knowledge 4 The "wow-factor" of serious games may drive technology use for the sake of technology. This is not optimal from a utility perspective and needs to be considered during development. Thus we propose that the design space for serious games is different in that it is about balancing utility with gameplay experience (Figure 10). Our first and naïve interpretation of how to navigate this design space was that there is an optimal balance between the two (the dotted line in Figure 10).

Figure 10. The proposed design space for serious games
What we found is that client requirements are typically about utility, which can be interpreted as not a game. The gameplay experience dimension is, as previously stated, harder to capture but still, we believe, at the core of a serious game. One solution to this dilemma is to use the usage context to compensate for aspects that are hard to capture in the game. This would mean to focus on gameplay experience in the solution and relying more on the context in combination with the gameplay experience to address utility.

Conclusion
Drawing from the six cases presented in this article, we contend that serious games share vital features with IS applications and in some sense they could be argued to be a specific type of IS application when viewed from the utility perspective. We note that the game design dimension is one distinguishing factor that is not commonly discussed in IS research addressing gamified systems [6,51]. Our analysis reveals new interpretations of the ontological domains of the IS body of knowledge [11] as well as an additional ontological domain, the game design domain. We contend that the five original ontological domains are relevant but that the game design dimension introduces a fundamental difference in serious games development. By explicating the game design component in serious games and relating it to the utility dimension we add to the understanding of the serious games from a game perspective, which is relevant to any development effort intending to use the persuasive and motivational power of games outside the entertainment sector, such as, for example, in information systems [6,51].