Game developer experience
A cognitive task analysis with different game engines
Micaela Gustafsson and Rasmus Flom´en
18 May 2020
Faculty of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona Sweden
This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the bachelor’s degree in software engineering.
The thesis is equivalent to 10 weeks of full-time studies.
Contact Information:
Authors:
Micaela Gustafsson
Email: micaela.gustafsson.90@gmail.com Rasmus Flom´en
Email: rasmusflomen@live.se
University Advisor:
Fabian Fagerholm DIPT
Faculty of Computing
Blekinge Institute of Technology SE-371 79 Karlskrona Sweden
Internet : www.bth.se
Phone : +46 455 38 50 00
Fax : +46 455 38 50 57
Abstract
Context: Today there are a lot of different kinds of game engines to choose from, but is one of these engines more suitable for a developer with a beginners’ experience in game development?
Objective: This is something we explore in order to help teachers choose a suitable en- gine for teaching game development to beginners. In this study, two teams of two persons each compare two of these engines, Godot and Unity.
Method: We conducted a study, consisting of six iterations, to observe the development of a prototype game using the two engines. We collected data during the development of the game using a think-aloud protocol and a questionnaire, and after the development using a questionnaire that included the SUS scale for assessing the overall usability of the game engines.
Results: The Godot engine have been focused on completing their documentation and the documentation is somewhat directed to more experienced developers. In comparison the Unity engine got more solutions outside of the documentation and also got their own special guides towards beginners.
Although Godot engine got a more simpler GUI which will be easier at first but as the tasks became more difficult this became more of a disadvantage and some solutions were not found easily among the documentation. In comparison the Unity engine got more menus and can seem a lot to a beginner but became to be more helpful the harder the tasks became and even though most solutions were not found among the documentation, there were enough information from other sources to solve all problems with an easy search.
Neither of the engines provided with a lot of helpful information within the tool, although the Godot engine had some cases where the tool would let the developers know a certain component was needed.
Conclusion: Our main conclusion is that Godot is a good entry point into game develop- ment but as the tasks gets more difficult students would need the teacher’s help in order to solve the tasks as easy as with Unity. In contrast, Unity starts more difficult but as tasks gets more difficult Unity have more solutions online, which makes it more suitable if students are to develop on their own.
This study is rather small with only four participants and this limits the results, for future studies it would be best to have more participants.
Keywords
Cognitive task analysis, game developer experience, Godot, Unity, game engine, usability
Contents
1 Introduction 6
1.1 Motivation . . . 6
2 Background 6 2.1 Definitions . . . 7
2.1.1 Open source software . . . 7
2.1.2 Propriety software . . . 7
2.1.3 Game engine . . . 7
2.1.4 Integrated Development Environment . . . 7
2.1.5 Usability . . . 8
2.1.6 Graphical user interface . . . 8
2.1.7 Grid . . . 8
2.1.8 Official software documentation . . . 8
2.1.9 Operating System (OS) . . . 8
2.1.10 Application Programming Interface (API) . . . 8
2.1.11 Bfxr sound library . . . 9
2.1.12 Third party sources . . . 9
2.2 Engine components description . . . 9
2.2.1 Game objects . . . 9
2.2.2 Script . . . 9
2.2.3 Tilemap . . . 9
2.2.4 StaticBody2D . . . 9
2.2.5 RayCast2D . . . 10
2.2.6 Rigidbody . . . 10
2.2.7 OnCollisionEnter2D . . . 10
2.2.8 OGG Vorbis format (.ogg) . . . 10
2.3 The engines . . . 10
2.3.1 Godot . . . 10
2.3.2 Unity . . . 11
2.4 The game . . . 12
2.5 Related work . . . 13
3 Research Method 14 3.1 The Research Questions . . . 14
3.2 The study . . . 15
3.3 Development platform and hardware . . . 15
3.4 The participants . . . 16
3.5 The methods . . . 16
3.5.1 Time taking . . . 16
3.5.2 Think-aloud testing . . . 16
3.5.3 Iteration questionnaire . . . 16
3.5.4 End questionnaire . . . 17
4 Results 17
4.1 First iteration - Environment setup . . . 17
4.1.1 Godot . . . 17
4.1.2 Unity . . . 17
4.1.3 Comparison . . . 18
4.2 Second iteration - Game skeleton . . . 18
4.2.1 Godot . . . 18
4.2.2 Unity . . . 19
4.2.3 Comparison . . . 20
4.3 Third iteration - Player movement . . . 21
4.3.1 Godot . . . 21
4.3.2 Unity . . . 22
4.3.3 Comparison . . . 24
4.4 Fourth iteration - Physics and collisions . . . 24
4.4.1 Godot . . . 24
4.4.2 Unity . . . 26
4.4.3 Comparison . . . 27
4.5 Fifth iteration - Interaction . . . 28
4.5.1 Godot . . . 28
4.5.2 Unity . . . 29
4.5.3 Comparison . . . 30
4.6 Sixth iteration - Sound effects . . . 30
4.6.1 Godot . . . 31
4.6.2 Unity . . . 32
4.6.3 Comparison . . . 33
4.7 Results of perceived difficulty . . . 33
5 Discussion 34 5.1 Advantage and disadvantages between Godot and Unity . . . 34
5.1.1 Summary . . . 35
5.2 Difference in amount of helpful information about game objects and hints inside the Godot and Unity tools . . . 35
5.2.1 Godot . . . 35
5.2.2 Unity . . . 35
5.2.3 Summary . . . 35
5.3 Available source materials for Godot and Unity . . . 36
5.3.1 Godot . . . 36
5.3.2 Unity . . . 36
5.3.3 Summary . . . 36
5.4 Perceived difficulty . . . 36
5.4.1 Time required . . . 37
5.4.2 Usability . . . 37
5.5 Validity threats & Future work . . . 38
6 Conclusion 40
References 41
Appendix A Iteration-schedule 44
Appendix B Iteration Questionnaire 45
Appendix C SUS Questionnaire 48
Appendix D SUS calculation instructions 51
Appendix E End Questionnaire 52
1 Introduction
How does selecting a game engine affect the game developer’s experience?
This is the question we will try to answer in this study by having two teams implement the same game design in two different game engines, where we will represent one of the teams and two other students will represent the other team. We have decided to compare the Godot and Unity engines for this study with the use of a cognitive task analysis [1].
The participants will have no experience using their assigned game engine but they will have experience in software development, the reason for this is to see how easy it is for a non-experienced game developer to understand and use the engine. To determine this we will look at how intuitive the IDEs are to use and the amount of available documentation there are for the two different engines and if the information is official or none-official documentation.
1.1 Motivation
This study will try to determine if one of the two game engines used in this study are more suitable for someone with a beginners’ experience in game development, even though they might have experience in other types of software development. This can be valuable in a game teaching environment, where the game teacher can choose the engine that is easier to understand for students that are new to game development. There are more aspects the game teacher may want to focus on, but we will focus on studying how easy it is to intro- duce students to game development. It is also important for the students that are new to game development that their teacher is able to choose an appropriate game engine since it will affect the students’ general experience of game development and their learning curve.
As we do not have the resources to test this with real teachers and students, our study will be performed by having the students learn the engines on their own, this may give an alternative result but will still give the gaming teachers a good foundation to work from.
The main challenge will be to determine if the personal experience is due to pre-knowledge of programming/game development or the game engine itself. The reason for this is that all participants in this study has different programming experience levels as we all have different backgrounds when it comes to software development and game development.
To determine if any of the engines are more suitable for beginners, we will consider the usability of the engines.
2 Background
It has been argued that ”efforts to find concrete usability flaws in model-driven tools are still relatively rare” [2]. Since open source projects often rely on volunteers and dona- tions, they have limited resources, this results in that the open source projects is even less tested than other projects. Studies have also found that usability experts are not really interested in open source software and is hardly welcome by other developers to partic- ipate [3]. Same study have also found that usability is harder to specify and find issues with than regular technical problems. This becomes extra hard to find as most developers
in open source software are not experts either. The study also shows that open source software contain more options for the users to adjust the program to their liking, this is shown to be good for expert users but novice users do not care for it and usually choose to use the default settings.
These observations becomes interesting to us as the Godot engine is open source and Unity is not, so it may be something to have in mind when considering the usability of the two engines. Another thing to have in mind when comparing the two engines is that the Godot engine is a relative new engine which was released in 2014 whereas Unity was released almost ten years earlier, in 2005. This may impact the result in the benefit of the Unity engine, as they have had more time to tweak the core functionality and more time to improve the usability. The Godot engine on the other hand may not have gotten the time to improve the usability yet but instead they may have focused on the core functionality.
2.1 Definitions
In order to fully understand our study we will define some of the terms we are using.
2.1.1 Open source software
It has been argued that the term open-source software (OSS), essentially describes soft- ware licenses that explicitly give users the rights to use the functionalities of the software and are permitted to view the source code of the programs as well as change, debug and develop the source code even further [4]. The changes made to the source code can later on be joint with the original and then published.
2.1.2 Propriety software
Propriety software has a owner which owns the rights for the software and decides if and how it can be used. Software of this type generally has its source code hidden from view.
The source code can not legally be used to develop software by independent programmers unless they are given permission by the unitary rights holder [5].
2.1.3 Game engine
The game engine is a tool created to allow developers focus on the details of their game in order to make them unique. The engine is a software which performs game related tasks such as collision detection between objects, rendering, physics and input and in order to simplify these tasks the game engines have reusable components the developer can use to create their game world. A game engine is defined as a middleware, as it is the software between the hardware and the game itself [6]. During this study we will sometimes use the shorter term engine instead of game engine.
2.1.4 Integrated Development Environment
Integrated development environment (IDE/IDEs) is a software that exist to help a com- puter programmer develop software. The software generally contains the following parts,
source code editor, a compiler and/or interpreter, debuggers and build automation tools.
It not uncommon for IDEs have version control system or/and tools for building graphical user interface (GUI) [7]. During this study we will sometimes use the term engine as a description of the game engine and the IDE as one unit.
2.1.5 Usability
There have been many different forms of the definition of usability. But in one study it is argued that the key to good usability are effectiveness, learnability, flexibility and attitude [8]. Where effectiveness is how well the system meets the required tasks for a specified type of users, learnability is how easy the system is to learn, flexibility is how well the system is able to do the same task but in a different way and attitude is how satisfied the user is with the system so it will likely to use the system again.
2.1.6 Graphical user interface
Graphical user interface (GUI) is an event-driven interface that allows users to interact with software through graphical icons and layouts instead of a text based interface that allowed interactions through user-written commands [9].
2.1.7 Grid
A pattern or structure made from horizontal and vertical lines crossing each other to form squares [10]. The grid is used in the game engines as guidelines to position the different game objects.
Figure 1: An example on how a grid can look.
2.1.8 Official software documentation
Official software documentation or software product development, documentation is the documents and information that describes the software to its users. The documentation generally consists of of the products technical manuals and user instructions.
2.1.9 Operating System (OS)
An operating system is the main software of the computer and is the main communication with the computer’s hardware.
2.1.10 Application Programming Interface (API)
API is the definition on how a component can be called, in other words, what kind of functions a component supports.
2.1.11 Bfxr sound library
This is an open source sound library, which contains different kinds of sound effects made especially for computer games [11].
2.1.12 Third party sources
In this study we will define a third party source as any website that does not contain the official documentation of the engine, in this study this will mostly be YouTube or different forums.
2.2 Engine components description
To further increase the understanding of our study we will describe the different compo- nents that was used within the engines.
2.2.1 Game objects
Game objects are what the Unity engine uses to create the actual game environment, this can anything from the player object to the camera which is the area that is shown to the end user [12]. The corresponding term used in the Godot engine is nodes, although the main difference is that all components used in Godot are called nodes even those that are not apart of the actual game environment [13].
2.2.2 Script
A script component is a piece of code that that is used to add functions to a game object.
One example of this is player movement with the arrow keys, where the script component contains the code that tells the computer to listen after key strokes and preforms an action depending on which key the player pressed. For example player presses the left arrow key this will make the player move to the left (assuming that the code in the script tells the computer to move the player object left when the left arrow key is pressed).
2.2.3 Tilemap
Tilemap is a grid component used within the Unity engine that stores and handles tile assets. This is used to create 2D levels (maps). The Tilemap transfers the required tile information to other related components such as Tilemap Renderer and Tilemap Collider 2D [14].
2.2.4 StaticBody2D
StaticBody2D is a physics component that is applied to a body that is not intended to move. The StaticBody2D component is used for objects such as walls or platforms [15].
This component is only used within the Godot engine, the corresponding component within the Unity engine is the Box Collider 2D [16] or Tilemap Collider 2D for tilemaps [17].
2.2.5 RayCast2D
This can be described as a virtual laser that shots from one point to another and will report back if there are any collisions in the line of the laser [18]. This can be used to check if a player object is on the floor.
2.2.6 Rigidbody
Rigidbody controls an objects position through physics simulation. By adding the Rigid- body component to an object it will put its motion under the control of Unity’s physics engine. This means that without adding any code the object will be pulled down by grav- ity and it will also react with other objects as long as it has a collider component present.
The Rigidbody component also has a scripting API that allows the developer to apply forces to the object to control how the object moves [19], an example of this is when a player jumps. How the jump looks is based on which forces are applied and which angles they are applied from. The Rigidbody component is present in both engines with the same functionality.
2.2.7 OnCollisionEnter2D
OnCollisionEnter2D is a component that sends information when an incoming object, which has a collider component, makes contact with this object’s collider [20]. This com- ponent can be used to determine the identity of the incoming object. The corresponding component within the Godot engine is the Area2D node [21].
2.2.8 OGG Vorbis format (.ogg)
OGG Vorbis format (.ogg) is an general-purpose compressed audio format which is used within the Godot engine. Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty- free created and maintained by xiph.org.
2.3 The engines
As mentioned before we will compare two engines: Godot and Unity. We chose these engines as of a request from our university advisor, Fabian Fagerholm, which wanted to know more about the difference in the learning curve between an open source engine and an proprietary engine. Godot was released in 2014 and is an open source software. Unity was released in 2005 and is in contrary to Godot, a proprietary software.
We will provide with some more information about these two engines below.
2.3.1 Godot
Godot is a small open source engine with a maximum download size of 68 MB, you do not need to install the engine, it can be run as soon as the download is finished but you have install modules when exporting your game.
The Godot engine supports multiple operating systems, according to the official site of Godot [22], both for developing and release and can be downloaded either from their offi- cial site, Steam or itch.io. Godot also have support for the most common mobile operating
Godot
Graphic type 2D & 3D
Languages GDScript, C#, C++, Python, Nim, D and
others
Built-in script-editor Yes
Architecture Node based
Supported OS Windows, Linux, macOS, FreeBSD,
OpenBSD & Haiku
OS support for desktop games Windows, macOS, Linux, FreeBSD, OpenBSD, Haiku & UWP
OS support for mobile games iOS & Android
Web game support HTML5 & WebAssembly
Video game console support No
Release date 2014
Release type Open source
Notable games No
Table 1: Information gathered from Wikipedia and from Godot official site.
systems and it got website support, but there is no support for video game consoles.
Godot has its own scripting language GDScript but supports many other common lan- guages such as C# and C++. Godot architecture is based solely on nodes, a node can be any type of component for example in Unity you have assets which represents imported files, in Godot these are called sprite nodes for pictures and AudioStreamPlayer node for sounds. The sound support on Godot is very limited and mainly only supports their own .ogg sound format. In order to connect nodes to each other the engine uses the term child node, in where you put one node as a child of another node. The order of these nodes is crucial when it comes to movement of the object combined with collisions with the ground, as the node you want to add the movement on needs to be the parent of the rigidbody node, which enables collisions.
2.3.2 Unity
Unity is a proprietary software and is developed by Unity Technologies, the installation size is dependant on how much platform support you want to have but the core function- ality is up to 7 GB big. In addition to the engine you also have to install the latest version of Visual Studio as Unity does not have its own editor, for this project we have Visual Studio 2019 v.16.1.3 installed which have a size of 3 GB, this size will vary depending on how much functionality support you want, for example if you want support to develop android mobile games.
Unity engine supports the most common OS for developing and releasing although it only supports the 64-bit of Windows for developing. Compared to Godot, Unity only supports Ubuntu and CentOS among the Linux operating systems for developing, the Unity en- gines does however support all Linux operating systems for releasing a desktop game.
Unity also supports the most common mobile operating systems and has website support but compared to Godot, Unity also got support for the newest video game consoles.
Unity
Graphic type 2D & 3D
Languages C#
Built-in script-editor No, uses the latest version of Visual Studio
Architecture Components, game objects & assets
Supported OS Windows (64), macOS, Ubuntu & CentOS
OS support for desktop games Windows, Linux, macOS, & UWP OS support for mobile games Android, iOS & tvOS
Web game support WebGL
Video game console support PS4, Xbox One, Nintendo Switch & Google Stadia
Release date 2005
Release type Proprietary release
Notable games Assassin’s Creed Identity, Hearthstone
Heroes of Warcraft, Temple Run Trilogy Table 2: Information gathered from Wikipedia and from Unity official site: Unity games, platform support, system requirements.
In comparison to Godot, Unity only supports one language: C# and does not have a built- in script-editor but have to rely on Visual Studio for script-editing. The architecture of the Unity engine is based on different kinds of components, game objects and assets. The game objects are the main structure of the game, each game object can have multiple components, the components have multiple uses for example it can be sounds or sprites which are based off the imported assets, the assets are files imported into the engine and can be either an image or a sound. During the study we found no restrictions on either the image or sound formats, although this is not something we have explored fully.
When comparing the two engines it is easy to understand that the Unity engine have had more time to improve and expand its uses, as it was released much earlier than Godot and also have video game console support, which Godot may not have had time to explore yet and have probably not been their focus yet. This observation can also be made when looking at notable games, as Unity have been available much longer there have been de- veloped more games for it compared to Godot. When looking at the architecture it would seem that Godot have based it off the Linux architecture with nodes, this is probably for simplicity, whereas Unity uses different kinds of components and objects.
2.4 The game
The main challenge will be to have the focus stay on the study and not on the game itself.
To reduce the risk of having a switch in focus, the game will be as simple as possible in 2D and with minimal enhanced graphics and no graphic effects.
As we wanted the game to be as simple as possible we based the game design on the first game 2D that came to mind, the mario game. Where we have different platforms to jump onto, with coins to collect on each platform and a finish flag in order to end the game.
The graphical pictures will be 64x64 pixels with simple colours, for example the Unity
Comparison
Engine Unity Godot
Graphic type 2D & 3D 2D & 3D
Languages C# C#, C++, Python, Nim, D
and others
Built-in script-editor No Yes
Architecture Object & component based Node based
Supported OS Windows (64), macOS,
Ubuntu & CentOS
Windows, macOS, Linux, FreeBSD, OpenBSD &
Haiku OS support for desktop
games
Yes Yes
OS support for mobile games
Yes Yes
Web game support Yes Yes
Video game console support Yes No
Release date 2005 2014
Release type Proprietary Open source
Notable games Yes No
Table 3: Comparison information, supported operating systems and functionalities be- tween Unity and Godot.
team did the coins as yellow boxes as, seen in figure 2(c), whereas the Godot engine used simple coin resemblance pictures, seen in figure 2(b). The reason for the differences in the final designs are because of different perceptions of the original design between the two teams.
2.5 Related work
Numerous studies have been done on different computer aided software environments (CASE) and L. Fowler et al. argue that learnability and usability is of utmost importance when it comes to CASE-tools and to conduct investigations of issues within these areas
”will help both students in education and professionals within industry” [23]. This is mainly because most CASE-tools have a steep learning curve and are complex and diffi- cult.
Another study have been performed by S¸. Mercan and P. Onay Durdu about the usability of the Unity game engine [24]. Where they found no major problems with the engine but there were a few minor problems the novice users faced. The main issues the novice users faced were firstly, that they thought the GUI was ”too crowded and complicated”
and secondly, that the error messages provided by Unity was ”long and complex”. They conducted their study with a total of seven participants with different experience levels, they were either experienced and novice users, the experienced users had more than two years of experience with the Unity game engine.
When they calculated on the usability of the engine both groups of users rated the engine
(a) Initial design.
(Image composed by the authors based on graphi- cal elements from the game Super Mario Bros. by Nintendo).
(b) Godot final design. (c) Unity final design.
Figure 2: State diagrams client-server
to be above average in usability, according to the results they got from their questionnaire.
No study have been found about the Godot engine, this may be because it is a relatively new game engine.
3 Research Method
3.1 The Research Questions
There are three questions we will address in this study:
RQ1: What kind of advantages and disadvantages are there between the different game engines, when considering non-experienced game developers?
Reason: We want to know if any engine is more suitable for non-experienced game de- velopers.
RQ2: What is the difference between the two engines when it comes to the amount of helpful information about the different objects used in the engine or the amount of useful hints during the development?
Reason: This question will help us answer the first question, if the tool has more built-in help it would indicate it would be more suited for non-experienced game developers.
RQ3: What are the available source materials for the different engines (easy to understand material, material context, amount, etc.)?
Reason: This is also an extension to the first question, if there are a lot of materials and it is easy to understand, it will be an indication that the engine would be more suited for non-experienced game developers. The participants used Google-searching in order to find the different materials and all searches were done in English.
3.2 The study
After we studied the process of a cognitive walkthrough [25][26] we formed an iteration- schedule which contained the tasks that would be completed in order to complete this study. The two teams will follow this schedule and each iteration will be completed at a specific site and time where both teams will meet up. When the teams meet they will first overview and discuss the iteration and decide how many (if not all) sub-tasks that will be completed at that time.
After the discussion of the iteration, the two teams will start at the same time with the first task, at the same time we start a timer in order to measure the time it takes for the teams to complete the iteration. One member of each team will take notes and the other member will be the game developer, this will be altered for each iteration. The one taking notes is the one responsible in trying to get information from the developer in how they are thinking when they are completing the iteration, as that person will be taking a step back, observe and ask the developer questions to get the necessary information.
The information will include notes on where the solutions were found to solve any specific problem of the iteration, specifically if the solutions was from any official or non-official sources. After each iteration both teams will answer questions from our questionnaire.
The participants will also have a quick discussion after the iteration about how it went in general, if it was any big obstacles that were particular difficult.
At the end of the study each participant will answer a short official questionnaire called SUS, which is used to determine usability, as well as another questionnaire which is a modified version of the one answered after each iteration but is used to get the overall experience of the engines.
3.3 Development platform and hardware
The participants in this study used their own computers during the iterations. This means that the participants did not have equal hardware specifications. We did not see the need to make sure that all participants had the same hardware specifications because if there would have been a major problem with the compilation time we are to assume the partic- ipants would have taken notes on that and we would have taken that into account when over-viewing the times. During normal conditions we would not expect the time differ- ence to be greater than five seconds for the compilation and as we are not comparing the times with such small marginals it is not a difference we care for. All participants used Windows 10 during the study, this was not a requirement.
3.4 The participants
The four participants were: Micaela Gustafsson, Rasmus Flom´en, Hadi AL Halbouni and Frank Hvidbjerg Hansen. All of the participants are doing their final year on the program:
Software Engineering, the program does not introduce the students to any game engines.
Frank however have some experience from Unity, so we made the decision to put him in the Godot team in order to make the teams as even as possible.
Frank and Hadi were working on a related thesis, which enabled us to conduct the game development as a joint project. To simplify the study we decided so none of the teams had to create the game in more than one engine, which is why we decided to only compare two engines.
3.5 The methods
We will use four different methods in order to retrieve information for this study, these methods have been considered carefully with the help of the cognitive task analysis guide formed by B. Crandall et. al [27].
3.5.1 Time taking
The two teams will start working on the iteration at the same time, at the start of the iteration a timer will start as the two teams begin to solve the first task. Notes will be taken of the time when the first team completes the iteration and will stop when the last team is done. This will give an indicator if the iteration was easier or harder than any other iteration and also if either team had a more difficult time to complete the iteration.
3.5.2 Think-aloud testing
We will use the think-aloud testing method [28][29] during the time the developer is work- ing on the iteration. During that time the team member who is taking notes is in charge of making sure the developer is talking about what he/she is doing while completing the tasks. The team member will do so by asking questions to the developer such as, ”Why did you do that?” and ”What made you click that button?”.
The notes taken will then later on be reviewed and rewritten into a summary of how the experience was during the iteration.
3.5.3 Iteration questionnaire
At the end of the iteration all participants will answer questions from our questionnaire separately. These questions will give answers to if there were anything particular that made the iteration possibly hard to complete and if it was the UI of the engine that made it harder to complete. We also will look at the sources the teams found while completing the iteration, if it was official or non-official sources and also if they found a lot of information to solve the issue or not.
In order to tell how the learning curve of the engine goes, the teams will also answer the question: ”Was this iteration was more or less difficult than the last iteration” where there will a force of selection between more or less. The teams will also answer to if they used any new technology or functions.
3.5.4 End questionnaire
At the end of the study all team members will answer questions according to SUS [30], which is a widely used questionnaire when evaluating the usability of a software. It is highly reliable, it is used to give a quick response of how good the usability is. The SUS is calculated through some specific instructions, and the results reminds of percentage but is a score which is translated into a grade between A to F.
They will also answer a second questionnaire which is very similar to the questionnaire taken after each iteration, but is more focused on the overall experience of the engine.
4 Results
4.1 First iteration - Environment setup
The first iteration steps included the following tasks:
1. Install and make needed configurations in order to start the engine.
2. Create an executable file and run the empty game.
No questionnaire was answered for this iteration as there were little to no interactions with the GUI of the engine. All participants was installing their designated engine, the time to complete this iteration for each team is the calculated average for each team.
4.1.1 Godot
Time to complete: 52 minutes
Seemed easy and straightforward for the team to complete apart from how to export and build the game, there were two options, the one called Windows Universal confused the users and was not used, the users chose to use Windows Desktop instead which made the executable without any hazards. Information about the executable needed to be googled but no result was found on how to export for Windows according to the users. The team then tried the other option which did not need any searching. The engine did not need any real installation, you only got a zip-file which contained the executable file that started the engine, although a plugin later on needed to be installed in order to create the executable file of the game. There was no first layout to the project so the first build did not show anything, but it did execute.
4.1.2 Unity
Time to complete: 47.5 minutes
The team had to take several steps before they could download and use the game engine:
create an account to their website and wait for a verification email, they also had to create an account or login to Github. When downloading and installing the engine they were prompted to install Visual Studio 2019. They got an activation key in an email, which they had to add in the Unity Hub, which is the Unity manager, before creating the project.
Creating the project was easy but could have been slightly more forward according to the team, this was because of the layout of the Unity Hub. Exporting the project was slightly
confusing as in Unity it does not say export instead you use the option to build and run the project, this will create an executable file and then start the game. The game started and had a blue background as default, was no button or way to exit the screen other than alt+f4, through the task manager or through tabbing out.
4.1.3 Comparison
Godot seemed more easy and straightforward than Unity, with less installations and pre- installation steps. Creating the executables seems to be more or less the same difficulty, although Unity seems to be the easier choice as it did not need a plugin and did not require as many steps as Godot did. The time difference was more or less the same but the Godot seemed to be slightly slower but only by a few minutes. Unity could be slower to install because of the requirements of downloading and installing Visual Studio 2019. Neither engines did provide any information about how to create an executable and when the Godot team tried to search for any relevant information, they did not find any. Unity did not need any searching for how to create the executable.
Conclusion: Both engines were more or less the same difficulty, the main difference lies in the fact that the Godot engine is an open source engine. This makes it easy to download and it has less dependencies to other software. After installation the Unity engine was slightly easier in creating an executable.
4.2 Second iteration - Game skeleton
The second iteration steps included the following tasks:
1. Add a game scene with a blue background.
2. Add platforms after pre-determined design.
3. Add a checkered flag (finish point).
4. Add a coin counter (non-functional).
4.2.1 Godot
Time to complete: 1 hour and 18 minutes Developer: Hadi AL Halbouni
This iteration seemed pretty much straightforward for this team, with an import options for the images, they had to set up the scene but the engine told the team how to do so.
Only problem was to set the grid size, offset and screen size to the correct values. This did not take too long and the option-names suited what was desired from the team. The team thought it was rather easy to put the game-object onto the 2D grid. The team also had a problem with the text-label as they did not think the scaling of the label was intuitive enough.
Godot Second iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The team thought that the scaling of the text ob- ject to be most difficult as it was not obvious.
They also thought it was difficult to create the 2D grid correctly.
How much relevant information did you find in order to solve a specific problem?
There was good amount of information on how to adjust the size of the view and how to config- ure the text of the coin-counter, YouTube videos and answers on the engine documentation were both used.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
The team used Google to search and found their answers on the engine documentation and the Godot website where other have asked the same questions.
Was this iteration more or less difficult than the last iteration?
The team thought this iteration was more diffi- cult than the last.
Did you use new technology/functions for this iteration?
The team used new technology in order to solve this iteration.
How would you describe the general personal experience using this game engine x?
The team had a general good experience with the engine, they found it easy to look around among the options and the options was easy to understand, what they did.
How easy did you think it was to find the things you needed?
The layout of the engine was easy to overview according to the team members, and the team could easily find what they were looking for.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The team thought that at first it was hard to know where to look but it quickly became easy once they got used to the engine.
Table 4: This table shows the questionnaire answers for Team Godot in iteration two.
4.2.2 Unity
Time to complete: 2 hours and 33 minutes Developer: Micaela Gustafsson
The Unity team did not have to setup the scene it was already setup and the background colour was already blue by default. The team thought it was hard to get the correct size of both the objects and the grid, as it was not easy to find and it was hard to understand what changed what among the settings. Once the team found out that they had to use a tilemap for the map-settings it became more easy. But they had to search a lot and eventually they came across a YouTube video which made it a little easier. To setup the camera view they had to use a specific formula to set the size value. This setting was not easy to understand and it took some searching to understand that they had to set the pixels of the object as well as everything else. Adding the text was easy and straightforward, apart
from the looks of the layout that came with it, it was rather confusing for the team as the text did not appear directly on the game scene but outside of it and you had to zoom out a lot in order to see the added text, configuring the text was easy though. The Unity’s own documentation was vague and not extremely helpful as it did not really explain how to do the tilemap in details, according to the team.
Unity second iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The team thought that the available informa- tion was poor within the engine which made it harder as there were no obvious setting to set.
They could improve by having a minor tuto- rial at start. The team thought the use of the tilemap was hard to understand, and the infor- mation available from Unity did not really help.
How much relevant information did you find in order to solve a specific problem?
The team did not find much information from Google, they found the most relevant informa- tion from YouTube. But in general there were not a lot of information available on how to set up the tilemap and change the size of the tiles.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
The team used the Unity official documenta- tion, Unity forums and YouTube as the main source of information.
Was this iteration more or less difficult than the last iteration?
The team thought this iteration was by far harder than the last iteration.
Did you use new technology/functions for this iteration?
Everything the team did in this iteration was new.
How would you describe the general personal experience using this game engine x?
The general experience the team had was that the engine is not very user friendly and more- over not very friendly towards beginners as it takes a long time to get into the engine.
How easy did you think it was to find the things you needed?
The team thought that when they knew what they were looking for in the GUI, it was easy to find.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The team thinks the hardest part was the tilemap, which was very hard to use and made it more difficult to setup this iteration, as it was hard to understand and hard to find.
Table 5: This table shows the questionnaire answers for Team Unity in iteration two.
4.2.3 Comparison
The Godot engine is still the more user friendly engine of the two so far. It seems like their layout of the engine is easy and straightforward, not a lot of settings to mess around with.
There seems to be more information as well for the Godot engine, even on the official documentation. Unity could be simpler to use once you know what to look for and how in general a game engine works. Godot had more of a drag and drop layout, where with the Unity engine you have to setup a special tilemap to setup the environment.
Conclusion: For beginners without guidance the Godot engine seems to be the better choice at least this far into the study, as it is more straightforward and have less amount of different kinds of components. It seems to be easier to setup the layout as well.
4.3 Third iteration - Player movement
The third iteration steps included the following tasks:
1. Add player object.
2. Add capability for horizontal movement on user input (left and right arrow-keys).
4.3.1 Godot
Time to complete: 10 minutes
Developer: Frank Hvidbjerg Hansen
The Godot team did not seem to have any major issues in this iteration. The inclusion of the player object was straightforward. The only modification needed was snap to grid and offset. Even adding a script seems to have been straightforward. All they needed to do was to select the game object they wished to add the script to then expand the script tab in the game objects inspector menu then press the section saying ”(empty)” which pops up a small menu where they then selected new script and a pop-up window appeared, where they needed to select some configurations for the script for example the name of the script.
This made a code editor appeared where they could write their code. At first the team tried to solve this on their own and they managed to get the object to move continuously to the right, this movement begun automatically when they started the game. This was not really what they wanted since the player is meant to use the arrow keys to move the object. To solve this they made this Google search “Get user input Godot arrow keys”, this led to the Godot documentation where they found a sample code which helped them solve this problem fast and easy.
Godot third iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The users did not find it very difficult to com- plete this iteration. Only the lack of knowledge but it was easy enough to find the answers they needed.
How much relevant information did you find in order to solve a specific problem?
The Google searches gave result on the first few searches and it was the Godot’s own documen- tation of how to get the object to move from user input.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
They got all the information needed from the Godot documentation.
Was this iteration more or less difficult than the last iteration?
This iteration was less difficult than the last ac- cording to the team.
Did you use new technology/functions for this iteration?
They used new technology this iteration.
How would you describe the general personal experience using this game engine x?
They thought the general experience was great and it was easy to understand.
How easy did you think it was to find the things you needed?
They thought it was extremely easy to find the things they needed in the GUI.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
As adding a script to the object only required that the team clicked on the object which opened a quick shortcut in order to add a script to it, this made it quiet easy for the team to add scripts to the objects. The team found this short- cut quite fast, which indicate it is rather easy to find.
Table 6: This table shows the questionnaire answers for Team Godot in iteration three.
4.3.2 Unity
Time to complete: 33 minutes Developer: Rasmus Flom´en
The Unity team had a hard time completing this task. Even though they had a slightly easier time in this sprint compared to the last one. The main reason for this is that they have started to get use to how the Unity environment works, even though they still have issues with it. For their first attempt on adding a player object they used the Unity tile map. They thought this worked so they went on to trying to get the player object to move by using scripts. They tried to find a way to add a script in the IDE for example: clicking on the object, right click on it and menus but could not figure it out, so they needed to do a google search. This search gave them these instructions:
In the top menu bar select assets, then click the create option and then click on new C#
script. After that is done a new script will appear in the assets folder. To edit the script simply double click the script and it will open up a visual studio instance where the script can be edited. To add the new script to a game object simply select the game object you wish to add the script to and select add new component which is located in the bottom of the inspector menu of the game object. Now either select the script option or search for it and select it, then simply select the script.
To write the code onto the script, the team needed to have Visual Studio open, since there is no built-in code editor in Unity IDE, clicking the script from Unity opened Visual Stu- dio automatically. Finding information on how to write the code for adding the horizontal movement to the player object that is controlled by user input with the arrow keys was
easy and the code was a small and easy piece of code as well. Now the script needed to be added to the player object so the team tried to drop it on the player object they had created in the tile map and they thought it worked but when they tried the game the whole map moved and not only the player object. This led them to try and debug their game and when doing so they found out that the script had been added to the whole tilemap and not to the individual tile (the player object). Their solution was to remove this tile and add a 2D-object to the scene and not to the tile map and then drop the script on it instead of the tilemap, which worked perfectly. This was a frustration and unnecessary complicated process for the team. The main factor for this is a poorly designed IDE and lack of information inside the work space, according to the team.
Unity third iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
Lack of information inside the Unity IDE con- tributed to the difficulty level.
How much relevant information did you find in order to solve a specific problem?
Some information on how to get the user input was found and how to add a script to a game object but only add script was from an official source.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
The information used by the team was found at https://docs.unity3d.com/Manua l/CreatingAndUsingScripts.html https://answers.unity.com/ques tions/667641/how-do-i-move-my- 2d-object-using-arrow-keys-als o-h.html
Was this iteration more or less difficult than the last iteration?
This iteration was easier than the first one, rea- son for this was that the team had more experi- ence in the Unity IDE now.
Did you use new technology/functions for this iteration?
The use of scripts was new to this iteration.
How would you describe the general personal experience using this game engine x?
The general experience was that it was horrible to use.
How easy did you think it was to find the things you needed?
It was hard for the team to find things in Unity since the Unity IDE does not have a user friendly design, where a lot of things are hidden in menus and sub-menus.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The team thinks the side menus are hard to use and does not behave as expected, as the menus are slightly pushed together and some infor- mation was not displayed as the developer ex- pected it to be. They also think the general menu is messy, and the general work space have an odd and surprising behavior when for exam- ple adding a text to the scene, which makes it confusing to work with.
Table 7: This table shows the questionnaire answers for Team Unity in iteration three.
4.3.3 Comparison
The documentation of the Godot engine seems to be far better than the documentation of the Unity engine. This shows in how easy the Godot team found their solution. The lack of information about the tilemap in how it worked made this iteration harder for the Unity team, as it was a waste of time for them to try and add a script to a tile. Godot seemed to have a more user friendly way to add a script as it was less hidden than compared to the Unity environment, as in Godot it would pop-up as a choice as they clicked on the object.
Conclusion: It is easier to add scripts to the objects in Godot, and the official documen- tation was more helpful compared to the Unity documentation but the documentation for Unity was not totally useless either. Other than that it was pretty much the same for both engines.
4.4 Fourth iteration - Physics and collisions
The fourth iteration steps included the following tasks:
1. Apply physics to the player object.
2. Make the player object jump with the space bar.
3. Collisions with the ground shall be set up so that the player does not fall through the floor.
4.4.1 Godot
Time to complete: 1 hour and 10 minutes Developer: Frank Hvidbjerg Hansen
The team found relevant information on their first Google search from a Godot engine tutorial page. This made them add a staticBody2D, which gave them an error message saying they need to add a collision shape, so they did. After this the engine said they had to add a shape to the collision shape, they choose rectangular and marked the first platform, they had to do this for all the platforms. They added layers on both the floor object and the player and then added collisions between the two. They used RayCast2D in order to solve the issue of detecting if the player is on the ground or not.
Godot fourth iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The team faced some issues trying to apply physics and collisions to the player. Accord- ing to the team: ”Godot has some weird system where both collision and physics is handled by similar components, we had to read through the documentation to figure out what we needed”.
They also thought that setting up the collisions was tedious, they had create and set a collision layer on the player and the floor separately, then they had to set the layer mask which says basi- cally is what the item will collide with, exam- ple: player mask will collide with the floor.
How much relevant information did you find in order to solve a specific problem?
The team found a lot of relevant information on how to setup physics and collisions on the Godot wiki. It took some time for the team to read but it had the information they needed.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
Godot’s wiki and forums was the teams main source for this iteration, they ended up finding someone’s question regarding writing code to make the player jump and that took some time to get working.
Was this iteration more or less difficult than the last iteration?
This iteration was more difficult than the last.
Did you use new technology/functions for this iteration?
They used new technology this iteration.
How would you describe the general personal experience using this game engine x?
Once they got an understanding on how colli- sions and physics in Godot works, it was simple to understand, but it took some time to get that understanding. The logic for setting it up was not what they had expected.
How easy did you think it was to find the things you needed?
The team thought that finding things in the ed- itor was a bit tricky, the collision layers were hidden in the project settings and they ended up getting confused because their player sprite was apparently supposed to be a child of the physics object to get it moving with the physics.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The team thought that finding the editor to ac- cess the code was easy but finding the settings for the layers, the layer mask and the collision layer was a bit difficult to find.
Table 8: This table shows the questionnaire answers for Team Godot in iteration four.
4.4.2 Unity
Time to complete: 1 hour and 7 minutes Developer: Micaela Gustafsson
The team thought that the engine did not provide any close information in how to add the new physics they needed for this iteration. The search on google gave a first version in how to solve it, although the data types were misspelled so the code could not be run at first, the solution came from a Unity question and answer forum. The engine did not give much information about why, more than it could not find that component. Below the first search result there were a YouTube video made for beginners, which helped a lot and was the primary reason for this iterations success, according to the team. It was through this video they learned that in the first answer there was a misspelling in the code.
The video did not include collisions with a tilemap so they searched anew and found a quick tutorial on YouTube, which explained it quick and simple. They did not find any information from official sites, but the information found was quick and easy to follow and understand, apart from the layer part which was never really explained why it was used. Adding collisions to the tilemap was by far the easiest part of it all, and makes it easier to add collisions later on with static objects.
Unity fourth iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The team thought the most difficult part was in how to make the player not fall through the first floor, which happened when the player landed on the first floor from the top floor. This was solved by forcing the player to land on a floor located one level below its current floor, so the player can never go from the top platform di- rectly down to the bottom one.
How much relevant information did you find in order to solve a specific problem?
The first search the team did gave some result but did not reveal relevant information about how to add physics as it was misspelled and did not provide enough information. The YouTube video though was their best information source as it provided with good, clear instructions and fast information about how to add the physics, collisions and get the game object to jump.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
Primarily YouTube was used as a source by the team this iteration.
Was this iteration more or less difficult than the last iteration?
This iteration was less difficult than the last.
Did you use new technology/functions for this iteration?
They used new functions and technology as they did not have the need to use collisions be- fore.
How would you describe the general personal experience using this game engine x?
The engine itself did not give any support to fulfill the iteration. The editing is done in Vi- sual Studio which may be the cause of why the editor does not provide helpful information, such as help with finishing data type names and such. Instead, according to the team, the ed- itor helped more with suggestions for variable names, which is helpful but would have been more helpful to have suggestion for data types instead.
How easy did you think it was to find the things you needed?
The team thought it was easy enough to find the collision components, although when going over to the layers they thought it was confus- ing in how to get back to the object inspection, it took them some time to understand that the layer was a different inspection page and was not a subsection of the objects inspection.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
Without the YouTube video it would have been much harder for the team to find the correct components to use, and how to start them up as it needed to have a specific code in order to start using them. The team thought the easiest part was to add collisions to the floors, as they used a tilemap, they only had to put the colli- sion to the tilemap and then it would add the collision to the whole tilemap.
Table 9: This table shows the questionnaire answers for Team Unity in iteration four.
4.4.3 Comparison
The documentation for Godot seems to be far better than the Unity documentation. This shows with how easy the Godot team finds their information and the majority of it comes from Godot.wiki (official documentation) in comparison to the Unity team needed to rely on YouTube guides to find what they needed, since Unity lacks good official documenta- tion. The Godot team had some problem understanding the documentation this time but the reason for this seems to be the complexity of the task. Both teams had some difficulty getting the collisions to work in a satisfying way. The reason for this seems to be due to the problem of understanding which object is colliding with which object. The Godot team also had an issue with that the physics and collision were not separate functions.
Both teams also reported some issues with rigidBody which is a physical property which has functionality such as allowing a player to jump.
Conclusion: This iteration was fairly equal between the two engines, but the Unity engine seems to have the easier time to handle collisions, this may be mostly because of the help of the tilemap.
4.5 Fifth iteration - Interaction
The fifth iteration steps included the following tasks:
1. Coin-objects shall be placed around the game map.
2. Add collision for player and coin-objects.
3. When player collides with coin-objects they will disappear.
4. When player collides with coin-objects coin counter will update with plus one.
4.5.1 Godot
Time to complete: 1 hour and 16 minutes Developer: Hadi AL Halbouni
The users found on their first search a component (Area2D) which listens to if components overlap https://docs.godotengine.org/en/3.1/tutorials/physics/physics introduction.html. Af- ter that they started to search on how to add collision to the component, which took quite a long time, they tried a various of different solutions they found while searching but none of them worked. Until they found out that they have to select the coin-object first when creating the collision method, this came from testing and not any documents. To update the counter seemed fairly easy though.
Godot fifth iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The collision handling did not seem intuitive and the most difficult part of this iteration.
How much relevant information did you find in order to solve a specific problem?
The team found a lot of information about col- lisions between objects but they thought it was hard to find the information they needed, even a YouTube video did not give enough information as the layout of the nodes was different from theirs. Eventually through testing around they found the solution.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
Godot forums, documentation, wiki and YouTube was used as sources.
Was this iteration more or less difficult than the last iteration?
This sprint was more difficult than the last.
Did you use new technology/functions for this iteration?
They used new technology.
How would you describe the general personal experience using this game engine x?
The general experience was negative, it re- quired a lot of steps to get the collision to work.
How easy did you think it was to find the things you needed?
Finding the things they needed in the engine was quiet hard and they could not figure it out themselves which they tried but made it worse.
They had to rely on information online.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The GUI was easy to understand and to use, the problem was more the connection with the com- ponents and the code.
Table 10: This table shows the questionnaire answers for Team Godot in iteration five.
4.5.2 Unity
Time to complete: 44 minutes Developer: Rasmus Flom´en
The team did not have a lot of trouble during this sprint, some quick searches on Google and they got the answers. Collision with the coin was found from the documentation from Unity, they tested to add a function called onCollisionEnter2D to the player which at first made the user disappear, this was later found to be because of making the player get destroyed instead of the coin on collision with the coin. They later on found a YouTube video which was an official Unity tutorial video for beginners, which helped them solve the problem. For the team to get the check if the player collided with the coin was fairly easy. The destruction of the coin was shown in another YouTube video, and was pretty straightforward as well. Updating the text for the coin counter was a bit more difficult, as it was a bit hard to get around how the engine detected which text to change, and how to set it correctly. The team found that they had to go to the panel of the player-object in the engine and add a text to the player-object, this made it so the engine knew what text it would update on collision with the player-object.
Unity fifth iteration questionnaire & answers
Question Answer
Was there anything specific that contributed to the difficulty level in game engine x, for this iteration?
The team did not find anything particular that was hard with this iteration, and they thought this iteration was quite straightforward.
How much relevant information did you find in order to solve a specific problem?
They found a decent amount of information on how to detect collisions between objects but they needed to try a few different solutions until they found the one that worked.
Where did you find the information you needed to solve the different difficulties you encoun- tered such as official documentation or a third party source (Google, stack overflow, YouTube, etc)?
The information that was used to solve this iter- ation was found on YouTube.
Was this iteration more or less difficult than the last iteration?
They thought this iteration was easier than the previous one.
Did you use new technology/functions for this iteration?
They used technology that they have used be- fore but in a new way.
How would you describe the general personal experience using this game engine x?
The feeling the team got of the game engine is that the GUI is clunky and hard to move around and slightly irritating especially as all code needs to be written in a separate IDE.
How easy did you think it was to find the things you needed?
The team thinks it is harder to navigate around the Unity IDE which is due to its poor design.
Were there any specific part of the (UI) design of the game engine that made it easier or harder to use?
The general layout and menus of the IDE is very counter-intuitive, according to the team. Even though this is less notable now after using it for a while.
Table 11: This table shows the questionnaire answers for Team Unity in iteration five.
4.5.3 Comparison
The Godot team had a hard time to find the information they needed which could be a factor of lack of relevant information. The team agreed that a lot of the information they found did not work. On the other hand the Unity team managed to find working information quite easy on YouTube. The Godot team also had a hard time figuring out how the collision was supposed to work and it required a lot of steps to get it to work and they did not find any information about this inside the IDE and needed to rely of outside information. The Unity team had an easier time to get their collision to work. They thought the procedure was quite straightforward but they also needed to rely on outside information. The Godot team thinks the Godot’s GUI is easy to understand and use. The biggest problem problem they have is that it can be hard to understand the connections between the components and the code. The Unity team feel that the Unity GUI is messy and clunky. The Godot team felt like this iteration was harder than the previous one and the Unity team felt it was easier.
Conclusion: Adding the collision and collision-actions is easier in Unity then in Godot.
It is easier to find information for Unity and it requires less steps to add the collision and collision-behavior.
4.6 Sixth iteration - Sound effects
The sixth iteration steps included the following tasks:
1. Introduce sound effects to the game when picking up coins.
2. Introduce sound effects to the game when colliding with the finish flag.
3. Introduce background music while playing the game.
4. When player collides with the checkered flag the game will reset.
