PaperlayerView exact revision on arXiv

Source-linked AI summary

Game Development Software Engineering Process Life Cycle: A Systematic Review

Saiqa Aleem, Luiz Fernando Capretz, Faheem Ahmed

arXiv:1711.08527v1cs.SE

TL;DR

Game development differs from traditional software development, and the complete GDSE life cycle had not been studied. This systematic literature review examines GDSE research and finds the most activity in production, less in post-production, identifying that phase as needing further attention.

Abstract

from arXiv · show

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. Although the game development process differs from the traditional software development process because it involves interdisciplinary activities. Software engineering techniques are still important for game development because they can help the developer 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.

1. Introduction

Game development combines creative and technical disciplines, making its engineering process complex and distinct from traditional software development. This study systematically reviews research on the GDSE process life cycle to map the state of the art and identify gaps for further investigation.

1. Introduction

  • Game development combines diverse creative and technical activities, making it complex and different from traditional software development.The cited passages identify sound, art, control systems, AI, and human factors as parts of this multidisciplinary process.Source: §1 · p. 2
  • Proposed GDSE life-cycle phases do not by themselves ensure a quality development process.The introduction also notes that companies may shorten development to reach the market sooner, affecting game quality.Source: §1 · p. 3

1.1 Related work

  • The authors report that no systematic literature review had addressed the GDSE process life cycle, despite related reviews of software games.They frame this review as a first step toward identifying research gaps.Source: §1 · p. 3, §1.1 · p. 4
  • A systematic literature review examined software development processes; a separate systematic study addressed research on software engineering, but the cited passages do not establish either review’s engagement or learning-outcome focus.Source: §1.1 · p. 4
  • The review examines existing GDSE process research to identify gaps and areas for further investigation.It aims to cover the state of the art for the GDSE process life cycle.Source: §1.1 · pp. 4–5
  • The study uses an evidence-based research paradigm and a systematic literature review.The passage describes the SLR as the first step in an evidence-based research process.Source: §1.1 · p. 5

2. Research Background

Games serve entertainment and serious purposes across domains, while game development differs from traditional software development. Earlier work offered varied GDSE lifecycle models, and this review groups the lifecycle into three phases to examine research coverage and gaps.

2. Research Background

  • Software games serve entertainment and serious purposes across domains including education, business, and health care.Source: §2 · p. 5
  • Researchers had proposed differing GDSE lifecycle models, and no single answer described which practices were used.The models named phases such as pre-production, production, testing, beta, and release in varying combinations.Source: §2 · pp. 6–7
  • Prior studies compared software engineering and GDSE, but none examined the complete GDSE process life cycle and its research topics in detail.Source: §2 · p. 7
  • The review is the first systematic review of GDSE process-life-cycle topics and identifies topics needing further researcher attention.It groups the phases as pre-production, production, and post-production.Source: §2 · pp. 7–8

3. Review Methodology

The review follows systematic literature review guidance and organizes the process into three phases. It also uses the SLR to assess research intensity across GDSE lifecycle phases.

3. Review Methodology

  • The review adopts the systematic literature review process described by Kitchenham and Charters and presents it as three phases with associated steps.Source: §3 · p. 8
  • Kitchenham’s guidance is used to investigate research intensity for each GDSE process-life-cycle phase.Source: §3 · p. 8
  • The SLR approach collects empirical evidence from existing literature to address a formulated research question.Source: §3 · p. 8

3.1 Planning Phase (Step 1 -4)

The planning phase defines the review’s topic, objectives, and domain boundaries, then frames questions about research activity, topics, approaches, and methods. It also establishes a protocol and a three-person review team to support thoroughness and reduce potential bias.

3.1 Planning Phase (Step 1 -4)

  • The study begins by selecting a topic, defining objectives, and delineating the domain boundaries.Topic selection is described as crucial because individual or community interest, research gaps, and research impact contribute to shaping questions.Source: §3.1 · p. 8, §3.1.1 · p. 8

3.1.1 Selection of Topic and Research Questions

  • The review targets a field where many areas lack generalized evidence and prior phase-specific studies do not provide systematic, comprehensive, and thorough methodological research.The authors frame identifying a quality-driven GDSE process as important for the game industry.Source: §3.1.1 · p. 8
  • Four research questions examine GDSE research intensity, phase-specific topics, research approaches, and empirical methods.Publication counts per year represent research activity, while each study is classified by topic, approach, and methodology.Source: §3.1.1 · pp. 8–9

3.1.2 Review Team & Protocol Establishment

  • A three-person team used a review protocol and evaluation procedure, with two principal reviewers and a project leader handling administrative and quality-assurance tasks.The protocol was developed to support replicability and reduce researcher bias.Source: §3.1.2 · pp. 9–10

3.2 Conducting Phase (Step 5-9)

The review searches and screens literature using a structured protocol, assesses study quality with a checklist, and synthesizes studies by GDSE topics and research methods. Its analysis tracks publication activity, phase-specific topics, research approaches, and empirical methods.

3.2.2 Pilot Selection & Data Extraction

  • The two-phase selection first screened titles, abstracts, and conclusions against inclusion criteria, then studied the whole article when it met criteria; 127 papers were identified after final selection.Source: §3.2.2 · p. 12

3.2.4 Data Synthesis

  • The topic classification covers issues in the pre-production, production, and post-production phases of the GDSE life cycle.The review used the 2012 ACM classification system to classify the papers’ topics.Source: §3.2.4 · p. 14
  • Research articles were categorized by approach as descriptive, exploratory, or empirical, with surveys, case studies, and experiments identified as major empirical methods.The review used these categories to characterize the methods and approaches represented in the studies.Source: §3.2.4 · p. 15
  • The analysis tracked yearly publication counts and data-source counts for RQ1, phase-related topics for RQ2, and research approaches and methods for RQ3 and RQ4.The collected data were statistically analyzed, tabulated, and presented in Appendix B.Source: §3.2.4 · p. 15

3.3 Documenting (Step 10-12)

The review documents threats and limitations that may affect its findings, while concluding that its results may be useful to game-development organizations and developers.

3.3 Documenting (Step 10-12)

  • Studies discussing game development may have been missed when “game” was absent from their titles, because the search procedure could exclude them from the primary dataset.The authors also identify generalization and subjective evaluation as threats associated with systematic reviews (Shadish et al., 2002).Source: §3.3 · pp. 15–16
  • The search was limited to academic databases, excluding blogs and forums that developers use and that did not meet the review’s paper-selection quality criteria.Excluding less-known journals and conferences from Web of Science and Scopus may also have produced a different dataset.Source: §3.3 · p. 16
  • Using a classification scheme other than ACM, such as the waterfall model, might have altered the results.Despite the limitations, the authors say the review may be useful to game-development organizations and developers.Source: §3.3 · p. 16

of software games. 4. Analysis of Results and Discussion

The analysis draws on 148 studies to describe the dataset and answer the review’s research questions. The authors also compare their findings with earlier studies of software engineering research.

4. Analysis of Results and Discussion

  • Statistical analysis of the dataset is used to present findings concerning the research questions, with dataset characteristics tabulated for clarity.The section presents the results of the statistical analysis and discusses the findings.Source: of software games. 4. Analysis of… · p. 16
  • The review collated and analyzed 148 studies to identify characteristics of the game-development software-engineering process life cycle.The mapped-study categories are listed in Appendix B.Source: of software games. 4. Analysis of… · p. 16
  • The review compares its findings with similar studies by Cai and Card (2008), Glass et al. (2002), and Dyba and Dingsoyr (2008).Source: of software games. 4. Analysis of… · p. 16

4.1 RQ1 What is the intensity of research activity on the GDSE process life

The review reports polynomial growth in GDSE publications since 2005, alongside a 2013–2015 decline and shifts in the geographic distribution of research activity.

4.1 RQ1 What is the intensity of research activity on the GDSE process life

  • Fig. 4 shows that GDSE process-life-cycle research activity continuously increased during the last few years.Its vertical axis expresses each year’s publication count as a fraction of the 2007 count.Source: cycle? · pp. 16–17
  • GDSE publications grew at a polynomial rate since 2005, although research activity dropped in 2013, 2014, and 2015.Table 8 presents citation type and per-year research activity.Source: cycle? · pp. 16–17, Table 8 · p. 17
  • The authors suggest the 2014 decline reflected activity outside the selected publication sources, including game-development groups and developers’ blogs.Source: cycle? · p. 17
  • China’s GDSE research began in 2010 and came to dominate the area within four years, while the United States and United Kingdom were active before 2010.Source: cycle? · p. 17
  • Asia has dominated GDSE research since 2010, following earlier contributions from North and South America and the start of European contributions in 2007.Source: cycle? · p. 17
  • IEEE accounted for approximately 63% of GDSE research publications, followed by Elsevier and Springer.Source: cycle? · p. 17

4.2 RQ 2: What topics are being researched in the pre-production.

This section surveys research topics across pre-production and production, including management, reuse, design documents, prototyping, design tools, risk management, asset creation, storyboards, development platforms, formal language description, programming, game engines, and implementation technologies. It also covers research activity across lifecycle phases, including the relative attention to production, pre-production, and post-production, and the topics leading within pre-production and post-production.

production and post production phase?

  • Production has the most GDSE life-cycle research, pre-production ranks second, and post-production has received much less attention.Production research intensity is attributed to demand for efficient development and coding techniques; the implementation phase is described as shorter than in traditional software development because of time to market.Source: production and post production phase? · pp. 18–19
  • Management of game development is the most researched pre-production topic, followed by development platforms, programming, and implementation; marketing leads post-production research.The account links increased pre-production research to games’ emphasis on entertainment and user enjoyment.Source: production and post production phase? · p. 19

5.2.1.1 Management

  • Management research covers development strategies, frameworks, agile practices, process issues, and interdisciplinary team interaction, while a game-specific process maturity model is still needed.The passage also identifies staying on budget, meeting timing, and producing the desired output as management considerations.Source: §5.2.1.1 · pp. 19–20

5.2.1.2 Requirements Specification

  • Game requirements must account for emotion, gameplay, aesthetics, and immersion, and integrate non-functional requirements alongside gameplay requirements.The identified challenges include communication across stakeholder backgrounds, integrating non-functional requirements with gameplay, and validating audience-dependent qualities such as fun.Source: §5.2.1.2 · p. 20
  • Requirements work addresses emotional criteria, gameplay criteria such as cognitive factors and mechanics, and sensory requirements including visual, auditory, and haptic aspects.Callele et al. [S20] proposed a requirements set based on these dimensions.Source: §5.2.1.2 · p. 20

5.2.1.3 Game System Description Language

  • Game system description approaches include UML, agent-based and soft-system methodologies, feature-analysis modelling, and ontology frameworks; a soft-system approach can provide an overview of game concepts.Tylor et al. [S28] proposed the soft-system methodology for initial concept identification and as an alternative to a popular description language.Source: §5.2.1.3 · p. 21
  • A game system description language should be human-readable, formal enough for comparison and analysis, production-independent, and able to describe the overall process with clear developer guidance.Quanyin et al. [S32] proposed a UML model for mobile games and reported it as a good model for further Android game development.Source: §5.2.1.3 · p. 21

5.2.1.4 Reusability

  • Reuse research highlights commonality and variability analysis in pre-production; game-development reuse techniques may reduce cost and time while improving quality and productivity.The passage notes a survey of reuse techniques and their similarity to software product lines.Source: §5.2.1.4 · p. 21
  • A proposed adaptive-development framework used loosely coupled components for flexibility and was tested through educational games, whose requirements needed to align with existing reusable components.Source: §5.2.1.4 · p. 22

5.2.1.5 Game Design Document

  • Game design documents describe core components and their relationships, but incomplete representation and poor-quality documents can contribute to rework, financial losses, and poor-quality products.The review calls formal GDD development important and notes that comprehensive documents focused on a game's basic design and premises support good game quality.Source: §5.2.1.5 · p. 22

5.2.1.6 Game Prototyping

  • Pre-production prototypes clarify fundamental mechanics, communicate play mechanics, and help evaluate player experience; proposed approaches include model-driven code generation and community-driven reuse.Rapid prototyping was also analyzed for history-dependent games, 3D interactive games, and game development frameworks.Source: §5.2.1.6 · pp. 22–23

5.2.1.7 Design Tools

  • Game design tools support detailed descriptions of effects and events without high-level programming skills, while enabling component reuse and reducing game-creation time.Event-design tools for rapid game development were proposed by Cho and Lee [S56] and Segundo et al. [S57].Source: §5.2.1.7 · p. 23

5.2.1.8 Risk Management

  • Risk management received little research attention; the only identified study [S58] highlighted development-strategy failure and lack of fun, while developers gave formal risk analysis low priority.Potential risks also include originality, scheduling, and budgeting.Source: §5.2.1.8 · p. 23

5.2.2.1 Asset Creation

  • Production asset research covered audio-processing libraries, model-driven user-interface development, and a brain-computer interface using EEG Mu rhythms to control mobile games.Source: §5.2.2.1 · p. 24

5.2.2.2 Storyboard Production

  • Storyboard work included AI-assisted exploration of game-level scenarios, scripting-system classification, and scene-editor software for developing and editing game scenes.Some tools generate game levels automatically from descriptions.Source: §5.2.2.2 · p. 24

5.2.2.3 Development Platforms

  • Development platforms provide ready-made architectures for server-client connectivity and faster game creation; reported work included multi-platform development and customizable mobile 3D-game templates.Source: §5.2.2.3 · pp. 24–25
  • Development-platform research considered rapid game development through platforms offering connectivity and client customization while avoiding unnecessary game-server updates.The supplied passage fragments also identify an educational children’s game platform and attribute a highlighted point to Suomela et al. [S77].Source: §5.2.2.3 · p. 25

5.2.2.4 Formal Language Description

  • Only two studies addressed formal language description of game semantics, and few semantic descriptions of languages have been published.This work uses game semantics to gain insight into programming-language design for game development.Source: §5.2.2.4 · p. 25

5.2.2.5 Programming

  • Programming studies explored development environments and languages, collision-detection and AI algorithms, object-oriented performance, and tools for complex multi-platform development.The reviewed work also described content libraries, graphical IDE support, and generative programming for integrating development artefacts.Source: §5.2.2.5 · p. 26

5.2.2.6 Game Engine

  • Game-engine research addressed engine requirements and script engines, mobile-platform engine development, engine selection, and customizable or design-pattern-based engines.One study highlighted affective-engine requirements, including identifying player emotions and social interactions among characters.Source: §5.2.2.6 · p. 27

5.2.2.7 Implementation

  • Implementation research covered platform technologies and frameworks, including mobile-device frameworks and solutions for communication, synchronization, and server-exhaustion problems.Topics also included browser-game technologies, game-theory-based design-to-implementation frameworks, and mobile-game APIs.Source: §5.2.2.7 · pp. 27–28

5.2.3 Post-Production Phase

Post-production coverage spans quality assurance, testing, and marketing, but reported research remains sparse across these topics. The reviewed work includes limited process validation, beta testing, heuristic and empirical testing, and testing tools, while no study directly captures marketing strategy or plans.

5.2.3.1 Quality Assurance

  • Only two studies addressed quality assurance; case studies involved small teams or one phase, and standard methodologies were lacking.The review describes process-data evaluation from pre-production through post-production as a way to assess whether the development process produces a good-quality game.Source: §5.2.3.1 · p. 28

5.2.3.2 Beta Testing

  • Only four studies addressed beta testing; reported educational-game schemes distinguish expert evaluators from real-world users.The review also reports an AHP-based online evaluation tool for educational computer games.Source: §5.2.3.2 · p. 29

5.2.3.4 Heuristic-Based Testing

  • Six studies covered heuristics, which can recur from early design and assess story, play, mechanics, usability, and quality through experts and users.The review notes that game evaluation extends beyond the interface to playability experiences.Source: §5.2.3.4 · p. 29

5.2.3.5 Empirical Testing

  • Only two studies covered empirical testing, focused on final-product quality and usability; reported work included QEF evaluation and usability-expert testing.The review reports experimental results showing the importance of validation in game development.Source: §5.2.3.5 · p. 30

5.2.3.6 Testing Tools

  • Only one study addressed testing tools, proposing black-box and scenario-based testing; available tools focused only on online games.The proposed tool was used on several online games to verify its effectiveness.Source: §5.2.3.6 · p. 30

5.2.3.7 Marketing

  • No study directly captured marketing strategy or plans; three studies instead examined game-user satisfaction and loyalty.The satisfaction studies provide a baseline for factors developers should consider when developing new games.Source: §5.2.3.7 · pp. 30–31

digital game domain?

  • Exploratory and descriptive approaches are now used equally; descriptive work led before 2010, while exploratory work gained afterward, and surveys were most frequent.The authors associate the shift toward exploratory research with the domain's maturation.Source: digital game domain? · p. 31

4.4 RQ4: What empirical research methods are being used in the software

Surveys were more common than case studies and experiments in the GDSE process life cycle literature. Experiments and case studies were used infrequently, with the review noting experience and data-access constraints.

4.4 RQ4: What empirical research methods are being used in the software

  • Experimental empirical methods were less used, which the authors relate to the experience required to conduct formal experiments.The cited rationale is attributed to Wohlin et al. (2000).Source: games domain? · p. 31
  • Case studies were infrequent; they require project data from observations or measurements, and no GDSE process life cycle research repository was available.The authors offer this data requirement as a possible reason for their infrequent use.Source: games domain? · p. 31
  • Surveys were more common than the other two empirical methods in the GDSE process life cycle domain.The review describes surveys as a way of questioning game users, experts, and others.Source: games domain? · pp. 31–32

7. Final Remarks

This systematic review surveys the GDSE process life cycle, finding an uneven distribution of research across its phases and a growing but still young field. It identifies research gaps and areas needing further attention, particularly in post-production and comprehensive evaluation.

7. Final Remarks

  • A systematic literature review examined the GDSE process life cycle, confirming that it differs from traditional software engineering and that research activity is growing.The study describes its review as confirming the first step of the evidence-based paradigm.Source: §7 · p. 32
  • Production was the most heavily researched phase, followed by pre-production, while post-production received less research activity.Management attracted the most pre-production publications; development platforms, programming, and implementation attracted the most production research.Source: §7 · p. 33
  • Post-production topics—process validation, testing, and marketing—had very little research activity, which the authors link to game quality not yet being fully explored.The review also notes that production attracts more research because developers focus on implementation and programming within limited development time.Source: §7 · p. 33
  • Researchers used exploratory approaches more often, and surveys more often than case studies and experiments.The authors state that the findings provide a baseline and identify topics needing further research.Source: §7 · p. 33
  • The fragmented GDSE process requires a comprehensive evaluation strategy, which the authors say has not yet been entirely explored.They also report that the field's relatively young history and empirical nature mean development strategies or best practices have not been established.Source: §7 · pp. 32–33

Learning.

The supplied material is primarily bibliographic, listing works on games and serious games, game-development processes, and systematic-review methods.

Learning.

  • The references include a systematic review of empirical evidence on computer and serious games (Connolly et al., 2012).The entry is split across the supplied passages.Source: Learning · p. 35
  • The references include guidance for conducting systematic literature reviews, including works by Kitchenham (2004) and Kitchenham and Charters (2007).The corresponding bibliography entries identify a technical report and review guidelines.Source: Learning · p. 36
  • The bibliography lists a systematic literature review on software development processes for games by Osborne-O’Hagan, Coleman, and O’Connor (2014).The supplied entry identifies the EuroSPI 2014 proceedings and pages 182–193.Source: Learning · p. 36

Appendix B Study Dataset

This appendix catalogs study dataset records by publication source or venue, year, location, format, and study type. The records span several topic groupings, including game requirements, system description languages, and formal language description.

Appendix B Study Dataset

  • The dataset lists records S1–S104 with publication venue, year, country, and study type.The records include conference, journal, book, and workshop entries, as well as exploratory, descriptive, survey, case study, and empirical types.Source: Appendix B · pp. 49–50

Game requirement specification

  • The “Game requirement specification” grouping identifies S19 (IEEE, 2005, Canada, Conference, Exploratory) and S26 (ACM, 2015, USA, Workshop, Descriptive) as separately specified records.Source: Appendix B · p. 49

Game system description languages

  • The game system description languages grouping lists records S28–S51 across journal and conference venues.Entries include exploratory, descriptive, survey, case study, and experiment empirical types.Source: Appendix B · pp. 49–50

Appendix B Study Dataset

  • Records S52–S98 are marked as related work and include descriptive, exploratory, survey, case study, and empirical types.The listed records span IEEE, ACM, Springer, and Google Scholar sources, among others.Source: Appendix B · pp. 50–51

Formal language description

  • The Formal language description passages identify S99 as a 2005 Springer journal study from France (Descriptive), S103 as a 2013 IEEE conference study from Thailand (Case study Empirical), and S104 as a 2012 IEEE conference study from China (Descriptive).Source: Appendix B · p. 51

Appendix B Study Dataset

  • S105–S109 are IEEE and ACM conference studies from China, Turkey, the US, and the UK (2009–2013); four are exploratory and one is descriptive.Source: Appendix B · pp. 50–51
  • S110 is a 2014 UK book classified as descriptive, while S111 is a 2015 Greek conference study classified as exploratory.Source: Appendix B · p. 51
  • Studies S112–S120 are IEEE publications dated 2007–2013 from Egypt, China, Mauritius, Portugal, Colombia, Finland, Brazil, and Taiwan, appearing as conferences, a workshop, and a journal.Their classifications include descriptive, exploratory, and empirical experiment studies.Source: Appendix B · p. 51
  • S121–S124 include a 1999 Japanese IEEE conference experiment and three descriptive US records from 2015: two IEEE conference studies and one Google Scholar book.Source: Appendix B · p. 51
Loading 1711.08527v1…