Game development software engineering process life cycle: a systematic review

Software game is a kind of application that is used not only for entertainment, but also for serious purposes that can be applicable to different domains such as education, business, and health care. Multidisciplinary nature of the game development processes that combine sound, art, control systems, artificial intelligence (AI), and human factors, makes the software game development practice different from traditional software development. However, the underline software engineering techniques help game development to achieve maintainability, flexibility, lower effort and cost, and better design. The purpose of this study is to assesses the state of the art research on the game development software engineering process and highlight areas that need further consideration by researchers. In the study, we used a systematic literature review methodology based on well-known digital libraries. The largest number of studies have been reported in the production phase of the game development software engineering process life cycle, followed by the pre-production phase. By contrast, the post-production phase has received much less research activity than the pre-production and production phases. The results of this study suggest that the game development software engineering process has many aspects that need further attention from researchers; that especially includes the postproduction phase.


Research Background
In the software development industry, software games are gaining importance because they are not only used for entertainment, but also for serious purposes that can be applicable to different domains such as education, business, and health care. Along with their applicability to different domains, their revenue has also been increasing. Games software earned three times more revenue than any other software product in 2012 (Nayak, 2013). Robin (2009) defines a development method as a systematized procedure to achieve the goal of producing a working product within budget and on schedule.
A number of methodologies used for game development and design (Novak, 2008;Castillo & Novak, 2008). The first is the waterfall method, which is also commonly used in traditional software development. Unlike game projects, once the pre-production phase is completed, production phase activities are performed in a "waterfall" manner. First, the activities are segregated based on functionalities and assets, and then they are assigned to their respective teams. The requirements team spent a significant amount of time in functionality definition and front-end activities, which implies a late implementation of level and mechanisms (Schwaber & Beedle, 2002). However, in the waterfall method, it is difficult to reverse any activity (Flood, 2003).
The second development methodology is the agile method that is commonly used for game development. These methods are highly iterative and not documentationcentric. The production phase is divided into small iterations and focusses on the most crucial features. During the beginning phase of each iteration, the whole team meets and sets clear objectives. At the end of each iteration, results are communicated to clients. These methods support different team cycles and dynamics through daily meetings. The most used agile methodologies in game development are extreme programming (XP), rapid prototyping, and Scrum (Godoy & Barbosa, 2010).
The unified development process (Kruchten, 2000) is another traditional SE method, which focusses more on analyzing requirements and converting them into functional software components. The requirement analysis document includes a definition of the game concept, use cases, and assets definitions (Schwaber & Beedle, 2002). The method includes five disciplines: requirements, analysis, design, implementation, and testing. The unified process is based on a philosophy of four key elements: iterative and incremental, use case-driven, architecturecentric, and risk-driven. Kanode and Haddad (2009) stated that an important, but incorrect, assumption was made that GDSE follows the waterfall method. More recently, researchers have agreed that it must follow the incremental model (Munassar and Govardhan, 2011) because it combines the waterfall method with an iterative process.A major concern, reported by , was that very poor development methodologies are commonly used by developers for software creation in the game industry. The GDSE appears as a question in many forms attempting to determine what types of practices are used. However, there is no single answer to this question. Few researchers have explored GDSE practices and then tried to answer questions like the phases of the GDSE process life cycle. Blitz game studios (2014) proposed six phases for the GDSE process life cycle: Pitch (initial design and game concept), Pre-production (game design document), Main production (implementation of game concepts), Alpha (internal testers), Beta (third-party testers), and the Master phase (game launch). Hendrick (2014) proposed a five-phase GDSE process life cycle consisting of Prototype (initial design prototype), Pre-production (design document), Production (asset creation, source code, integration aspects), Beta (user feedback), and, finally, the Live phase (ready to play). McGrath (2014) divided the GDSE process life cycle into six phases: Design (initial design and game design document), Develop/redevelop (game engine development), Evaluate (if not passed, then redevelop), Test (internal testing), Review release (third-party testing), and Release (game launch).
Another GDSE process life cycle proposed by Chandler (2010) consisted of four phases: Pre-production (design document and project planning), Production (technical and artistic), Testing (bug fixing), and, finally, the Post-production phase (post-mortem activities). The latest GDSE process life cycle in 2013 proposed by Ramadan and Widyani (2013) was based on the four GDSE process life cycles previously described. They proposed six phases: Initiation (rough concept), Pre-production (creation of game design and prototype), Production (formal details, refinement, implementation), Testing (bug reports, refinement testing, change requests), Beta (third-party testers), and Release (public release).
In traditional software engineering, the development phase usually involves activities such as application design and its implementation; the production phase is when the software actually runs and is ready for use. However, in the GDSE process lifecycle, the production phase includes the development process, which is the pre-production phase of the traditional software engineering process, and the production phase of traditional software engineering is actually the postproduction phase of the GDSE process life cycle (Bethke, 2003). Therefore, the GDSE process life cycle is different from the traditional software engineering process, and many researchers have studied the challenges faced by this domain (Kanode and Haddad, 2009). The most prominent observation made in these studies is that to address the challenges faced by the GDSE process life cycle, more rigorous software engineering strategies must be used. Most researchers have explicitly compared the software engineering process with the GDSE process, but none of them has studied complete GDSE process life cycle and research topics under this domain in detail. This study will provide evidence on these topics and their differences from the traditional software engineering process. In this paper, the GDSE process phases were divided into three phases for basic understanding: Preproduction, Production, and Post-production. Efforts were made to classify these further based on studies found in the literature. The primary contribution of this paper is that it is the first SLR that addresses these GDSE process life cycle research topics and highlights the topics that need further attention by researchers.

Review Methodology
In this work, the conceptual description of the SLR process presented by Kitchenham (2004) was used to investigate the research intensity for each phase of the GDSE process life cycle. Conceptually, SLR provides an opportunity for researchers to collect empirical evidence from the existing literature about a formulated research question. Although most authors followed the general SLR guidelines provided by Kitchenham (2004), there were slight variations in the description and presentation of the conceptual process layout. The generic SLR guidelines stated by Kitchenham (2004) are further elaborated here, and the overall process is described as a set of activities The research process has been adopted for this study described by Kitchenham and Charters (2007). There are mainly three phases of the review and the steps associated with each phase are shown in fig. 1.

Planning Phase (Step 1 -4)
This study started by selecting a topic, at which point the study objectives were also clearly defined and the boundaries of the domain delineated.

Selection of Topic and Research Questions
Selecting a topic for SLR is of crucial importance because many factors such as individual or community interest, research gaps, and research impact contribute to shaping research questions on the topic. Our understanding of the GDSE process life cycle is continuously evolving (Kitchenham et al., 2010), and many areas in this field lack generalized evidence. It is critically important for the game industry to identify a quality-driven GDSE process. Several studies have investigated different phases of the GDSE process life cycle, but they do not offer systematic, comprehensive, and thorough methodological research specific to this topic.
In this review, studies from 2000 to 2015 will be explored to answer the following research questions: Research Question (RQ1): What is the intensity of research activity on the GDSE process life cycle? RQ2: What topics are being researched in the pre-production, production, and post-production phases?
RQ3: What research approaches are being used by researchers in the software game domain?
RQ4: What empirical research methods are being used in the software game domain?
The number of publications has been identified by the research group to address RQ1. A graphical representation has been used to represent the increase or decrease in the number of publications per year as a measure of research activity.
To address RQ2, RQ3, and RQ4, each study selected has been affiliated to a research topic, to a certain approach, and to a specific methodology used for the research. Details of this classification into corresponding categories are discussed in section 3.2.4.

Review Team & Protocol Establishment
A multidisciplinary team is needed to perform a high-quality scientific SLR. To enhance the thoroughness and minimize the potential bias of a study, an SLR is normally undertaken by more than one reviewer. The SLR team for this review was made up of three people. Two people were designated as principal reviewers (Second expert report by American institute 2011). One person was also selected as the project leader to handle additional administrative tasks such as team communication, points of contact, meeting arrangements and documentation, task assignment and follow-up, and quality assurance. Table 1 details the tasks required for the SLR process and reviewer's involvment. In order to ensure the review could be replicated and to reduce researcher bias a review protocol and it's evaluation procedure was developed at step 3 and 4. The final review protocol is discussed in the following sections 3.2.1 to 3.2.4 (Steps 5-9 incl.).

Search Strategy
In the SLR, the search procedure is based on an online search. In order to retrieve different sets of relevant literature, four groups are designed.
The main objective of this grouping is to find the literature that is the intersection of the groups as shown in Fig. 2. Table 2 Search terms and corresponding groups The search strategy was implemented by applying the "AND" and "OR", where the "OR" operator is used within the Group and the "AND" is used between the groups. According to  Table 3, was not explicitly present in the potential study, then that paper was peer-reviewed by all team members and, after discussion, validated for correctness. Otherwise, each paper was reviewed by one reviewer.
Each study involved some general information and some specific information, as indicated on the form.

Pilot Selection & Data Extraction
The research study selection and data extraction was based on the following coverage criteria: Inclusion Criteria for Study: For SLR, articles and research papers from 2000 to 2015 were included, and to evaluate their suitability, the following criteria were analyzed:  The study should be thoroughly reviewed by at least one of the reviewers.
 Only the following types of studies were considered: case studies, theoretical papers, and empirical analysis surveys.
 The full text of the article should be available.
 If any article identifies any challenges and problems in software games, that article is included as a review.
 Studies that describe motivation for game application.

Study Exclusion Criteria:
The following criteria were used to determine articles to be excluded:  Articles published on company Web sites.
 Articles not relevant to the research questions.
 Articles not describing any phase of the game development life cycle.
Study Selection: This procedure involved two phases. In the first phase, an initial selection was made on the basis of the inclusion criteria and after reading the title, abstract, and conclusion of each article. In the second phase, if a particular article met the criteria, then the whole article was studied. One hundred twenty seven papers were identified after final selection, as shown in Fig. 3. Table   4 shows the results found in each data source and Appendix A contains a full list of selected publications.

Quality Criteria
In this research, quality guidelines were defined based on a quality instrument that was used to assign a quality score to each article as a basis for data analysis and synthesis. The quality instrument consisted of four sections: a main section containing a generic checklist applicable to all studies, and three other sections specific to the type of study.
The checklist was based upon SLR guidelines (Kitchenham, 2004) and was derived from Kitchenham (2004) and Second expert report by American institute (2011). The detailed checklist is shown in Table 5. Some of the checklist items could be answered by "yes" or "no" and they also included a "partial" option. A value of 1 was assigned to "yes," 0 to "no," and 0.5 to "partial"; then the sum of the checklist values was used to assign a quality score to the study to assess document quality.

Data Synthesis
For data synthesis the topics, research approaches and methods are classified and their classification details are listed below: Classification of topics in the GDSE Life Cycle: This section includes a classification of the topics covered by each study with respect to the preproduction, production, and post-production phase issues involved. The 2012 ACM classification system was used for classification, which is the same method used by Kai and Card (2008). The proposed classification system has been adopted by many journals and conferences specifically for software engineering topics. The same classification was used here to classify the papers under study, and these were further fabricated based on studies found in the GDLC domain. Table 6 presents the selected classification schema.  (2002). The main categories for scientific approach are descriptive (a system, tool, or method; a literature review can also be considered as descriptive studies), exploratory (performed where a problem was not clearly defined), and empirical (findings based on observation of its subjects). To evaluate new methods or techniques, three major empirical research methods are used: surveys, case studies, and experiments (Wohlin et al., 2000). Table 7   To address RQ2, the major topics of the GDLC that were investigated in the software game domain.
 To address RQ3 and RQ4, the research approach or method used by number of studies.
From Section 3.2.4, data were tabulated and are presented in Appendix B.

Documenting (Step 10-12)
This step of the SLR describe conclusion, possible threats and limitations to the validity of this study. Authors believe that there is a chance that the word game was not part of the title of some studies, but that nevertheless they discussed game development. These studies may, therefore, have been excluded from the primary Table 7 Empirical methods

Survey
One or more questionnaires are filled out by a set of subjects either directly or by Internet, and results are derived from the answers.

Experiment
A specified task is performed in a highly controlled environment by a set of subjects. The results are the observations made by the subjects; in addition, task outcome inspection gives answers to research questions.

Case study
According to a methodology, an activity, project, or assignment is examined, and project measurements provide results. dataset by the search procedure. There are other threats that are also linked to a systematic literature review such as generalization and subjective evaluation (Shadish et al., 2002).
There are limitations to our results, although significant amounts of effort and time was spent to select the papers that were studied. More specifically, our search was limited to the academic databases. It is obvious from the results of RQ1 that developers prefer to submit their work on the blogs or forums. However, posts for different game forums and blogs cannot be included in a systematic literature review because they don't fulfil the quality criteria used for the selection of papers. In addition, the exclusion of less-known journals and conferences from the Web of Science and the Scopus index might have led to a different dataset.
Finally, the classification scheme might have altered the results if they were classified by a scheme, such as the waterfall model, instead of the ACM classification scheme. Despite these limitations, the results of our systematic literature review will be useful to game development organizations and developers of software games.

Analysis of Results and Discussion
This section presents the results of statistical analysis of the data set discusses the findings concerning the RQs formulated in Section 3.1. The characteristics of the data set are tabulated for better understanding. To trace the categories of each mapped study, the interested reader is referred to the Appendix B. A total 148 studies were collated and analyzed as part of this review. To identify GDSE process life cycle domain specific characteristics, the findings of this review will be compared to results from similar studies done by Cai and Card (2008), Glass et al. (2002), and Dyba and Dingsoyr (2008).

RQ1 What is the intensity of research activity on the GDSE process life
cycle?   4.2 RQ 2: What topics are being researched in the pre-production.
production and post production phase?
This section addresses the identification of main research topics in the GDSE process life cycle domain. Table 9 clearly suggests that most research has been conducted in the production phase, followed by the pre-production phase. On the other hand, the post-production phase has not attracted much research interest.
These GDSE process life cycle topics are somewhat different than in software engineering because of two factors: first, the GDSE domain has special needs and priorities, and second, it is a young domain which requires more fundamental research in the area of requirements, development, and coding tools. When the GDSE domain becomes mature, then other areas in the field, like testing and verification, will attract the interest of researchers. As mentioned earlier in Section 2, games have specific characteristics, which the conventional software development process cannot completely address. In the past years, research on GDSE process life cycle topics has become more active because, unlike other software products, games provide entertainment and user enjoyment, and developers need to give more importance to these aspects. As a result, research about the pre-production phase has increased. The implementation phase is shorter than in the traditional software implementation process because of the short time to market. This production-phase research intensity has attracted the interest of many researchers, and maximum research activity has been reported because the GDSE domain requires efficient development and coding techniques.
McShaffrey (2003) also highlighted the importance of the production phase to counteract poor internal quality. There is much less research activity in the postproduction phase than in the pre-production and production phases.

Management
In the pre-production phase, most of the studies categorized under this topic address management issues during the GDSE process life cycle. The overall management of the game development process combines both an engineering process and creation of artistic assets. Ramadan and Widyani [S1] compared various game development strategies from a management perspective, and most studies like [S3], [S6], [S7], and [S8] have proposed frameworks for game development. Game development guidelines can be followed to manage GDSE process life cycle. The presence of agile practices in the game development processes is also highlighted by some studies. Tschang [S4] and Petrillo et al.
[S17] highlighted the issues in the game development process and their differences from traditional software development practices. Management of development-team members and their interaction is critically important in this aspect.
Some studies [S10] and [S11] have provided data analytics and empirical analysis of the game development process and issues of interdisciplinary team involvement. Best management practices in the game development process must consider certain elements such as staying on budget, timing, and producing the desired output. To assess game quality, five usability and quality criteria (functional, internally complete, balanced, fun, and accessible) can be used, but a process maturity model specific to the game development process is still needed to measure these processes for better management and high performance.

Requirements Specification
One of the main differences between the traditional software development process and GDSE process life cycle is the requirements phase. The game development process requires consideration of many factors such as emotion, game play, aesthetics, and immersive factors. In four studies, the authors have discussed the requirements engineering perspective to highlight its importance for the whole game-software development process. They discussed emotional factors, language ontology, elicitation, feedback, and emergence [S19], [S20], [S21], and [S22]. In particular, game developers must understand these basic non-functional requirements along with the game play requirements and incorporate them while must address both the functional and non-functional requirements of game development.

Game System Description Language
Many description languages are currently used by developers, such as the UML model, agent-based methodologies, and soft-system methodologies. Quanyin et al. and Rodriguez et al. [31] proposed an ontology knowledge framework for digital game development and serious games modelling using the AOSE methodology. A system description language for games must be both intelligible to human beings and formal enough to support comparison and analysis of players and system behaviors. In addition, it must be production-independent, adequately describe the overall game process, and provide clear guidelines for developers.

Reusability
The existence of reusability of software (Capretz et al., 1992) and development platforms in game development has been reported by some researchers, but to gain its full advantages, commonality and variability analysis must be done in the

Game Design Document
The Game Design Document (GDD) is an important deliverable in the preproduction phase. It consists of a coherent description of the basic components, their interrelationships, directions, and a shared vocabulary for efficient development. Westera et al. [S37] addressed the issue of design complexity in serious games by proposing a design framework. Furthermore, Salazar et al. [S38] highlighted the importance of a game design document for game development and

Game Prototyping
Game prototyping in the pre-production phase helps the developer to clarify the fundamental mechanics of the final game. Game prototyping in the preproduction phases is considered important because it is used to convey game and play mechanics and also helps in evaluating a game player's experience. Reyno andJournal of Software Engineering Research andDevelopment, 4(6):1-30, DOI: 10.1186/s40411-016-0032-7, Springer, November 2016. Cubel [S49] proposed automatic prototyping for game development based on a model-driven approach. An automatic transformation generates the software prototype code in C++. De Silva et al. [S48] proposed community-driven game prototyping. The developer can approach the well-established community and focus on the technical stuff rather than starting from scratch. They used this approach for massive, multi-player online game development. Guo et al. [S50], Kanev and Sugiyam [S51], and Piesoto et al. [S52] proposed analysis of rapid prototyping for Pranndo's history-dependent games, 3D interactive computer games, and game development frameworks respectively. Prototypes also help to identify missing functionality, after which developers can easily incorporate quick design changes. Model-driven or rapid-prototyping approaches can be used to develop game prototypes.

Design Tools
Game design tools are used to help game developers create descriptions of effects and game events in detail without high-level programming skills. Cho and Lee [S56] and Segundo et al. [S57] proposed an event design tool for rapid game development and claimed that it does not require any kind of programming skill.
These tools also enable reuse of existing components and reduce the total time of the game-creation process.

Risk Management
In the game development domain, risk management factors do not receive much discussion by researchers. Risk management is very important from a project management point of view. Identifying risk factors in the game development process is also important. In game development, the project manager is the game producer and must bring together management, technical, and aesthetic aspects to create a successful game. The study by Schmalz et al. [S58] is the only study highlighting the issue of risk management in video development projects. They identified two risk factors during the development process: failure of development strategy and absence of the fun factor. In game development, important risk factors can be the development strategy, the fun factor or extent of originality, scheduling, budgeting, and others, but very low priority has been given by game developers to formal analysis of risk factors.

Asset Creation
Asset creation in the production phase is the foundation stage where game developers create the various assets and then use them in the game implementation phase. In the production phase, the first step is to create assets for the game. One of these assets is audio creation. Migneco et al. [S63] developed an audio-processing library for game development in Flash. It includes common audio-processing routines and sound-interaction Web games. Minovic et al. [S65] proposed an approach based on the model drive method for user interface development, and Pour et al. [S64] presented a brain computer interface technology that can control a game on a mobile device using EEG Mu rhythms.
For audio processing, open-source libraries are available, especially for games.
Audio and interface design are examples of game assets.

Storyboard Production
Storyboard production is the most important phase of game production; it involves development of game scenarios for level solutions and incorporation of artificial intelligence planning techniques for representing the various features of games through a traditional white board or flow chart. Pizzi et al. [S59] proposed a rational approach that elaborated game-level scenario solutions using knowledge representation and also incorporated AI techniques to explore alternative solutions by direct interaction with generated storyboards. Finally, Anderson [S61] presented a classification of scripting systems for serious and entertainment games, and Cai and Chen [S62] explored scene editor software for game scenes.
Their approach was based on the OGRE .Net framework and C++ technology.
Various scripting editors based on different technologies are available for game developers to produce storyboards. Some of this software helps to develop and edit scenes at different game levels, and other software helps by generating game levels automatically based on a description.

Development Platforms
The studies classified under this category proposed various types of platforms  [S77] highlighted the important aspects of multi-user application platforms used for rapid game development. Some researchers have proposed a development platform similar to that described above that provides connectivity along with client customization and unnecessary updating of game servers.

Formal Language Description
Game semantics can be classified under formal language description for programming languages; only two studies were reported under this classification.
The formal language description of game semantics provided a way to gain insight into the design of programming languages for game development. Mellies [S99] proposed a denotational prepositional linear logic for asynchronous games, and Calderon and McCusker [S100] presented their analysis of game semantics using coherence spaces. Very little work has been reported in this area, and very few game semantic descriptions of languages have been published.

Programming
Code complexity is increasing, especially in game development, because of the incorporation of complex modules, AI techniques, and a variety of behaviors. The most common programming languages used in game development are objectoriented structured languages such as Java, C, and C++. Studies classified under this category explored the programming aspect of game development. El Rhalibi et al. [S82] proposed a development environment based on Java Web Start and JXTA P2P technologies called Homura and NetHomura. It extends the JME game engine by facilitating content libraries, providing a new interface, and also providing a software suite that supports advanced graphical functionalities within IDE. The other two studies, done by Meng et al. [S84] and Chen and Xu [S85], also explored programming languages such as C++, DirectX, and Web GL and also Web Socket technologies for game development. Three studies by Yang et al.
[S87], Yang and Zhang [S88], and Wang and Lu [S89] explored collision detection algorithms from a game logic aspect for software games, proposed A* search, and AI optimization-based algorithms.
Wang et al. [S83] proposed a framework for developing games based on J2ME technology. Zhang et al. [S92] also explored the effects of object-oriented technology on performance, executable file size, and optimization techniques for mobile games and suggested that object-oriented technology should be used with great care because the structured programming in game development is highly competitive. Bartish and Thevathayan [S86] and Fahy and Krewer [S90] analyzed the use of agents, finite state machines, and open-source libraries for the overwhelmingly complex process of multi-platform game development.
Optimization techniques can be used with object-oriented programming to avoid unnecessarily redundant classes and inheritance, and to handle performance bottlenecks. These languages can be used across different development environments such as Android, iOS, Windows, and Linux. Researchers have proposed various approaches and tools for efficient game development. The integration of various development artefacts into games can also be done by generative programming, which also helps to achieve efficient development.

Game Engine
A game engine is a kind of special software framework that is used in the production phase for creating and developing games. Game engines consist mainly of a combination of core functionalities such as sound, a physics engine or collision detection, AI, scripting, animation, networking, memory management, and scene graphs. Hudlicka [S108] identified a set of requirements for a game engine, including identification of the player's emotions and the social interactions among game characters. This is the only study that has highlighted the important functionalities that an affective game engine must support. Another study by Wu et al. [S109] focused on game script engine development based on J2ME. It divided script engines into two types. The first type is the high-level script engine that includes packaging and refining of the script engine. The second type, the low-level script engine includes feature packages associated only with API. Four studies [S102], [S105], [S106], and [S107]

Implementation
The foundations of game theory are used in game development because it is a branch of decision theory that describes interdependent decisions. Most studies in this category described different aspects of game implementation technologies on various types of platforms. They considered improving programming skills, 2D/3D animations and graphics, sound engineering, project management, logic design, story-writing interface design, and AI techniques. Various kinds of game implementation technologies can be found in the literature. Vanhatupa [S117] presented a survey of implementation technologies especially for browser games.
The technologies explored in these studies are mainly server applications (application runtime, server-side scripting, and user interface and communication), client applications, databases, and architecture. The same study also described the accessories that can be used for implementation: application platforms, game engines, and various types of plug-ins. Abd El-Sattar [S112] proposed an interactive computer-based game framework for the implementation process. The framework includes steps from design through implementation that are based on game theory foundations and focus mainly on game models, Nash Journal of Software Engineering Research andDevelopment, 4(6):1-30, DOI: 10.1186/s40411-016-0032-7, Springer, November 2016. equilibrium, and strategies of play. The proposed framework includes architectural design and specifications, a proposed game overview, a game startup interface and difficulty scaling, game modelling, the game environment and player control, and a free-style combat system.
Four studies [S113], [S114], [S119] and [S120] focused mainly on a development framework for mobile devices. Su et al. [S96] proposed a framework describing implementation of various main modules such as pressure movement, a thread pool based on the I/O completion port, and a message module. They also claimed that their proposed framework addressed the problems of traditional frameworks such as the single-server exhaustion problem, synchronization, and thread-pooling issues. Jhingut et al. [S114] discussed 3D mobile game implementation technologies from both single-player and multi-player perspectives. They also evaluated two game APIs: MDP 2.0 and M3G API.
Finally, Kao et al. [S120] proposed a client framework for mobile devices that used a message-based communication protocol and reserved platform-specific data as much as possible. A few researchers have proposed agent-based frameworks as explored above for effective communication and synchronization between system components.

Quality Assurance
Process validation plays an important role in assessing game quality. Collection and evaluation of process data from the pre-production phase through to the postproduction phase either provide evidence that the overall development process produces a good-quality game as a final product or reveal that it cannot. Only two studies were reported under this classification. Stacey et al. [S122] used a storytelling strategy to assess the game development process. They carried out a two- year case study on a four-person development team. Astrachan et al. [S126] tried to validate the game creation process by analyzing the development process and design decisions made during development. The scope of studies done under this category was limited. The case studies were done for small teams and were limited to only one phase. In the game development process, quality assurance and process validation are critical components, and standard methodologies are lacking. More exploration is needed to provide deeper insights. QA for games needs more research attention because very little work has been reported.

Beta Testing
Beta testing in games is used to evaluate overall game functionality using external testers. Beta testing is a kind of first public release for testing purposes by users. Game publishers often find it effective because bugs are identified by users that were missed by developers. If any desired functionality is missing, it must be addressed at this stage. This testing is performed before final game release. Under this classification, only four studies [S127], [S128], [S129], and [S130]

Heuristic-Based Testing
Heuristics are a kind of design guideline and can be used as an evaluation tool by game design developers or users. Basically, heuristics can be used in software engineering to test the interface. In games, evaluation must extend beyond the interface because other playability experiences also need evaluation such as the game story, play, and mechanics. Six studies [S132], [S133], [S134], [S146], [S147], and [S148] fell under this classification. Al-Azawi et al. [S132] proposed a heuristic testing-based framework for game development. The proposed framework divides testing by two types of user: experts and real-world users.
Experts evaluate playability, game usability, and game quality factors. Users evaluate the game as a positive or negative experience. Omar and Jaafar [S133] and Al-Azawi et al. [S134] proposed a framework for the evaluation phase in the game development process. Heuristic testing can be done during the development process and repeated from the early design phase. It is perfect for game testing because after the game is implemented, if anything goes wrong, it will be too expensive to fix and will affect the project schedule. This topic also needs attention by researchers.

Empirical Testing
Empirical testing approaches for the game-testing phase have been explored by only a few researchers. The approaches described by these researchers have focused only on final-product quality and usability. Only two studies were reported under this classification [S135] and [S136]. Escudeiro and Escudeiro [S135] used a Quantitative Evaluation Framework (QEF) to evaluate serious mobile games and reported that QEF frameworks are very important in validating educational games and final-product quality. Choi [S136] analyzed the effectiveness of usability-expert evaluation and testing for game development.
Experimental results showed the importance of the validation process in game development. The scope of the studies done under this category was very limited, and other aspects of final-product testing have not been explored by researchers.

Testing Tools
Development of testing tools has not been addressed by many researchers. Only one study [S137] was reported under this classification. Cho et al. [S137] proposed testing tools for black-box and scenario-based testing. They used their tool on several online games to verify its effectiveness. Tools for game testing facilitate the testing process. The proposed scope of study was also limited, and available testing tools have focused only on evaluation of online games.

Marketing
After a game has been developed, the final step is marketing. Marketing of games includes a marketing strategy and a marketing plan. The marketing strategy is directly related to the choice of users and the types of games that are in demand.
The marketing plan is something that a publisher can give to a distributor to execute on the publisher's behalf. Some studies have been done from the perspective of game-user satisfaction that provide the baseline for the factors that game developers must take into account for new game development. Yee et al.
[S142] described a game motivation scale based on a three-factor model that can be used to assess game trends. Three studies [S139], [S143], and [S144] empirically investigated the perspective of game-user satisfaction and loyalty. No study in the literature has directly captured a marketing strategy and a marketing plan for games.

RQ 3: What research approaches are being used by researchers in
digital game domain? Table 10 shows that most GDSE process life cycle studies have used an exploratory research approach. Fig. 8 shows a comparison between the three research approaches used in the GDSE process life cycle domain. Fig. 9 shows a comparison among the empirical research methods used in the GDSE process life cycle domain. The results suggest that surveys are most frequently used in GDSE domain research.  more common than the other two methods. This is reasonable because the GDSE domain is still immature and researchers are trying to produce knowledge by questioning game users, experts, and others.

Final Remarks
The GDSE process proved to be incredibly challenging as game technology including game platforms and engines changes rapidly and coding modules are used very rarely in the another game project. However, recent success of digital game industry enforces further stress along with game development challenges and highlights the need of good practices adoption for game development process.
In order to find out the specific area in game development software engineering process for improvement, assessment of process activities needs to be performed.
However, due to relatively young history and empirical nature of the field, there has not been any development strategies or set of best practices to carry out game development fully explored. This systematic literature review helps to identify the research gaps in game development life cycle.
The main objective of this research was to provide an insight into the GDSE process life cycle domain because, in the past, researchers have pointed out that it is different from the traditional software development process. To achieve this objective, a systematic literature review was performed, which confirmed the first step of the evidence-based paradigm. The results also confirmed that the GDSE process life cycle domain is different from the traditional software engineering development process and that research activity is growing day by day, attracting the interest of more researchers. This paper describes the various topics in the GDSE domain and highlights the main research activities related to the GDSE process life cycle. The research topics identified in the GDSE were a combination of different disciplines and together they complete the game development process.

Empirical method Frequency
Case study 10/30 Experiment 6 / 3 0 Survey 14/30 The most heavily researched topics were from the production phase, followed by the pre-production phase. On the other hand, in the post-production phase, less research activity was reported. In the pre-production phase, the management topic accounted for the most publications, whereas in the production phase, the development platform, programming, and the implementation phase attracted the most researchers. The production phase has attracted more research because game developers focus more on implementation and programming because of the limited game-development time period. The post-production phase includes process validation, testing, and marketing topics. Very little research activity was observed in this area because the quality aspect of game development is not yet a mature field.
In addition to research topics, more researchers used exploratory research methods; as for empirical research methods, surveys were carried out by more researchers than case studies and experiments. Overall, the findings of this study are important for the development of good-quality digital games. Rapid and continual changes in technology and intense competition not only affect the business, but also have a great impact on development activities. To deal with this strong competition and high pressure, game development organizations must continually assess their activities and adopt an appropriate evaluation methodology. Use of a proper assessment methodology will help the organization identify its strengths and weaknesses and provide guidance for improvement.
However, the fragmented nature of the GDSE process requires a comprehensive evaluation strategy, which has not yet been entirely explored. Finally, this kind of research work provides a baseline for other studies in the GDSE process life cycle domain and highlights research topics that need more attention in this area. The findings of this study will help researchers to identify research gaps in GDSE process life cycle and highlights areas for further research contributions. This study also is a part of a larger project aiming to propose a digital game maturity assessment model. The identified important dimensions are developer's perspective, the consumer, the business (Aleem et al. 2016), and the process itself.
It also reinforces the assertion that the GDSE process life cycle domain is a complex scientific domain comparable to the software engineering development process, and it needs more attention and consideration of different factors in game development software engineering process.