Source-linked AI summary
Untangling the Spaghetti Code in Game Development: A Review of Challenges and Academic Solutions
Esdras Caleb Oliveira Silva, Lyrene Fernandes da Silva
TL;DR
Game development is perceived as having poorer code quality and more bugs, motivating questions about the prevalence of code smells and technical debt and the solutions available. The authors systematically review 34 studies. They report higher incidence of smells and technical debt in games, while proposed solutions have not gained broad developer uptake amid workflow priorities that favor rapid release and performance.
Problem
The review asks how game-domain code smells and technical debt compare with other domains, what solutions exist, whether developers are involved, and whether those solutions address the problems.
Source: §1 · p. 1, §3.1 · p. 2Method
The authors conduct a systematic literature review and assess 34 studies on game-development code quality and proposed solutions.
Source: §3.4.2 · p. 4Results
The game domain has higher incidence of code smells and technical debt than other software fields, while testing practices are minimal or absent.
Source: §5 · p. 6Takeaways & Limitations
Detection tools, product lines, and other processes could mitigate code-quality problems, but solutions have not gained widespread developer traction.
Source: §5 · p. 6, §7 · p. 7A single researcher read and classified studies, and manual rechecking of BART-MNLI screening could not rule out all erroneous exclusions.
Source: §6 · p. 7
Abstract
from arXiv · showhide
The code quality in the game domain is perceived as less structured and more convoluted than in other domains, which results in lower maintainability and higher bug frequency. In this work, we conduct a systematic literature review to address four main research questions: (1) how the incidence of code smells and technical debt differs in game development compared to other software domains; (2) what academic solutions are proposed to mitigate these code quality issues; (3) whether researchers collaborate effectively with developers to implement these solutions; and (4) if the proposed solutions are sufficient to tackle the diagnosed problems. Thirty-four works were mapped and analyzed. We found that the game domain is affected by a short-term mentality, continuous requirements changes, reduced code reuse, and minimal to no automated testing. As potential solutions, we identified tools and models to detect code smells, along with testing practices and product lines adapted for game development. Although these solutions exist, they are not widely adopted by practitioners, highlighting the need to investigate barriers to their integration.
1 Introduction
The introduction frames game software as persistently bug-prone and asks whether code-quality problems are distinctive to game development and why existing solutions appear not to work. The review examines the academic evidence and proposed remedies.
1 Introduction
- Games are perceived as recurrently bugged, and developers have acknowledged releasing games in a bugged state.The paper notes that bugs occur across domains, but are perceived as a recurring issue specifically in games.Source: §1 · p. 1
- The authors ask whether game development has an inherent code-quality problem, what research and tools could mitigate it, and why solutions appear not to work in practice.They note that flawed launches can affect player confidence, despite the industry's scale and potential benefits from high-quality code.Source: §1 · p. 1
- The systematic review examines game-domain susceptibility to code smells and the academic solutions proposed to address it.Its objective is to establish the current academic state and inform future research.Source: §1 · p. 1
2 Related Reviews
The related-review discussion positions this review around the link between code smells, technical debt, and defects in games. It also notes prior coverage of smell-detection techniques and calls for more systematic game-software-engineering research.
2 Related Reviews
- The review uses the reported relationship between code smells and software defects as a premise for examining solutions to code smells and technical debt in games.The discussion references prior systematic reviews and their treatment of smells, defects, and bugs.Source: §2 · p. 1
- Prior work connects technical debt with code smells and reports that strict game-development time constraints affect project technical debt.The review therefore considers both code smells and technical debt.Source: §2 · p. 1
- Earlier work surveys common smell-detection techniques, while another review identifies a need for more systematic game-domain research and development-cycle solutions.Source: §2 · p. 1
3 Method
Following systematic-review guidelines, the authors define four questions spanning game-domain code quality, proposed solutions, developer collaboration, and solution sufficiency. They search multiple scholarly sources, screen and assess studies, and retain 34 works for analysis.
3 Method
- The review follows Kitchenham and Charters’ guidelines to overview game-development code smells, technical debt, academic solutions, and developer involvement.Source: §3 · p. 1
3.1 Research Questions
- The four research questions cover domain differences in smells and debt, proposed solutions, developer collaboration, and whether solutions address diagnosed problems.The collaboration question asks whether data and solutions are developed with active developers and compatible with their workflow.Source: §3.1 · pp. 1–2
3.2 Consulted Databases
- The authors search Scopus, ScienceDirect, IEEE, Web of Science, ACM, and Google Scholar, adding Google Scholar to capture potentially insightful works absent from academic databases.They acknowledge that Google Scholar may have citation-count problems, but cite its coverage and search capabilities as reasons to include it.Source: §3.2 · p. 2
3.3 Search Terms
- They adapt PICO to the review: game domain or community as population, code problems as intervention, problem-solving techniques as comparison, and better code, manageability, or fewer bugs as outcomes.Search strings were pilot-tested and tailored to each database; Google Scholar used targeted queries and exclusions, while some databases used broader strings.Source: §3.3 · p. 2
3.4 Search Process
- The search found 1,599 works across six databases and was completed on August 15, 2024, the review’s publication cutoff.A metadata table supported selection, and the process is presented in Figure 1.Source: §3.4 · pp. 2–3
3.4.1 Exclusion and Inclusion Criteria.
- Screening excluded duplicate works, non-English works, and inaccessible Google Books, then considered keyword matches or title/abstract BART-MNLI scores of at least 0.50, with manual review to assess subject relevance.A manual audit of excluded records with “game” in their metadata found no false negatives. Of 113 works whose titles and abstracts were read, 36 were considered relevant; two duplicate works were also excluded.Source: §3.4.1 · p. 3
3.4.2 Quality Assessment.
- Studies needed yes answers to at least four of six quality questions; two studies were excluded, leaving 34 works, including one systematic review and 33 primary studies.Of the final studies, four earned the maximum score, 21 scored five, and nine scored four.Source: §3.4.2 · p. 4
4 Results
The mapped studies describe game-development code-quality problems alongside academic responses, while highlighting limited testing, time pressure, and challenges integrating solutions into practice.
4 Results
- Twenty works analyzed code and 19 experimented with code; 57.6% of studies engaged directly with the community through consulting or corporate partnerships.Eleven used interviews or surveys, and study combined experiments with a survey.Source: §4 · p. 4
4.1 Systematic Review
- The prior review mapped research topics, while this review asks why bug-plagued games persist despite extensive research.Product lines, testing, and management are identified as future-research topics, alongside an increasing number of works in the domain.Source: §4.1 · p. 4
4.2 Game Domain Specificities
- Studies report prevalent smells, tight deadlines and change, interdisciplinary-team difficulties, startup release pressure, and little automated testing.Management often invokes agile without applying it; developers’ intrinsic motivation can also sustain crunch and focus on the final product over process.Source: §4.2 · p. 4
4.3 Code Smell Classification and Detection
- Game code has domain-specific smells, including oversized assets and tool-use problems, while detection studies assess performance and sometimes recover code.Most classification studies use open-source code, though some use proprietary code; the review also identifies a need for refactoring and product lines.Source: §4.3 · p. 4
4.4 Product Lines
- Five works explore product lines for code reuse; studies report improved efficiency, user satisfaction, and maintainability, but industry partnerships identify refactoring as labor-intensive.Two works extend code-smell detection and feature recovery into a product line with fewer code lines and a unified visual identity.Source: §4.4 · pp. 4–5
4.5 Management
- Four works examine team management, reporting misuse of agile terminology; one applied Kaizen and reported greater company satisfaction, though prior Scrum use was incomplete.The included economy studies describe regional management differences and connect poor management with employee motivation.Source: §4.5 · p. 5
4.6 Tests and Quality Assessment
- Only 25 of 97 analyzed projects contained tests, which covered an average of 15.28% of code; interviews and company research likewise found scarce automated testing.The interviews found indie-game test absence and a preference for exploratory public testing over quality-assurance tests.Source: §4.6 · p. 6
4.7 Smell Impact
- Experiments found code smells negatively affect maintainability; smelly code had 15 more issues, and refactoring 3,294 detected problems was estimated to require 47 workdays.A study of Scratch found that smells in visual blocks can also harm children’s code comprehension.Source: §4.7 · p. 6
5 Discussion
Game development has higher code-smell and technical-debt incidence than other domains, with minimal testing, while research offers detection tools and product-line approaches that remain difficult to integrate into industry workflows. The review links this gap to release and performance priorities, limited developer engagement, and the need for domain-relevant evaluation.
RQ1
RQ2
- Researchers propose game-specific smell-detection tools and product lines, but developers have not widely adopted them amid rapid release cycles.The review says adoption depends on demonstrating usefulness with developers and fitting industry practices and needs.Source: §5 · p. 6
RQ3
- Although 57.6% of studies engaged industry, 42.4% lacked direct community feedback, and some partnered studies evaluated solutions only on finalized projects.Many studies emphasized maintainability, which is often not game developers’ primary daily constraint.Source: §5 · p. 6
RQ4
- Proposed solutions can mitigate smells and technical debt, but speed and performance priorities under tight deadlines limit their immediate integration.The review argues that even a universally effective smell fixer would not prompt immediate adoption.Source: §5 · p. 6
Management Issues
- The reviewed works describe a mismatch between claimed agile practices and strict release deadlines; hybrid lifecycles such as Agile-V add quality gates and verification while retaining iterative development.The review presents this as a way to support delivery and quality in game projects.Source: §5 · p. 6
Metrics
- Research should report performance and other domain-relevant metrics; a gray-area code review of Super Mario 64 demonstrated measurable performance improvements.The review argues that such metrics can better capture what matters to game developers.Source: §5 · p. 7
Automated Tests
- More automated code and QA testing is needed because QA remains predominantly manual; regression tests can prevent updates from undoing earlier fixes.The review also calls for understanding why developers rely on manual testing.Source: §5 · p. 7
6 Limitations of this Work
The review identifies internal and construct validity threats, including study selection and screening risks, interpretation of concepts, and keyword-driven sample bias. Its findings also exclude primary studies published after August 2024.
6 Limitations of this Work
- A single researcher read and classified studies, while BART-MNLI preliminary screening could exclude valuable articles despite manual rechecking.The authors mitigated the first threat through discussion with a second researcher and the screening threat through manual rechecking.Source: §6 · p. 7
- Keyword choices improve replicability but limit results and may induce sample bias, while differing interpretations of technical debt and code smells threaten construct validity.The authors reviewed the literature and adopted widely accepted definitions to mitigate interpretation differences.Source: §6 · p. 7
- The review's scope ends with its August 2024 literature-search cutoff, excluding primary studies published afterward.Source: §6 · p. 7
7 Conclusion
The review finds higher prevalence of low-quality code in game development and identifies domain-specific conditions linked to the problem. It also reports potential tools and processes, while noting adoption and research gaps remain.
7 Conclusion
- The game domain has a higher prevalence of low-quality code, linked to internal particularities of game development.Source: §7 · p. 7
- The review identifies tools and processes that could mitigate code-quality problems, but asks why those problems persist in game development.Source: §7 · p. 7
- Rapid delivery is prioritized over long-term maintainability, informal agile practices lack structured quality controls, and automated testing is significantly absent.The review says automated tests could mitigate part of the problem generated by low code quality.Source: §7 · p. 7
- Regional and organizational factors highlighted by Miozzo et al. remain unexplored in their specific impact on coding practices.The authors propose comparing workflows and post-release patch frequencies between Eastern and Western studios.Source: §7 · p. 7