Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
9
datasets available to search
ShareScore release 0.9.0
Dataset results
9 results for “game engine”
SyDRA: An Approach to Understand Game Engine Architecture
<p>Game engines are tools to facilitate video game development. They provide graphics, sound, and physics simulation features, which would have to be otherwise implemented by developers. Even though essential for modern commercial video game development, game engines are complex and developers often struggle to understand their architecture, leading to maintainability and evolution issues that negatively affect video game productions. In this paper, we present the Subsystem-Dependency Recovery Approach (SyDRA), which helps game engine developers understand game engine architecture and therefore make informed game engine development choices. By applying this approach to 10 open-source game engines, we obtain architectural models that can be used to compare game engine architectures and identify and solve issues of excessive coupling and folder nesting. Through a controlled experiment, we show that the inspection of the architectural models derived from SyDRA enables developers to complete tasks related to architectural understanding and impact analysis in less time and with higher correctness than without these models.</p>
Performance results of different scheduling algorithms used in the simulation of a modern game engine
<p><strong>Performance results of different scheduling algorithms used in the simulation of a modern game engine</strong></p> <p>These results are a companion to the paper entitled "<em>Exploring scheduling algorithms for parallel task graphs: a modern game engine case study</em>" by M. Regragui et al.</p> <p><strong>General information</strong></p> <p>This dataset contains raw outputs and scripts to visualize and analyze the scheduling results from our game engine simulator.<br> The result analysis can be directly reproduced using the script run_analysis.sh. A series of Jupyter Notebook files are also available to help visualize the results.</p> <p><strong>File information</strong></p> <p>- All Scenario*.ipynb files contain python scripts to visualize and analyze the simulation results.<br> - The Scenario*.py files contain python scripts that can be run directly with Jupyter Notebook.<br> - The requirements.txt file contains the names and versions of python packages necessary to reproduce the analysis.<br> - The run_analysis.sh file contains a bash script to install the required python packages and run the Scenario*.py scripts.</p> <p>The results are organized in five folders:</p> <p>1. Result_1 contains the results for Scenario 1 generated using file input_scenario_1.txt.<br> 2. Result_2 contains the results for Scenario 2 generated using file input_scenario_2.txt.<br> 3. Result_3 contains the results for Scenario 3 generated using file input_scenario_3.txt.<br> 4. Result_CP_1 contains the results for the critical path of Scenarios 1 and 2 generated using file input_CP_scenario_1.txt.<br> 5. Result_CP_3 contains the results for the critical path of Scenario 3 generated using file input_CP_scenario_3.txt.</p> <p>Each result file (e.g., HLF_NonSorted_Random_1_200_10.txt) contains 200 lines representing information of the 200 frames that were simulated. Each line contains four values: the frame number, the duration of the frame (in microseconds), a critical path estimation for the previous frame (in microseconds), and the load parameter (value between 0 and 1).</p> <p>The outputs of this analysis include some PDF files representing the figures in the paper (in order) and some CSV files representing the values shown in tables. The standard output shows the p-values computed in parts of the statistical analysis.</p> <p><strong>Software and hardware information</strong></p> <p>The simulation results were generated on an Intel Core i7-1185G7 processor, with 32 GB of LPDDR4 RAM (3200 MHz). The machine ran on Ubuntu 20.04.3 LTS (5.14.0-1034-oem), and g++ 9.4.0 was used for the simulator's compilation (-O3 flag).</p> <p>The results were analyzed using Python 3.8.10, pip 20.0.2 and jupyter-notebook 6.0.3. The following packages and their respective versions were used:</p> <p>- pandas 1.3.2<br> - numpy 1.21.2<br> - matplotlib 3.4.3<br> - seaborn 0.11.2<br> - scipy 1.7.1<br> - pytz 2019.3<br> - python-dateutil 2.7.3<br> - kiwisolver 1.3.2 <br> - pyparsing 2.4.7 <br> - cycler 0.10.0 <br> - Pillow 7.0.0<br> - six 1.14.0 </p> <p><strong>Simulation information</strong></p> <p>Simulation results were generated from 4 to 20 resources. Each configuration was run with 50 different RNG seeds (1 up to 50).</p> <p>Each simulation is composed of 200 frames. The load parameter (lag) starts at zero and increases by 0.01 with each frame up to a value equal to 100% in frame 101. After that, the load parameter starts to decrease in the same rhythm down to 0.01 in frame 200.</p> <p><strong>Algorithms abbreviation in presentation order</strong></p> <p>FIFO serves as the baseline for comparisons.</p> <p>1. FIFO: First In First Out.<br> 2. LPT: Longest Processing Time First.<br> 3. SPT: Shortest Processing Time First.<br> 4. SLPT: LPT at a subtask level.<br> 5. SSPT: SPT at a subtask level.<br> 6. HRRN: Highest Response Ratio Next. <br> 7. WT: Longest Waiting Time First.<br> 8. HLF: Hu's Level First with unitary processing time of each task.<br> 9. HLFET: HLF with estimated times.<br> 10. CG: Coffman-Graham's Algorithm.<br> 11. DCP: Dynamic Critical Path Priority.</p> <p><strong>Metrics</strong></p> <p>* SF: slowest frame (maximum frame execution time)<br> * DF: number of delayed frames (with 16.667 ms as the due date)<br> * CS: cumulative slowdown (with 16.667 ms as the due date)<br> </p>
Consensus of Game Engine Architectures: an Overview of Coupling and Subsystems in Game Engines
<p>The video game industry is one of the most innovative, competitive, and rapidly growing industries. The industry's successes along with the increasing gamers’ expectations result in always larger and more complex games. These games thus must be developed with game engines, which have become correspondingly more sophisticated. Today, game engine developers find game engine development challenging. To support the process of creating and maintaining game engines, we propose applying an approach based on a consensus algorithm to a set of game engine architectures. Our approach generates a model that suggests the most commonly used subsystems in game engine architectures, ranked by their degree of coupling. The model can be used by developers as a starting point when deciding what subsystems to include when building a game engine and points out the most coupled subsystems, which can play an important role towards higher subsystems maintainability and reusability. We evaluate our approach by comparing the results of our approach against a predefined ground truth data. The result of our approach matches the subsystems defined in the ground truth data and it shows that the most coupled subsystems are core, low-level rendering, third-party SDKs and world editor. Additionally, when comparing game engine architectures, we observe that most architectures are composed of nearly the same set of subsystems. </p>
Are Game Engines Software Frameworks? A Three-perspective Study
<p>Dataset for the paper: "Are Game Engines Software Frameworks? A Three-perspective Study"</p>
Dataset SLR Game Software Engineering 2009-21
<p>This dataset records the review process and results of the study "The Consolidation of Game Software Engineering: A Systematic Literature Review of Software Engineering for Industry-scale Computer Games."</p>
[SANER2020] Dataset of game engines and frameworks
<p>Dataset for the paper X</p>
Empirical Study and Vision for a Holistic Serious Game Platform for Software Engineering Education
<p>Serious games are becoming increasingly popular in universities to motivate students. Therefore, more and more lecturers are using game-based learning to encourage students to learn the subject matter. However, using serious games in Software Engineering (SE) lectures at universities is rather challenging as the subject is very practice-oriented and requires special kinds of tasks, e.g., practicing programming, software modeling, etc. Thus, building serious games and integrating such SE-specific tasks is a serious technical challenge and requires immense development effort. Therefore, before developing new games, students' preferences should be analyzed to increase the chances that these games will be played. To address this issue, we conducted an empirical study with 105 students to investigate the requirements and chances for using serious games in SE education in universities. Our analysis shows that students' preferences vary significantly and that there is no clear indication of a single game type that motivates all students equally. Therefore, our second contribution is a vision for a microservice-based Holistic Serious Game Platform for Software Engineering Education, which supports efficiently developing different serious games and integrating SE-specific mini-games and tasks. Hence, our empirical results and the presented approach support advancing research and development of serious SE games and also sensitize game developers to the needs of SE education.</p>
Questionnaire and Results for the "Gamify-IT - A Web-Based Gaming Platform for Software Engineering Education" Paper
<p>This archive contains the questions and results of our questionnaire to evaluate the prototype Gamify-IT e-learning platform. The questionnaire contains 18 questions and statements to evaluate the students' experience with the platform. We conducted the evaluation with students of our programming introductory course at the University of Stuttgart. 20 students provided their feedback. Results are anonymized.</p>
The Engineer-Built System, Video-Game Based Kinect Sensor in Upper Extremities Problems in Cerebral Palsy Children
ClinicalTrials.gov study NCT05311358. IPD Sharing: YES. Countries: 1. Publications: 7.
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.