Evaluation of CPU and Memory

performance between
Object-oriented Design and
Data-oriented Design in Mobile
games.

PAPER WITHIN Computer Science

AUTHOR: Björn Eriksson and Maria Tatarian
TUTOR: Domina Robert Kiunsi
JÖNKÖPING 02 2021
This exam work has been carried out at the School of Engineering in Jönköping in the
subject area Computer Science. The work is a part of thethree-year Bachelor of
Science in Engineering program.
The authors take full responsibility for opinions, conclusions and findings presented.

Examiner: Johannes Schmidt

Supervisor: Domina Robert Kiunsi

Scope: 15 credits

Date: 2021-02-13
Abstract

Acknowledgments
We want to thank our Examiner Johannes Schmidt for guiding us with interesting
and helpful feedbacks.

We want to thank our supervisor Domina Robert Kiunsi for always being there
when we needed help throughout the writing process.

We want to thank our teachers for helping us develop our knowledge and
competence during these three years at the university.

Finally, we want to thank our families for their support and encouragement.

1
 Abstract

Abstract
The popularity that mobile games gained recently gives the opportunity to develop more mobile
games. Limited by the scarce resources on mobile phones, developing good games becomes
critical and requires special optimization while choosing the design approach.

Object-oriented Design (OOD) and Data-oriented Design (DOD) are two programming
paradigms that have different ways of defining and structuring data. The purpose of this student
thesis is to investigate the CPU and Memory performance differences between the two
approaches.

To answer the research questions an experiment is conducted where two identical mobile games
are built, one according to OOD and the other to DOD to collect empirical quantitative data
and compare the results. The study limits the scope by running the games on Android mobile
phones.

The results of comparing the CPU Usage show significant differences especially when the
amount of data is large. For instance, in the DOD version of the game,the CPU spends 20.9%
of the time on updating data, while it spends 69.2% of thetime on the same action in the OOD
version of the game.
No significant differences are observed regarding the total Memory allocated for the games in
both versions. It can therefore be concluded that when the number of objects/data is big, a
more optimized code should be written following the Data oriented Design approach with
regard to better CPU and Memory Usage and better game performance.

Keywords
Mobile games, Object-Oriented Design, Data-Oriented Design, Game performance, CPU
Usage, Memory Usage.

2
Contents

1 Introduction ............................................................ 1
1.1 BACKGROUND ............................................................................................... 1

1.2 PROBLEM STATEMENT ................................................................................................... 2

1.3 PURPOSE AND RESEARCH QUESTIONS ............................................................................. 3

1.4 DELIMITATIONS ........................................................................................................... 4

1.5 DEFINITIONS .............................................................................................................. 4

1.6 OUTLINE .................................................................................................................. 5

2 Theoretical background .............................................. 6

2.1 PREVIOUS RESEARCH ON OOD AND DOD APPROACHES ................................................ 6

2.2 LINK BETWEEN RESEARCH QUESTIONS AND THEORY ............................................................7

2.3 OBJECT ORIENTED DESIGN (OOD) ................................................................ 7

2.4 DATA ORIENTED DESIGN (DOD) .................................................................. 9

2.5 CPU USAGE ........................................................................................................ 10

2.6 MEMORY USAGE ................................................................................................... 10

2.7 THE GAME ENGINE UNITY ....................................................................................... 10

2.7.1 Classical Unity 3D ........................................................................... 10

2.7.2 DOTS ................................................................................... 11

3 Method and implementation ...................................... 15

3.1 LINK BETWEEN RESEARCH QUESTIONS AND METHODS ........................................................ 15

3.2 HYPOTHESIS ............................................................................................................ 15

3.3 WORK PROCESS ................................................................................................... 15

3.4 GAME DESIGN ...................................................................................................... 16

3.4.1 Classical Unity (OOD Version) ............................................................ 17

3.4.2 DOTS (DOD Version) .................................................................... 18
3.5 DATA COLLECTION ................................................................................................ 18

3.6 DATA ANALYSIS ..................................................................................................... 18

3.7 VALIDITY AND RELIABILITY ........................................................................................ 19

4 Findings and analysis ............................................... 21

3
Contents

4.1 CPU ...........................................................................................21

4.1.1
Findings. .......................................................................................... 21
4.1.2 Analysis
.................................................................................................................................................. 21
4.2 MEMORY ........................................................................................................... 24

4.2.1
Findings. .......................................................................................... 24
4.2.2 Analysis
.................................................................................................................................................. 24

5 Discussion and conclusions ...................................... 26

5.1 DISCUSSION OF METHOD ....................................................................................... 26

5.2 DISCUSSION OF FINDINGS ...................................................................................... 27

5.2.1 Discussion of first research question: “How does the CPU Usage differ in the two
approaches?” .........................................................................................................................................................
27 5.2.2 Discussion of second research question: “How does the Memory Usage differ in the
two approaches?”
......................................................................................................................................................... 28
5.3 CONCLUSIONS .................................................................................................... 28

5.4 FUTURE WORK ................................................................................................... 29

6 References .......................................................... 30 7
Appendices...........................................................32

4
 1 Introduction
The chapter provides a background for the study and the problem area the study is built upon. Further, the
purpose and the research questions are presented. The scope and delimitations of the study are also described.
Lastly, the disposition of the thesis is outlined.

Recently, mobile games played an important role in the entertainment industry, an increased
number of people play games using their mobile phones. According to statistics, there are
2.3 billion mobile gamers who play mobile games more than 10 times per week (Cough,
2020). This increased number of mobile gamers gives the opportunity to develop more
mobile games.

As mobile phones get newer and better in both design and functionality, processor sizes and
memory capacity, mobile games development requires increased development quality to
utilize the modern phones abilities and to improve game performance (Hammershoj,
Sapuppo, & Tadayoni, 2010). A gamer enjoys the game most when it has fast interactions
which make the game real and exciting, that is why the performance of the game is something
essential for the developer to consider.

Developing good games requires special optimization for choosing the right design approach
to write the code accordingly (Inam, Malik, Sabahat, & Subhani, 2017). This is especially
crucial in mobile games development, because of the scarce resources on mobile devices,
such as the small memory, CPU, small screen size, limited battery life etc. (Zhang, Han,
Kunz, & Hansun, 2007).

This student thesis aims to investigate whether any significant performance improvements
can be achieved by developing mobile games with a Data-Oriented Design as opposed to an
Object-Oriented Design.

1.1 Background

Object-oriented design (OOD) approaches have been a default approach when developing
games as Nystrom mentions in his book (Nystrom, 2014). The main idea of the approach is
centered on defining, producing and operating on objects. Every object has its state and
behavior that builds the functionality of the object (Mines, 2018).
Object Oriented Programming allows us to write code that is close to reality, thinking of
real objects that have their own properties and interact with other objects.

Data-oriented design (DOD) is a different way to approach program design and it is used in
game development (Fabian, 2018). DOD focuses on data and how it is transformed and used
so that the functionality and the data are separated, and they are no longer coupled to a
specific object (Llopis, 2009).

From previous research, there is no literature that makes a direct comparison between the
OOD and DOD approaches regarding their effect on the performance of the games. Several

1
 theoretical perspectives state that DOD is a better choice when developing games, for
example; Mike Acton (2014) describes DOD as the design that fits the hardware it runs on it,
Fabian (2018) ensures that designing the game the DOD way will support locality of
references and minimize fetching of unnecessary data and Mike Gieg (2019) encourages to
convert the game design to DOD whenever good performance is the goal, but still an
investigation is needed to collect quantitative data that shows convincing results.

In this thesis, an investigation about how the two approaches affect the game performance is
done, where two games are developed; the first one with an Object Oriented Design
approach using the traditional Unity 3D game engine, and the second one with Data
Oriented Design approach using Unity’s new Data oriented game engine DOTS.

To evaluate the game performance, the CPU usage and the memory usage is measured for the
two identical games.

1.2 Problem Statement

The chosen design approach and its principles affect the overall game performance. The
order of the operations and the way the data are structured affect the efficiency of the game
because they can cause irrelevant latency when accessing and retrieving data (Carvalho, 2002).
Fetching data from main memory takes more than 100 clock cycles where one cycle is more
than 50ns, while accessing the CPU cache Layer 1 takes almost 0.5ns (Cohen, 2016). Because
of the big time difference between accessing the main memory (50ns) and the CPU (0.5ns),
the average times to access data from main memory must be reduced by utilizing the CPU
cache the right way.
OOD and DOD have different ways of structuring data. Object-oriented programming
structures its data in objects which are instances of classes, every object has its own
properties and interacts with other objects.
Data-oriented programming does not have objects with properties, but instead it gathers the
similar properties from every object in one group, this way they become sequentially
organized in memory (see figure 1).

Figure 1: OOD and DOD way of defining data.

2
On the left, we have the OOD way of defining 3 objects of class Particle every object has x,
y, and color properties (attributes). On the right the DOD way has one class
ParticleManager that includes an array of all x, y, and color attributes’ values.

And in memory the two ways of structuring the data look significantly different.

Figure 2 illustrates how the properties of the three Particle objects are structured in memoryon
the other hand how gathering the same type properties in one group in the DOD way
structures the data sequentially.

Figure 2: OOD and DOD way of structuring data

The benefit of structuring the code in contiguous memory blocks is to write a more cache
friendly code that reduces the cache misses. Organizing data that are used at the same time
next to each other in main memory gives better exploitation of locality of references which
results in better performance (Nystrom, 2014). Shan, Shi, Feng, Mengyun and Wang (2018),
underline the importance of the CPU cache in increasing the efficiency of memory access.
When data is found in the CPU cache, the longer cycles to main memory are skipped and the
process of retrieving data is done much faster.

Object-oriented design allows us to think about objects as real entities, a human mind can
reason about how data would be used together and therefore be structured accordingly in
memory, but in fact compilers cannot infer and predict about how objects are designed and
will be used because they do not have the intelligence to do that yet especially when the objects
have a large number of attributes. This would explain why there is no compiler yet that can
interpret the Object-oriented code to a Data-oriented code.

OOD and DOD have different ways of defining and structuring data, however, how
significant performance differences there may be between developing a game with OOD
and DOD approaches are yet to be determined.

The problem of the study is that there have not been done documented studies that directly
compare mobile games development based on how the different ways of structuring the
data in the OOD and DOD approaches result in better CPU Usage and Memory Usage.

1.3 Purpose and research questions

The way data is structured in memory affects the overall performance of the game. The
OOD and DOD approaches have different ways and priorities to consider about while
coding. Consequently, to understand how these differences can have different effects on

3
 the game performance, it is necessary to conduct an experiment. Hence, the purpose of the
study is:

To investigate the performance differences between Data-oriented design (DOD) and Object-oriented design (OOD) approaches in
Mobile games.

With the study we aim to answer to two questions:

1. How does the CPU usage differ in the two approaches?

2. How does the memory usage differ in the two approaches?

1.4 Delimitations

The study limits the scope of the project by developing two games for mobile phones where
the focus will be on performance related issues, namely measuring the CPU and memory
usage. To avoid introducing variables that may affect the performance and the memory
capacity, the test cycle runs automatically with no user input required. This ensures an
identical cycle lifetime for each test cycle.

The time spent on developing the two games with the two different versions is not
measured, because the developers are more familiar with the Object-oriented programming
and cannot claim that Data-oriented programming takes longer time to develop.

1.5 Definitions

CPU Cache: The CPU Cache is a small but very fast memory located near the Central
Processor Unit (CPU), which executes the instructions of any program running on the
device. CPU Cache’s task is to hold data from frequently visited memory locations in orderto
reduce the number of cycles to the main memory every time that data is needed to be accessed.
Modern hardware use multi-level caches (L1,L2,..) where accessing the first level
/layer is the fastest (Carvalho, 2002).

Cache hit: When a program (an application) requests data, the CPU first looks for the data at
the CPU cache if it finds the requested data a cache hit occurs. A cache hit means that data
delivered the fastest way. (Nishry, 2015).

Cache miss: In oppose to cache hit, a cache miss is when the CPU can’t find the requested data
in the CPU cache and a longer journey to main memory is needed. (Nishry, 2015).

Locality of reference: the multilevel cache systems in modern CPUs provide for
exploitation of the locality of reference. As described in Encyclopedia of Parallel Computing
“The term locality of reference refers to the fact that there is usually some predictability in
the sequence of memory addresses accessed by a program during its execution” (Padua, 2011).
Restructuring the code can enhance the locality of reference so that a large number of data
accesses is done from the CPU cache and a small number is accessed from the main memory.

4
Multithreading: As defined by Techopedia: Multithreading is a type of execution model that
allows multiple threads to exist within the context of a process such that they execute
independently but share their process resources. Multithreading if programmed correctly,
ensures faster execution time because it utilizes the multicore processor the best way
(Techopedia, 2017).

1.6 Outline

The thesis is structured as follows: Chapter 2, methodology, gives an overview about the
methods chosen to conduct the study with as well as describes the game design. Chapter 3 is
the theoretical framework which gives an overview about pervious research and describes the
theory behind the study. Chapter 4 provides an overview and description of the empirical
data extracted from the study. Chapter 5, Analysis, answers to the research questions by
analyzing collected empirical data and the theoretical framework. Finally, chapter 6,
discussion and conclusions, provides a summary description of the study’s results,
furthermore, it concludes the study and gives suggestions for future work

5
Theoretical background

2 Theoretical background

The chapter presents the theoretical foundation for the study.

2.1 Previous research on OOD and DOD approaches

Carvalho (2002) discusses the potential gap between CPU and memory usage (see
figure 3). He encourages us to utilize the CPU cache the right way by understandingthe
memory hierarchy and memory access patterns to write a more cache friendlycode.

Nystrom (2014) underlines the importance of writing cache friendly code while game
developing and ensures that data and the way it is structured can affect the game
performance. Furthermore, he shows some code samples to explain the idea of
writing a cache friendly code. He does not mention about two different approaches of
designing games, but rather he calls them two different ways of coding (Nystrom,
2014).

Recently, Askarbekuly, Fedoseev, Mazzara and Uzbekova (2020) conducted a case

study of DOD and OOD paradigms on two different games developed for IOS
devices, the study investigates the performance, the maintainability and the
programming knowledge required to understand the games. Because the games are
not identical, they cannot claim which approach is better than the other.

In a different approach, in (Zhang, Han, Kunz, & Hansun, 2007) an optimization of

five different mobile games is done where OO and structured programming are
compared, this study results that OO would not be the perfect choice while mobile
game development.

From the readings, we recognize that there is a need to compare the two different
approaches by applying them on two identical mobile games to get good and
convincing results.

In our study, an Android mobile phone is used, and the CPU and Memory usage are
measured to understand to what degree the performance is affected by using the
different design approaches.

6
Theoretical background

Figure 3: CPU-Memory speed gap.

2.2 Link between research questions and theory

In the following sections, the theory providing the theoretical foundation for
answering the research questions is described.

To give a theoretical foundation to the two research questions, Object Oriented

Design and Data Oriented Design concepts are covered because it is necessary to
understand the two approaches and how they work to understand the study’s
results. In addition, to give a good answer to the first research question, the concept of
CPU usage is covered and what is meant by memory usage is described to answer the
second research question. A brief introduction to Unity3D and DOTS is also
mentioned at the end of this chapter.

2.3 Object Oriented Design (OOD)

Object oriented design is a programming paradigm centered around objects, that

have attributes that hold the objects’ data. Objects belong to data types known as
their classes, in other words, objects are instances of classes. The functionality of the
objects is built in methods, so objects interact with each other by calling their specific
methods.

Four key fundamental principles of Object-Oriented Programming are; Inheritance,

Abstraction, Encapsulation and Polymorphism. A brief definition of the concepts is
given below as described by Nakov and Kolev (2013) in the book” Fundamentals of
computer programming with C#”.

Inheritance: As the word means, inheritance is about the Parent-child relationship

between classes. For example, a class of Lion and Cheetah are children to a parent
class of Cat, because they are different biological types of the same animal. This
feature supports the reusability of the code, so that when a Lion class inherits from a
Cat class it gets all the attributes that a Cat has in addition it can add its own, this
means that we do not need to rewrite the code that describes a Lion animal and it’s

7
Theoretical background

behavior (methods) when creating the Lion class, but a Lion class inherits the Cat
class.

Abstraction: Abstraction refers to work with something you know how to use but
you don’t know how it works internally. For example, saving elements to a file
without knowing how the file sorts them (as an array, as a list etc.). This principle
helps with code reusability and flexibility because by writing code with abstract data
structures, programs that do a specific task, define an interface which can be reused by
several different subprograms to fulfill different tasks.

Encapsulation: Also known as “information hiding”. A class/object provides to

the user/another class the information (attributes or/and methods) that it needs to
know about or change in it. A class determines what should be known by markingan
attribute or method as public while coding, or what should not be known or
modified by marking it as private.

Polymorphism: It refers to overriding methods in the Children classes to change

their original behavior. For example, although a Lion and a Cheetah are children
classes of a Cat, but they have different ways of catching their prey, so the method
“catch_prey” can be different in the children's classes thanks to the use of
polymorphism. This is called dynamic binding, the same message sent to different
objects activates different methods decided by the objects at run time.

These features make Object-Oriented Design a good choice when programming

applications, games and even big systems where several teams work on the same
project because they support code reusability and modularity. Every object
represents itself by implementing its own behavior. Although same type objects
share the same methods, methods are implemented according to every object’s
behavior. By this way objects are independent from each other and they build
modularity which eases development (Pokkunuri, 1989). Flexibility is also supported by
Object Oriented Programming, for example when several child classes inherit from
a parent class and an attribute will be added to or deleted from all the derived classes,
modifying only the parent class will be enough.

Object Oriented Programming stores data in stack and heap memory. In the stack
method-related information is stored, such as the local variables, parameters and
returned addresses. In the heap application-related information is stored, namely the
Objects with all their attributes (Rahman, 2013).
Using the heap is flexible because the size allocated can be modified. The problem is,
the heap memory is allocated randomly, which means that objects instantiated after
each other can be placed in random places on the heap and this would be
inadequate for good exploitation of locality of reference. In (Janardhanan & Barrett,
2017) it was noted that poor allocation of memory leads to poor memory
management and ineffective usage of CPU power.

Another issue in OOD is when an object is fetched from the heap, all the attributes
belonging to that object are fetched even though when some of them would be used or
one of them, this would take lots of place on the CPU cache when the number of
objects is big and it would greatly affect the performance because there would

8
Theoretical background

not be enough space left on the cache line for other data so the number of cache
misses will increase and longer journeys to main memory will be required.

2.4 Data Oriented Design (DOD)

Motivated by the CPU-Memory speed gap problem (see figure 3), Data-oriented
Design was introduced. DOD is a programming paradigm with focus on data and
cache coherency (Wikipedia, 2020). It is especially used in video games development
where the delays caused by cache misses can affect the game performance
(Davidovic´, 2014).

When a class owns some data, to some extends, it limits the reusability of that data, and
when a function will be added to only a specific piece of data in that class, different
and sometimes unrelated data need to be added, and this results in many additional
data that are hard to untangle because the function will need to drag in them from
random places from the class (Fabian, 2018).

To avoid increasing the complexity of code, to ensure more reusability and to

improve performance, the main premise of DOD is centered around data and how it
is transformed, here data and functionality are separated and are not coupled to a
specific object (Collin, 2010). This feature is an oppose to the encapsulation feature of
OOD, where the goal is hiding the class data. In addition, the polymorphic calls from
the OO principles are avoided because there are no classes that inherits from other
classes and no objects that share same data.

Two major benefits of DOD, as described by Mike Acton (2014), are:

Efficient cache usage: DOD attempts to structure data that are used at the same
time in one group. For example: Instead of having a “Car” object with “Engine”
and “Horn” attributes coupled together, the attributes are separated because they
are rarely used at the same time so that when the “Engine” needs to be updated,
there is no need to fetch the “Horn” attribute. This would take less space on the
cache line and will therefor reduce the cache misses. In addition, this would makethe
CPU work less, because instead of searching for all the “Engine” attributes on
random addresses, it will find them grouped together in contiguous memory blocks.

Better Parallelization: Parallelization refers to the parallel computing where several

processors work simultaneously on different tasks. Structuring the data sequentially
results in better parallelization. It becomes easier to split work between multicore
processors and at the same time ensure that no two processors are writing on the
same cache-line. If the data is randomly allocated, the processors must keep things
consistent and cannot even guarantee that they are not working on the same
cache-line. Parallelization ensures faster run-time and improved performance.

9
Theoretical background

2.5 CPU Usage

CPU Usage refers to the term that describes how much work the processor is doing.
It varies depending on the tasks performed by the CPU (Easey, 2020). It is important
to monitor the CPU usage because it is a primary indicator to all applications’
performance including games. CPU Usage is measured in clock speeds indicated in
Hertz or cycles per second. If the CPU Usage is high, probably a performance issue will
arise, and the frame rate will decrease. Although modern devices have multicore
processors which can greatly deal with multitasking, where several processors work
simultaneously with different kind of tasks, abnormal CPU Usage situation can still
occur (Intel, 2020).

2.6 Memory Usage

Memory Usage means the amount of memory available on the system, and the
memory already in use by all the applications on the device (Wiki, 2020). Memory
utilization is the average utilization derived from the percent of available memory in
use at a given moment. Monitoring the memory usage helps to discover memory
leak. When memory utilization is increased, it may indicate to memory deallocating
problems which in turn can cause performance issues. High memory usage can over
time make the device unresponsive to its tasks (Engine, 2020).

2.7 The Game Engine Unity

Unity is a cross-platform game engine used to develop games with 3D objects. It is

implemented by Unity Technologies and had been used by more than 25 platforms.
Unity enables developing games in two different environments: Classical Unity3D that
has an Object-Oriented Design and DOTS that has a Data-Oriented Design.

2.7.1 Classical Unity 3D

Traditionally, Unity3D is centered around gameobjects which is a typical
ObjectOriented design concept. A Gameobject is a collection of different
components all deriving from the same Monoheaviour base class. For instance, in
classical Unity every GameObject has its own Update function as shown in Figure
4. This Update function is run every frame and updates the data on the gameobject.

Figure 4: Every GameObject has its own Update function.

GameObjects
A Gameobject is an object containing references to monobehaviour components.

10
Theoretical background

To operate on a component that belongs to a gameobject, the entire gameobject

must be fetched which means a lot of data that might not be needed along with it.

Monobehaviour components
A monobehaviour component contains data and logic coupled together.

The monobehaviour component is owned by the gameobject it belongs to and it is

impossible to say where in memory any given component resides, which makes it
prone to cache misses and makes it more difficult to utilize multithreading.

The Monobehaviour component typically has some variables containing data and an
update function which performs operations on this data each frame. In this example
(see table 1) the position data of the transform component is incremented by a
given vector multiplied by the speed data and the time between the current and
previous frame.
1 public class Cube: MonoBehaviour

2 { public float

3 speed; void

4 Update()

5 {

6 transform.position += Vector3.forward * Time.deltaTime * speed;

7 }

8 }

9
Table 1: An example of a Monobehaivor class

2.7.2 DOTS

Unity’s Data-Oriented Tech Stack (DOTS) is a combination of different

technologies enabling a Data-Oriented Design approach for creating games with the
main focus on performance.

It consists of three main elements, also referred to as the three pillars of DOTS;
The ECS, The C# Job System and The Burst Compiler.

The definitions of the different concepts are according to Unity’s official website
(Unity, DOTS, 2020)

11
Theoretical background

2.7.2.1 ECS

The Entity Component System (ECS) is an architectural pattern used in game

development, typically combined with data-oriented design approach. Instead of
GameObjects there are entities to split the data from functionality. (Unity, DOTS,
2020). Figure 5 shows how entities are updated by a system.

Figure 5: ECS architecture

Entities

Similar to a Gameobject in that it is a collection of components, but it is much lighter

as it is basically just an id used to identify components that belong to the same entity.

Components
A component contains data and only data. Unlike the classical Unity, where a
component is owned by a gameobject, a component in ECS is not owned by an
entity but it is independent and only loosely coupled to an entity by an id reference.
This allows components of the same type to be structured next to each other in
chunks in memory which in turn increases cache hit rate and allows for
multithreading by the C# Job system. Table 2 shows an example of declaring a
component.

Table 2: A Component “Cube” that only contains data.

1 public struct Cube

2 { public float

3 speed;

4 }

12
 Theoretical background

Systems

Contains logic and only logic. Systems governs the behavior of entities by operating
on component data.

In the following example, the “MoveSystem” iterates all entities that have
“Translation” and “Cube” components and updates the position data of the
Translation component by the speed data of the Cube component each frame.

In contrast to classical Unity where each component containes its own update
function, now there is a single function that updates all components. Table 3
shows an example of a System.

1 public class MoveSystem: SystemBase

2 {

3 protected override void On Update()

4
{
5
Entities
6

7 .WithName("MoveSystem")
.ForEach((ref Translationposition, ref Cube cubeData) =>
8
{
9 position.Value += math.forward * cubeData.speed *
Time.DeltaTime;
10

11 })

12 .ScheduleParallel();
}

}
Table 3: System in ECS

2.7.2.2 The C# Job System

As modern processors speed increases mainly due to more cores, it is important to

be able to utilize multithreading to get the most out of the processor and maximize
performance.

The problem is that it can be quite difficult and complex to do this in a safe way,
which is what
13
Theoretical background

The C# job system aims to solve. It manages the complexities of multithreading

and makes it easier to write thread safe and correct code.

2.7.2.3 The Burst Compiler

Unity uses something called Mono for scripting which can compile C# code to
different platforms to make it easy to create multi-platform games. The drawback of
this is that this is much slower compared to native code for specific platforms Burst
is a compiler, primarily designed to work with the C# Job system, that solves this
problem by translating from C# code to highly optimized native code to improve
performance.

14
Method and implementation

3 Method and implementation

The chapter provides an overview of the work process of the study. Further, the approach and design
of the study are described as well as the data collection and data analysis. The chapter ends with a
discussion about the validity and reliability of the study

3.1 Link between research questions and methods

A literature review has been done to collect information and state clear definitions
about the OOD and DOD approaches.

In order to determine which approach results in better game performance, an

experiment has been conducted. The experimental method in computer science is
adopted to collect quantitative data from real world implementations to be able to
test the veracity of theory (Omankwu, Chinecherem, Nwagu, Chikezie, & Inyiama,
2018).

In the study two identical games developed with OOD and DOD approaches built
the test ground for the experiment.

• To answer the first research question the CPU Usage of the developed
games is monitored and analyzed.
• To answer the second research question the Memory Usage of the developed
games is monitored and analyzed.

3.2 Hypothesis

Our hypothesis is:

A game built in Unity’s DOTS gives better CPU Usage and Memory Usage than
a game built in traditional Unity3D.

The study has this hypothesis because Data Oriented Design was implemented to
improve the speed gap between the memory and CPU. In addition, as stated by
Unity’s official website the new technology DOTS ensures better CPU utilization
because it supports multithreading by its architecture ECS.

3.3 Work Process

In the early stage of the study, a literature review for previous research about Object
Oriented Design and Data Oriented Design in the game development area was
initiated. The literature review phase helped the authors to formulate the research
questions as well as to identify the hypothesis.

Throughout the experiment phase, the study followed guidelines from the book
“Writing for Computer Science” (Zobel, 2014). According to the book, the first
thing to consider about when designing experiments in Computer Science is to
identify the baseline, that is the benchmarks against which the contribution would
be measured. The baseline in our experiment is implemented by the authors, it is

15
Method and implementation

the game built in the traditional Unity3D. The baseline is appropriate because
Unity3D has a pure Object-Oriented Design that would help to build the game
according to an Object-Oriented approach.

In the next step, the authors decided to look at the CPU Usage and Memory Usage
for the two games, as they are essential metrics to monitor when game development
in order to ensure good performance.

After developing the games in Unity’s two different development environment

(Unity3D and DOTS), the games were installed and played on Android mobile
phones to gather the suitable data. The collected data were analyzed by significance
analysis in form of T-test to ensure that the results are true and there is really a
significant difference between the two approaches. Finally, conclusions were drawn
upon the results and ideas for future work were suggested.

3.4 Game Design

The idea of the game is original and inspired by the state-of-art and theoretical
foundations that shows that DOD results in better CPU and Memory utilization.
Hence the goal of the game is:

To test how the CPU handles the increasing number of objects rotating on the
screen simultaneously.

To test how structuring the data in contiguous blocks in memory improves memory
utilization

To achieve the goal, the game consists of a single scene in which 3D cubes are
spawned. These cubes then move up and down while rotating around their own
axis. As the game starts, the “roundCounter” variable is set to 10 and a spawning
loop is initiated. With every iteration of the spawning loop, 5000 cubes are
instantiated in the scene and the roundCounter is decremented by 1. After a delay
of 50 frames the loop continues. The reason the delay is set in frames and not in
seconds is to ensure an equal number of frames being monitored for both versions
of the game.

Having the delay in seconds would mean fewer number of frames would be
monitored each second over the game's lifetime, due to increased processor load as
the number of cubes are increased. The iteration continues until the roundCounter
reaches zero and there is a total of 50 000 cubes in the scene at which time the game
terminates.

Figure 6 shows a design diagram of the game.

16
Method and implementation

Figure 6: Game design diagram

3.4.1 Classical Unity (OOD Version)

In the OOD version of the game, a gameobject in the scene with a “Spawner”
component is responsible for instantiating cube gameobjects in the scene, from a
prefab (template gameobject). The cube object has a move component attached that
moves the cube, and a rotate component, which rotates the cube.

Figure 7: Class diagram for the OOD Version game

17
Method and implementation

3.4.2 DOTS (DOD Version)

The DOD version of the game is very similar to the OOD version. In this version,
the “Spawner” object creates cubes as entities instead of gameobjects. The entities
are created from an archetype, which is basically a template for the entity, describing
what components it consists of, similar to the prefab in OOD version.

These cubes are then moved and rotated by the “MoveSystem” and the
“RoateSystem” systems respectively.

Figure 8: Class diagram for the DOD Version game

3.5 Data Collection

The data collection consists partly of studying literature and partly of collecting
quantitative data.

The theoretical information is collected from journal articles, peer-reviewed papers

and experienced programmers’ blogs using Google, Google Scholar, Primo and
Scopus search databases provided from Jönköping’s University’s library.

The empirical data from the experiment are real data collected from Unity’s profiler
window at game execution time. More precisely, data will be collected by taking the
mean of 20 frames for each time the number of cubes is increased by 5000.

The profiler window is a tool used by developers to profile different aspects of the
game’s performance.
For our study’s purpose the CPU Profiler and Memory Profiler are used. To collect
information about how much time is spent on tasks of different categories e.g.
rendering, scripts and animations, on every frame, the CPU Usage Profiler is used
(Unity, CPU Usage Profiler, 2019). The Memory profiler tool is used to capture,
inspect and compare memory snapshots by giving an overview of memory
allocations in order to reduce memory usage whenever needed in the game (Unity,
Memory Profiler, 2020).

3.6 Data Analysis

In order to determine if there is a significant difference between the OOD and

DOD approaches, the collected data is analyzed by significance analysis in the form
of T-test.

18
Method and implementation

The significance analysis refers to the use of statistical techniques to determine

whether a relationship really exists between two groups or is just due to random
chance (StatisticSolutions, 2020).

T-test is a technique to determine whether there is a significant difference between

two groups so that it is unlikely that the chance caused this difference
(Statiskhjälpen, 2020).

Because the study is investigating both the CPU Usage and Memory usage
differences between the games, two different T-tests are done to check how
significant is the differences between the collected data sets.

Hence the null hypothesis and the alternative hypothesis are:

• For the first T-test:

Ho: There is no difference between the game built in DOTS and the game built in
Unity3D regarding the CPU Usage.

H1: There is a difference between the game built in DOTS and the game built in
Unity3D regarding the CPU Usage.

• For the second T-test:

Ho: There is no difference between the game built in DOTS and the game built in
Unity3D regarding the Memory Usage.

H1: There is a difference between the game built in DOTS and the game built in
Unity3D regarding the Memory Usage.

Every T-test has a p-value, that is the probability that the results from the
experiments happened by chance. A low p-value indicates that the result is valid,
this means, the difference is actually significant between the two data sets and the
result could be generalized and the null hypothesis can be rejected because the
alternative hypothesis is more probable (Walpole, 2016).

The limit to consider a p-value as low varies, in this thesis thou, the limit is at p ≤
0.05 for the both T-tests, because it is a common p-value (Gunnarsson, 2003).

The calculation of the T-test is done on Excel to ensure accurate calculations as the
number of items in every data set is big.

3.7 Validity and reliability

A probable risk when writing code in two different paradigms is that the developer
is most likely more competent with one of them and will therefore write better and
more optimized code for that paradigm and the gap in code quality will likely grow
the more complex the application gets. To alleviate this issue and to ensure the

19
Method and implementation

validity of the results, the developers took an online course via Udemy to educate
themselves about the Data-Oriented Design in game development

Further, games can be very complex and messy collections of code with a multitude
of different things that might affect performance and in conducting an experiment
like this, it can be difficult to pinpoint the exact causes of disparities in performance,
To avoid this problem, the games for this experiment are designed to have as few
variables as possible. This ensures, to the extent possible, that any potential
disparities in performance measured, are not a reflection of the developer’s aptitude,
but rather, of the underlying system’s ability to process data.

By designing the games with only the bare minimum code necessary to meet the
target objectives, a fair comparison between the traditional Unity3d game engine
and Unity3d DOTS can be accomplished.

To ensure reliability, detailed information about the development environment, the

mobile phone model, processor size and memory capacity are documented. In
addition, the game design is explained with UML diagrams that shows how different
components are connected to each other. The project is shared as a GitHub
Repository, where a link is shared as an appendix, to ensure the experiment can be
reproducible under the same conditions.

20
Discussion and conclusions

4 Findings and analysis

This chapter introduces the findings of the study and answers the two research questions by an
accurate analysis of the results.

4.1 CPU

To answer the first research question” How does the CPU Usage differ in the two
approaches?”, the CPU Usage profiler is monitored every frame, Data is collected
by taking the mean of 20 frames for each time the number of cubes is incremented
by 5000.

4.1.1 Findings

Figure 9: Average time in milliseconds it takes to render one frame for DOD and
OOD version respectively.

As the graph shows in Figure 9, the difference in performance is increasing as the

number of objects grows. For example, when the number of cubes is 40000, it is
taking just more than 100ms to render a frame in the DOD game, while in the
OOD game it is taking more than 300ms to do the same operation.

4.1.2 Analysis

To better understand what is causing these differences an examination of where the

CPU spends the most time is done. In the case of DOD, as Figure 10 shows, most
time, 66.2 %, is spent waiting for the GPU to finish which suggests the performance
bottleneck lies in the GPU and not in the CPU.

The second most time, 20.9%, is spent in the update function, iterating all the cubes
in the scene and updating their data. This can be contrasted with the OOD version
where as much as 69.2% of the time is consumed by the update function, as shown

21
Discussion and conclusions

in Figure 11. Here, no time is spent waiting for the GPU, which is a clear indicator
of the CPU being the bottleneck.

WaitForGFX means the CPU is

waiting for the GPU to finish
Update is time spent handling
updating the cubes.
Camera.render is how much time
is spent rendering the cubes in
the scene.

Figure 10: Top time consumers in DOD game

Figure 11: Top consumers in OOD Game

Furthermore, Figure 12, highlights the difference between time spent on updating
the cube data for the two versions.

22
Discussion and conclusions

Figure 12: Time spent on updating cube data

Along with the graphs that shows the performance differences, and are in line with
the literature that suggests that DOD is especially good at handling large numbers
of object, a significance analysis in form of T-test is done in order to submit that
there is really a significance differences between the CPU Usage in the two
approaches.

Figure 13: First T-test, CPU Usage

Figure 13 shows, when applying the T-test, a p value at 0.00017 is yielded and it is
less than 0.05. In addition, if t Stat < -t Critical two-tail or t Stat > t Critical twotail,
the null hypothesis is rejected. Furthermore, the mean difference is significantly big.

P: 0.00017<0.05 and t-stat: -5,58<-2,26

23
Discussion and conclusions

it can therefore be concluded that there is a significant difference in CPU usage and
the Ho for the first T-test can be rejected because H1 is more probable to be true.

4.2 Memory

To answer the second research question” How does the Memory Usage differ in
the two approaches?”, the Memory profiler is monitored every frame. Data is
collected by taking the mean of 20 frames for each time the number of cubes is
incremented by 5000.

4.2.1 Findings

Figure 14: The total amount of memory in megabytes used by the application
for the DOD- and OOD version respectively.

When looking at Figure 14, any real memory issues could be observed. Both
versions stay below 200 MB in allocated memory which is well within reasonable
bounds even for older mobile phones.

4.2.2 Analysis
Figure 14 shows that OOD uses less memory at the start but has a relatively steep
trendline which suggests a significant increase in memory usage per cube in the
scene.
DOD on the other hand uses more memory at first but has a gentler trendline. The
amount of memory used for each new cube seems to be less than OOD. We see
this in figure 17. The reason for the large amount of memory used at the beginning
could possibly mean that it pre allocates memory. This is a bit unclear, however,
and should be investigated further.

24
 Discussion and conclusions

Another interesting observation can be found when breaking down memory usage
and looking only at the parts that are related to the cubes. In the case of DOD all
cube related data is stored sequentially as arrays (see figure 15). For OOD the
different parts of the cube, as shown in Figure 16, are stored randomly as objects.

Figure 15: Cube related memory Figure 16: Cube related memory
consumers DOD consumers OOD

By dividing the total amount of memory used by all cube components by the number
of cubes, a value of memory usage for each cube can be estimated.

As seen in Figure 17, OOD requires around five times as much memory for each
cube, approximately 1000 bytes, to DOD:s approximately 200 bytes.

Figure 17: Memory Usage per cube

Although there is no big difference in memory allocated for every game, a T-test is
conducted to submit whether the difference was due to chance or not.

25
Discussion and conclusions

Figure 18: Second T-test, Memory Usage

Figure 18 shows when applying the T-test, a p value at 0.25531 is yielded. In

addition, if t Stat < -t Critical two-tail or t Stat > t Critical two-tail, the null
hypothesis is rejected, which is not the case here. Furthermore, the mean difference
is not significantly big.

P: 0.25531>0.05 and t-stat: -0.68>-2,26

it can therefore be concluded that there is no significant difference in Memory usage

and the Ho for the second T-test is more probable to be true.

5 Discussion and conclusions

This chapter summarizes the results of the study. Further, it discusses the choice of method and the
findings of the study. It also describes the conclusions and recommendations of the study. Suggestions
for further research are given at the end of the chapter.

5.1 Discussion of method

The student thesis started with narrowing down the ideas that the authors had to
focus on one specific problem and to have one specific goal with the work.

At the beginning, an intensive research on related topics were done, where keywords
such as mobile games development, OOD and DOD were used. The relevant
articles or web sites were gathered in a shared document between the authors to
facilitate the searching process. Unfortunately not so many peer-reviewed papers
nor books were found about Data-oriented design in game development, but rather

26
Discussion and conclusions

the needed information was gathered from one book, experienced game developers’
blogs, and an online course from Udemy with the name “Unity’s DOTS
fundamentals” was useful to buy to get more familiar with coding the DOD way.

In conducting the experiment and designing the games, the main goal was to achieve
the objectives and see the performance differences in the CPU and Memory Usage
between both versions of the games. For this reason, the game design focused
mostly on having the minimum code/data needed to reduce the side causes that
may affect the performance and the validity of the results. To meet the requirements
of reliability, the code base for the games are available on GitHub and a link is
shared as an appendix.

In the data collection phase, one Android mobile phone was used to play the game
with and collect the data sets. More supporting results could be gathered if the
games were played on one more mobile phone that has a different processor size
and memory capacity to see how different processors could handle the increasing
number of data. The main reason was that it would be time consuming, and no
additional Android mobile phone was available.

The data analysis phase went as planned. The collected data were analyzed in an
accurate way with help of charts, graphs, and a significance analysis in form of Ttest.

5.2 Discussion of findings

As stated in section Purpose and research questions the purpose of the study is:

To investigate the performance differences between Data-oriented design (DOD) and Objectoriented
design (OOD) approaches in Mobile games.

Our approach to finding the best way to fulfill the purpose of the study, was to
conduct an experiment, where two identical games were developed according to
DOD and OOD approaches respectively and compare the CPU and Memory
performance. By doing this, we made some findings that we think will contribute
to the mobile game development field of research.

5.2.1 Discussion of first research question: “How does the CPU Usage differ in the

two approaches?”

Figure 10 and Figure 11show clear answer to the first research question. The CPU
Usage differ in the two approaches, different percentages of time are consumed by
the same activities (waiting for the GPU, updating the cube data and rendering the
cubes) in the two versions of the game. To pinpoint the exact reasons for this
discrepancy and explain why the OOD version requires so much more time to
update the data, which is the most time consumer activity, further experimentation
would be required. From the theory, however, we can summarize:

The ECS that has a Data-oriented design runs a single update function for all
components and iterates over all data. In the Classical Unity, that has an

27
 Discussion and conclusions

Objectoriented design the update function runs for every object. For example, in
our experiment, the OOD game runs 50000 update functions by the end of the
game, while the DOD runs one update function and iterates it 50000 times. In
addition, ECS has built-in functionality by default, therefore the Systems in ECS
will update entities faster than MonoBehaviours updating GameObjects in Classical
Unity.

The DOD requires less CPU cycles, as the CPU needs to look at only two memory
addresses: the function and the base address for the chank of data. In addition, it
utilizes the cache more effectively since data is stored in sequential memory blocks,
rather than randomly in the OOD way, and it fully utilizes the C# Job System and
enables multithreading and parallelization.

5.2.2 Discussion of second research question: “How does the Memory Usage differ in
the two approaches?”

No significance differences in total memory allocated for the both versions of

games are observed. This is not surprising as the games used for the experiment are
very basic with no large textures or other embellishing elements that typically take
up a lot of memory in games. However, the memory allocated for each cube in the
DOD version is five times less than the memory allocated for each cube in the
OOD version. When the number of cubes to be increased more, the OOD would
run into memory issues much earlier than the DOD version.

From theory, possible reasons to explain this big difference in memory allocated for
every cube in the both versions could be that DOTS use Structs of Arrays instead
of classes. Structs are value types and when dealing with Structs it is directly dealing
with the underlying data and a single space is allocated in memory to store the value,
while in Classes which are reference types, it is dealing with references, and spaces
for the value and its reference are allocated in memory. Structs are allocated either
on the stack or inline in contiguous memory blocks, while Classes are allocated
randomly on the heap. Therefore, allocation and deallocation of value types arrays
are cheaper and faster than reference types.

Further, the components used in Classical Unity inherit from a “Monobehaviour” class
which in turn inherit from another class. Each class in this inheritance chain has its own
data and logic attached to it which needs to be stored in memory. In Dots the components
are simple structs containing only the data that is needed for that component.

Figure 19 attempts to highlight this.

28
 Discussion and conclusions

Figure 19: Anatomy of a “Move” component.

5.3 Conclusions

Throughout this project, two games have been developed to compare the CPU and
Memory Usage and to investigate how they affect the game performance. The
results indicate that writing optimized code, with focus on memory-layout and data
structure, can improve the CPU Usage especially when the processor will perform
on large data.

However, it cannot be completely attributed that the improvement was solely due
to the underlying game design, DOD. The use of ECS architecture implemented in
DOTS established separation between data and logic and enabled implementation
of data-oriented principles, so a pure DOD solution was not achieved.

As a conclusion, DOTS that is built on Data-orientation could be the choice of

preference for the development of performance critical games. The more complex
the game gets with content variety, and different interactions, the more difficult it
is to perform correctly and avoid the code complexity. However, separating data
and logic, and structuring data that are used at the same time sequentially in
memory, to some extents, enhances the game performance.

This student thesis has a contribution in the researches about game development
where there is lack of comparative studies (OOD vs DOD) had been done.

5.4 Future work

As the games are not representative of a production level game, a suggestion to

continue the work could be to run the same experiment on more optimized versions

29
Discussion and conclusions

of more complete games with GUI and players to be able to make more reliable
conclusions about the difference in performance between OOD and DOD.

30
References

6 References
Askarbekuly, N., Fedoseev, K., Mazzara, M., & Uzbekova, E. (2020, 07). A Case Study on
Object-Oriented and Data-Oriented Design Paradigms in Game Development.
Retrieved from Research Gate:
https://www.researchgate.net/publication/342735514_A_Case_Study_on_ObjectOri
ented_and_Data-Oriented_Design_Paradigms_in_Game_Developmen

Carvalho, C. (2002). The gap between processor and memory speeds. (pp. 27-34). Braga
Portugal: IEEE International Conference on control and automation.

Cohen, W. (2016, 03 01). Reducing Memory Access Times with caches. Retrieved from Red
Hat: https://developers.redhat.com/blog/2016/03/01/reducing-memory-
accesstimes-with-cac

Collin, D. (2010, 11 05). Introduction to Data-Oriented Design. Retrieved from slideSahre:

https://www.slideshare.net/DICEStudio/introduction-to-data-oriented-design

Cough, C. (2020, 09 11). Portion of mobile gamers worldwide. Retrieved from Statista:
https://www.statista.com/statistics/748089/number-mobile-gamers-worldplatform/

CppCon. (2014, 09 30). CppCon 2014: Mike Acton "Data Oriented Design and C++".
Retrieved from YouTube: https://www.youtube.com/watch?v=rX0ItVEVjHc&t=3s

Davidovic´, D. (2014, May 28). What is Data-Oriented game engine? Retrieved from
envatotuts+: https://gamedevelopment.tutsplus.com/articles/what-is-data-
orientedgame-engine-design--cms-21052

Easey, C. (2020). Definition of CPU Usage. Retrieved from It still works:

https://itstillworks.com/definition-cpu-usage-5076431.html

Engine, M. (2020). Memory Utilization Monitor. Retrieved from Manage Engine OpManager:
https://www.manageengine.com/network-monitoring/memory-monitoring

Fabian, R. (2018). Data-Oriented Design. Fabian Richard.

Gunnarsson, R. (2003, 01 02). Översikt över signifikansanalys. Retrieved from Infovoice:
https://www.infovoice.se/fou/bok/10000015.shtml

Hammershoj, A., Sapuppo, A., & Tadayoni, R. (2010). Challenges for Mobile application
development. 2010 14th International Conference on Intelligence in Next Generation
Networks (pp. 1-8). Berlin-Germany: IEEE.

Inam, H., Malik, A. A., Sabahat, N., & Subhani, A. (2017). Improving the process for mobile
game development. 2017 International Conference on Communication Technologies
(ComTech) (pp. 45-49). Rawalpindi-Pakistan: IEEE.

Intel. (2020). How to Fix High CPU Usage. Retrieved from Intel: http://www.intel.com

31
Janardhanan, D., & Barrett, E. (2017). CPU Workload forecasting of machines in data centers
using LSTM recurrent neural networks and ARIMA models. The 12th International
Conference for Internet Technology and Secured Transactions (ICITST) (pp. 55-60).
Cambridge, UK: IEEE.

Joshi, R. (2007). Data-Oriented Architecture: A loosely coupled Real-Time SOA. RTi, 1-54
.
References

Llopis, N. (2009, December 04). Data-Oriented Design (Or why you may be shouting
yourself in the foot with OOP). Retrieved from Games
from within:
http://gamesfromwithin.com/data-oriented-design

Nishry, S. (2015, 07 02). Game Performance: Data-Oriented Programming. Retrieved from

AndroidDevelopers: https://android-
developers.googleblog.com/2015/07/gameperformance-data-oriented.html

Nystrom, R. (2014). Game programming patterns. Genever Benning.

Omankwu, Chinecherem, O., Nwagu, Chikezie, K., & Inyiama, H. (2018). Computer Science
Research Methodologies. International Journal of Computer Science and Information
Security (IJCSIS), 142-144.

Padua, D. (2011). Encyclopedia of parallel Computing. Boston: Spronger.

Rahman, M. (2013). In M. Rahman, Expert C# 5.0 with .NET 4.5 Framework (pp. 85-108).
Berkeley CA: Apress.

Statiskhjälpen. (2020). Statisk Hjälpen. Retrieved from t-test:

https://www.stathelp.se/sv/ttest_sv.html

StatisticSolutions. (2020). Significance. Retrieved from Statistic Solutions:

https://www.statisticssolutions.com/directory-of-statistical-analyses-significance

Techopedia. (2017, 07 20). Multithreading. Retrieved from Techopedia:

https://www.techopedia.com/definition/24297/multithreading-
computerarchitecture

Unity. (2020). DOTS. Retrieved from Unity: http://www.unity.com/dots

Unity. (2020). Unity. Retrieved from Unity: https://unity.com

Unity-ANZSEA. (2019, 06 24). Converting your game to DOTS-Mike Gieg. Retrieved from
YouTube: https://www.youtube.com/watch?v=Gs19-JMvyxc

Walpole, R. E. (2016). Probability and statistics for engineers and scientists. Upper Saddle
River : Pearsn.

Wiki, A. (2020). Memory usage. Retrieved from Lumina: wiki.lumina.com

Wikipedia. (2020, 12 19). Data Oriented Design. Retrieved from Wikipedia:

https://en.wikipedia.org/wiki/Data-oriented_design
Zhang, W., Han, D., Kunz, T., & Hansun, M. K. (2007). Mobile game development:
ObjectOrientation or not. 31st Annual International Computer Software and
Applications Conference. Beijing: IEEE.

Zobel, J. (2014). Experimentation. In J. Zobel, Writing for Computer Scienece Third edition
(pp. 197-215). London: Springer.

Search terms

7 Appendices
• Appendix 1: Mobile phone specification.
Motorola MOTO G8 POWER

Chipset Qualcomm SDM665 Snapdragon 665 (11 nm)

CPU Octa-core (4x2.0 GHz Kryo 260 Gold & 4x1.8 GHz Kryo 260 Silver)

GPU Adreno 610

Card slot microSDXC (uses shared SIM slot)

Internal 64GB 4GB RAM

eMMC 5.1

• Appendix 2: The GitHub Repository link for the code of the OOD game.
https://github.com/bjerra/Unity-Classic-CubeTest

• Appendix 3: The GitHub Repository link for the code of the DOD game.
https://github.com/bjerra/Unity-DOTS-CubeTest

33
Postadress: Besöksadress: Telefon:
Box 1026 Gjuterigatan 5 036-10 10 00 (vx)
551 11 Jönköping
Postadress: Besöksadress: Telefon:
Box 1026 Gjuterigatan 5 036-10 10 00 (vx)
551 11 Jönköping