Content uploaded by Fabio Petrillo
Author content
All content in this area was uploaded by Fabio Petrillo on Apr 17, 2020
Content may be subject to copyright.
A preview of the PDF is not available
Are Game Engines Software Frameworks? A Three-perspective Study
Preprints and early-stage research may not have been peer reviewed yet.
Abstract and Figures
Game engines help developers create video games and avoid duplication of code and effort, like frameworks for traditional software systems. In this paper, we explore game engines along three perspectives: literature, code, and human. First, we explore and summarise the academic literature on game engines. Second, we compare the characteristics of the 282 most popular engines and the 282 most popular frameworks in GitHub. Finally, we survey 124 engine developers about their experience with the development of their engines. We report that: (1) Game engines are not well-studied in software-engineering research with few studies having engines as object of research. (2) Game engines are slightly larger in terms of size and complexity and less popular and engaging than traditional frameworks. Their programming languages differ greatly from frameworks. Engine projects have shorter histories with less releases. (3) Developers perceive game engines as different from traditional frameworks and claim that engines need special treatments. Generally, they build game engines to (a) better control the environment and source code, (b) learn about game engines, and (c) develop specific games. We conclude that game engines are different from traditional frameworks although this difference is too small to force special treatments.
Figures - uploaded by Fabio Petrillo
Author content
All figure content in this area was uploaded by Fabio Petrillo
Content may be subject to copyright.
ResearchGate has not been able to resolve any citations for this publication.
Game engines are a vital part of a game production pipeline, but there is a vagueness of definitions regarding the boundaries of components in a game engine and the rest of the production tools used in a game development pipeline. The aim of this paper is to nuance the use of the term game engine and to put it into the context of a game development pipeline. Based on data from the current state of game production, a proposed taxonomy for tools in game development is presented. A distinction is made between user facing tools and product facing tools. A defining characteristic of the production pipeline and game engines is their plasticity. One of the conclusions is that a "game engine" as a single entity containing the whole game production pipeline is not desirable due to the large number of competences and needs involved in a game development project.
Software engineering research is evolving and papers are increasingly based on empirical data from a multitude of sources, using statistical tests to determine if and to what degree empirical evidence supports their hypotheses. To investigate the practices and trends of statistical analysis in empirical software engineering (ESE), this paper presents a review of a large pool of papers from top-ranked software engineering journals. First, we manually reviewed 161 papers and in the second phase of our method, we conducted a more extensive semi-automatic classification of papers spanning the years 2001–2015 and 5196 papers.
Results from both review steps was used to: i) identify and analyse the predominant practices in ESE (e.g., using t-test or ANOVA), as well as relevant trends in usage of specific statistical methods (e.g., nonparametric tests and effect size measures) and, ii) develop a conceptual model for a statistical analysis workflow with suggestions on how to apply different statistical methods as well as guidelines to avoid pitfalls.
Lastly, we confirm existing claims that current ESE practices lack a standard to report practical significance of results. We illustrate how practical significance can be discussed in terms of both the statistical analysis and in the practitioner’s context.
Besides a git-based version control system, GitHub integrates several social coding features. Particularly,GitHub users canstara repository, presumably to manifest interest or satisfaction with an open sourceproject. However, the real and practical meaning ofstarring a projectwas never the subject of an in-depthand well-founded empirical investigation. Therefore, we provide in this paper a throughout study on themeaning, characteristics, and dynamic growth of GitHub stars. First, by surveying 791 developers, we reportthat three out of four developers consider the number of stars before using or contributing to a GitHubproject. Then, we report a quantitative analysis on the characteristics of the top-5,000 most starred GitHubrepositories. We propose four patterns to describe stars growth, which are derived after clustering the timeseries representing the number of stars of the studied repositories; we also reveal the perception of 115developers about these growth patterns. To conclude, we provide a list of recommendations to open sourceproject managers (e.g., on the importance of social media promotion) and to GitHub users and SoftwareEngineering researchers (e.g., on the risks faced when selecting projects by GitHub stars).
Arguably the prime focal point of a software system’s engineering is its architecture. A system’s architecture is the set of principal design decisions made during its development and evolution. All too often, however, the architecture—and every system has an architecture—is left latent. Such disregard arises from many factors; some would go so far as to say that an explicit focus on architecture is unnecessary. This chapter explores different contexts in which software development occurs and, with respect to those contexts, discusses what kind of attention to architecture is needed, why it is needed, how it may be approached, and benefits that may be achieved through such attention. The objective is to highlight the degrees of architectural rigor and effort that are commensurate with the needs of diverse projects.
This article illustrates a gap between popular narratives of game development in design texts and the reality of day-today development, drawing from an ethnographic account of intern developers to highlight the potential contributions of studio studies to both game scholars and aspiring developers. It describes three take-aways. The first is that developers have difficulty articulating their work to others, impacting how we learn, teach, and talk about development, including how we share knowledge across domains. The second is that negotiation with technology rather than mastery characterizes the daily work of new developers, and the third is that problems frequently arise in articulating and aligning the normally black-boxed work of individual developers. Resolution of these issues commonly depends on 'soft' social skills, yet, external pressures on developers mean they tidy up and professionalize accounts of their daily practice, thus both social conflict and 'soft' skills have a tendency to disappear.
Quality assurance is an integral part of software development process. Game projects possess own distinctive traits that affect all stages of work. In this paper, we share the lessons learned during a three year-long mobile game development project. We discuss the conceptual architecture for mobile game quality assurance through the perspective of techniques that turned out to be most efficient for us, including manual testing, automated and manual runtime bug reporting, Crashlytics-supported crash analysis, automated smoke testing, and playtesting. We analyze how these activities address typical game-specific mobile development and testing issues, and why they can be recommended for game projects, as well as for wider range of mobile applications.
Context: The video game industry is a billion dollar industry that faces problems in the way games are developed. One method to address these problems is using developer aid tools, such as Recommendation Systems. These tools assist developers by generating recommendations to help them perform their tasks.
Objective: This article describes a systematic approach to recommend development processes for video game projects, using postmortem knowledge extraction and a model of the context of the new project, in which “postmortems” are articles written by video game developers at the end of projects, summarizing the experience of their game development team. This approach aims to provide reflections about development processes used in the game industry as well as guidance to developers to choose the most adequate process according to the contexts they’re in.
Method: Our approach is divided in three separate phases: in the first phase, we manually extracted the processes from the postmortems analysis; in the second one, we created a video game context and algorithm rules for recommendation; and finally in the third phase, we evaluated the recommended processes by using quantitative and qualitative metrics, game developers feedback, and a case study by interviewing a video game development team.
Contributions: This article brings three main contributions. The first describes a database of developers’ experiences extracted from postmortems in the form of development processes. The second defines the main attributes that a video game project contain, which it uses to define the contexts of the project. The third describes and evaluates a recommendation system for video game projects, which uses the contexts of the projects to identify similar projects and suggest a set of activities in the form of a process.
