daniil vdovenko development of computer game in
TRANSCRIPT
VYTAUTAS MAGNUS UNIVERSITY
FACULTY OF INFORMATICS
DEPARTMENT OF APPLIED INFORMATICS
Daniil Vdovenko
DEVELOPMENT OF COMPUTER GAME IN THE PLATFORMER
GENRE USING UNITY
Bachelor Thesis
Informatics Systems study program, state code 6121BX016
Study field Informatics
Supervisor Vytautas Barzdaitis degree, name, surname signature, date
Defended prof. dr. Tomas Krilavičius Dean of Faculty signature, date
Kaunas, 2021
CONTENT
LIST OF ABBREVIATIONS ............................................................................................. 3
ABSTRACT ........................................................................................................................ 4
АБСТРАКТ ........................................................................................................................ 5
1 INTRODUCTION ....................................................................................................... 6
2 ANALYSIS OF THE GAME FIELD ......................................................................... 9
2.1 Review of analogs ............................................................................................... 9
2.2 Review of game development environments .................................................... 10
2.3 Analysis of methodologies, settlement of requirements, preparatory design ... 13
2.3.1 General information about the game process ................................................ 13
2.3.2 Development methodology ........................................................................... 14
2.3.3 Functional and nonfunctional requirements, use-case diagram .................... 16
2.3.4 External specifications .................................................................................. 18
3 DESIGN OF THE GAME APPLICATION ............................................................. 20
3.1 Game architecture ............................................................................................. 20
2.1.1 Classes of the game application ....................................................................... 21
2.1.2 States model of the enemy ............................................................................... 26
3.2 Diagram of states of the game ........................................................................... 27
4 IMPLEMENTATION OF THE GAME APPLICATION ........................................ 29
4.1 Structure of the project ...................................................................................... 29
4.2 Implementation of the Player game object ........................................................ 30
4.3 Implementation of the Enemy game object....................................................... 31
4.4 Implementation of background and decorative elements .................................. 32
4.5 Implementation of the graphical interface ........................................................ 35
4.6 Implementation of the in-game animations ....................................................... 36
5 TESTING OF THE GAME APPLICATION ........................................................... 38
5.1 Functional testing .............................................................................................. 38
5.2 Nonfunctional testing ........................................................................................ 39
5.3 Usability-testing ................................................................................................ 42
6 RESULTS AND CONCLUSIONS ........................................................................... 43
6.1 Results ............................................................................................................... 43
6.2 Conclusions ....................................................................................................... 43
6.3 Perspectives ....................................................................................................... 43
7 REFERENCES .......................................................................................................... 45
8 APPENDIXES .......................................................................................................... 47
8.1 Term Paper Abstract.......................................................................................... 47
8.2 The review of game development environments .............................................. 47
8.3 PlayerController code example ......................................................................... 50
8.4 The structure of the player game object ............................................................ 57
8.5 The grid component for the game level ............................................................ 57
8.6 The tile palette configuration and actual views ................................................. 58
8.7 The graphical user interface for the main menu ................................................ 59
8.8 The graphical user interface for the game menu ............................................... 60
8.9 The graphical user interface for the pause menu............................................... 60
8.10 Animations ........................................................................................................ 61
8.10.1 Demonstration of the animation frames on the timeline of the player ........ 61
8.10.2 Demonstration of the animation frames on the timeline of the enemy ....... 61
8.10.3 The demonstration of the main menu tested functions ............................... 62
8.10.4 The demonstration of the pause menu tested functions .............................. 62
8.10.5 The demonstration of the tested functions of the player ............................. 63
8.10.6 The demonstration of the tested functions of the combat and interaction .. 63
8.10.7 The demonstration of the tested functions of finishing the game by reaching
the endpoint in the level ........................................................................................................ 64
8.11 Sources .............................................................................................................. 65
3
LIST OF ABBREVIATIONS
AAA
2D
3D
PC
PS4
IDE
HTML5
SRP
HDRP
LWRP
UML
LMB
UI
OOP
FR
NR
GUI
CPU
GPU
Triple A
Two-Dimensional
Three-Dimensional
Personal Computer
PlayStation 4
Integrated Development Environment
HyperText Markup Language
Scriptable Render Pipeline
High-Definition Render Pipeline
Lightweight Render Pipeline
Unified Modeling Language
Left Mouse Button
User Interface
Object-oriented programming
Functional Requirement
Nonfunctional Requirement
Graphical User Interface
Central Processing Unit
Graphical Processing Unit
4
ABSTRACT
Author Vdovenko Daniil
Title Development of Computer Game in the Platformer Genre Using Unity
Supervisor Vytautas Barzdaitis
Presented at Vytautas Magnus University,
Faculty of Informatics, Kaunas
(2021.06.11)
Number of pages 46
Number of appendices 19
Platform game is a subgenre of video games and can be of two types, for example, a
puzzle game or an action game. The basic concept of 2D platformers is that the player will control
a character or avatar and guide him through a series of platforms that can be grounded or raised
depending on the design of the level. The mission of such games is to always collect certain items
(coins, rubies, etc.) and avoid or fight enemy characters. In this game, an environment will be
developed that will consist of earthed and suspended platforms and environmental barriers. To
achieve this, it is necessary to analyze and study the features of the analog game, determine the
advantages of the selected game engine, build a UML diagram of the game, define functional
and non-functional requirements, and design prototypes of the scenes, UI of the game
application. Create a game architecture by developing in-game classes with appropriate
functionality, use a state machine to reproduce dynamic changes in enemy behavior using the
C # programming language. Implement functionality in Unity using written scripts, create in-
game objects, create scenes, create a game level, and animate characters. Finally, to provide
functional testing to validate functional requirements, non-functional testing to see how the
product works, and usability testing by engaging users to test the game. The result of decisions
will be that the product has a good reason to use Unity, strict functional and non-functional
requirements, game prototypes, functionality through developed classes, implementation
directly in Unity, and testing to avoid potential bugs and contingencies errors for the most error-
free product deployment. This game will be supported on multiple platforms such as the latest
versions of Windows and MacOS.
5
АБСТРАКТ
Автор Вдовенко Даниил
Заглавие Разработка компьютерной игры в жанре платформера с
использованием Unity
Руководитель Витаутас Барцадаитис
Представлена Университет Витаутаса Великого
Факультет Информатики, Каунас (2021.06.11)
Количество страниц 46
Количество
придатков
19
Основная концепция 2D-платформеров заключается в том, что игрок будет
управлять персонажем или аватаром и направлять его через ряд платформ, которые могут
быть заземлены или подняты в зависимости от дизайна уровня. В этой игре будет
разработана среда, которая будет состоять из заземленных и подвешенных платформ и
экологических барьеров. Для этого необходимо проанализировать и изучить особенности
аналоговой игры, определить преимущества выбранного игрового движка, построить UML-
диаграмму игры, определить функциональные и нефункциональные требования и
разработать прототипы сцен. Пользовательский интерфейс игрового приложения.
Создавайте игровую архитектуру, разрабатывая внутриигровые классы с соответствующей
функциональностью, используйте конечный автомат для воспроизведения динамических
изменений поведения противника с помощью языка программирования C #. Реализуйте
функциональные возможности в Unity с помощью написанных сценариев, создавайте
внутриигровые объекты, создавайте сцены, создавайте уровни игры и анимируйте
персонажей. Наконец, для обеспечения функционального тестирования для проверки
функциональных требований, нефункционального тестирования, чтобы увидеть, как
работает продукт, и тестирования удобства использования путем привлечения
пользователей для тестирования игры. Результатом принятых решений будет то, что у
продукта есть веская причина для использования Unity, строгие функциональные и
нефункциональные требования, игровые прототипы, функциональность через
разработанные классы, реализация непосредственно в Unity и тестирование, чтобы в
большинстве случаев избежать потенциальных ошибок. Эта игра будет поддерживаться на
нескольких платформах, таких как последние версии Windows and macOS.
6
1 INTRODUCTION
Development of game applications has never been an easy task to handle especially for
AAA studios spending years of debugged approaches to surmount the challenges, risks and
succeed in product deployment for masses of gamers all over the globe. It is important to note that
there are many genres a game can have at the same time, on the other hand, the game product may
have a single genre but in today’s game industry this approach may seemingly determine the
simpleness and not lay claim to be a multifaced product. At the same time, even a superficial game
product may bring an unforgettable experience to audience by relying on quality trends. There are
notable quality trends a game application should follow like interesting storyline, flexibility,
continuous challenge, combination of fun and realism, and immediate, useful rewards [1].
These trends serve and embody equilibrium between being good, bad or mediocre game but not
necessary all these criteria are kept on practice, on the contrary, some criterion may outweigh
another, and it only impacts on player’s choice because everything depends on the quality of
execution. In case a game product follows a narrow focus approach, it may follow several or one
quality trend and execute it with utmost quality, on the other hand, if a game application follows
a multifaced approach, it must adhere to various quality trends and execute each trend not worse
than the rest otherwise mediocrity is inevitable (on practice, it is exceptionally hard). Finally, a
bad game product means neglection of any quality trends which appears in poor gaming experience
and frustration among final users.
Not least important part of development of game product is choosing robust, relevant game
development platform called “game engine”. Therefore, with advent of platforms called game
engines helping to execute common game-related tasks like rendering, physics-related
computation, and input meant to be a solution for productive game development to collect reusable
components that can be manipulated to bring a game in life, according to [2]. Furthermore, game
engine can be a fundamental playground to be used for the next project development and thus work
as a predecessor-platform with updated features. The essence of game engines is to be a platform
abstraction, so making a few changes to the source code allows gamers to play games on diverse
platforms ranging from personal computers to mobile devices. For this reason, game development
requires professional skills in programming especially engineering, when one’s video game is
unique and demands to develop a brand-new game engine. In this research, the creation of a game
doesn’t require to create a bicycle, but the knowledge of programming language and debugged
game engine platform called Unity. There was always a dispute over what kind of platform to
choose, what benefits developers would get from implementing existing platforms instead of
creating it from scratch, and what approaches to abide.
7
Consequently, there should be a synergy between these two entities like game and game
engine, because not every game vision may be fulfilled in game engine and vice versa.
Nonetheless, for demonstration of game development flow and game mechanics purposes
which may serve as a skeleton for finalized game product by alleviating future development steps,
the goal of the research is to follow game development steps like analysis of the domain, design,
implementation, and testing by relying on proven game genre called “Platformer” with side
genres in it using Unity game engine.
Actuality of Platformer Genre
A game application in platformer genre – a game application, in which a player controls
an object, moves across the playing field horizontally or vertically and overcomes obstacles and
destroys enemies on a way.
A Platformer game – a game which may range from have a purposely simplified or
hardcore game process. A computer game is called platformer given that player has an objective
to reach a destination by overcoming barriers which stand in front of him. The simplicity of the
objective is leveled out by the fact that each player’s movement onscreen may be a life and death
question in the game which brings a challenge and draws attention of hardcore players, that is a
predominantly a paramount aim [3]. Additionally, this one of the genres that is a perfect choice to
immerse in development world of games. Consequently, it would teach the primitives of
mechanics which then can be implemented in future projects by giving the understanding of how
to seamlessly put them into the practice and reap a benefit from the acceleration of the game
development process.
The following figure depicts the representation of general platforming game view. This
concept will bear similarities to the developing game project. The player’s character appears at a
certain point on the playing field. The player can move along the map, destroy enemies which
block the path, and avoid environmental barriers which may either instantly destroy player’s
character or deal some damage. The player should find the way to the ending point of the level.
Figure 1 Representation of a platforming game concept [Made by author]
8
Platformer games can be played on every game station like smartphones, portable consoles,
desktops, laptops which means that platformer genre is an inalienable pilar of game industry and
these genre aspects may be inherent in many other games which have a combination of diverse
genres. Traditional platformers define a simple, intuitive control of game objects. A user doesn’t
need to configure and learn game controls; thus, it lets almost immediately start the gameplay.
Undeniably, the actuality of platformers is time-tested and has proven that it will last for
long due to being used nearly in every AAA game, thus the goal of developing a game in such
genre is of a current interest.
Goal and tasks
The goal of the project is to develop a game in the “platformer” genre implying developing
sub-mechanics in it and using Unity game engine as an environment.
To reach the set goal, it’s required to solve following tasks:
1. Execute the analysis of the subject area, requirements and develop external
specifications.
2. Create the design of game application.
3. Do the implementation of game application.
4. Provide the testing of game application.
Content of work
In the first chapter, “Analysis of the subject area”, the review of analogous, the review of
game engines, preliminary design, basic requirements for the game and external specifications are
executed.
In the second chapter, “Design”, the design of game application is executed.
In the third chapter, “Implementation” the description of implementation is performed.
In the fourth chapter, “Testing”, the testing of game application is done.
In results, the description of main results during the writing of thesis is received.
9
2 ANALYSIS OF THE GAME FIELD
In contemporary game development industry, it is complicated to find a game product
which doesn’t follow the basic trends of genre in which the game is developed. In this way, the
attempts to present fundamentally new mechanics is nearly impossible due to the genre might be
hackneyed and new visions are exhausted. Thus, it is important to look at the analogs without
which today’s platformers would not exist.
2.1 Review of analogs
Crash Bandicoot – a series of platformer games about a fictional character called Crash
Bandicoot released by Naughty Dog, Player controls the character in two or three dimensions
depending on the level, thus it brings diversity unlike other 2D games in nineties. The game goes
through 32 consecutive levels to reach the end. At some levels, the player may encounter bosses
that serve as an obstacle to the transition to the next chapter. The paramount objective of the game
is to overcome obstacles like platforms, enemies, death pits and collect apples which serve as
rewards with the subsequent option to purchase in-game things. The game brings unique
mechanics like combing 2D and 3D dimensions, hardcore and competitive challenge. The entire
game series is available on PlayStation 4, 5 and PC [4].
Castlevania - is a series of video games released by Konami starting with Castlevania, an
NES game released in 1986. The first game focused on the whip-armed vampire hunter Simon
Belmont as he tried to fight his way through Castlevania to kill Count Dracula. The game combines
medieval lore with the exciting action of platforming around thematic enemies. Player can hit
enemies with different weapons which are acquired when advancing through the game along with
platforming which can be a life-or-death question due to the number of attempts to revive the
character is limited otherwise the game will begin from the very first level [5]. Thus, the game
embodies the essence of hardcore and continuous challenge which is why it is very appealing to
gamers looking to test their nerves.
Super Meat Boy – is a spiritual heir of “Super Mario Bros” game series which was release
in 2010 by Team Meat. This a definition of platformer because no other tool is given to player but
personal skill to overcome objects and defeat enemies. Super Meat Boy is a red creature with two
legs, but its appearance can be changed by completing challenges and gathering collectibles in
each level. Every new appearance gives the player a new ability to overcome obstacles but not
facilitates the game process, on the contrary, it encourages to examine levels more thoroughly.
10
The abovementioned video games define and demonstrate an ideal implementation of
crucial game mechanics for the genre although neglecting some conventional quality trends but
aiming to implement a couple of them with high-quality.
The following table demonstrates the quality trends which are good, mediocre, or missing
or having in those games and trends which will be implemented in the game application in this
research:
Table 1 Comparison of Analogs
Criteria Crash Bandicoot Castlevania Super Meat Boy Developed game
Interesting storyline Mediocre Mediocre Mediocre Mediocre
Flexibility Good Good Good Good
Combination of fun and realism Mediocre Mediocre Mediocre Mediocre
Useful rewards Yes Yes Mediocre Mediocre
As it is seen in the Table 1, there a comparison of quality trends these games follow and
don’t adhere. As it was said, following even a single trend and executing it substantially is a good
sign for a game product. Although most of the analogs have two quality trends, executed well, the
development of the game in the research will stick to “Flexibility” by offering different game
mechanics within the core game mechanic like platforming.
Nevertheless, determining the genre and quality trends is a half-way to a debugged game
development process. Equally important is choosing a suitable game development environment
which would offer functionality and tools to implement the vision. Since the game is 2D-based,
it’s important to review and compare different 2D game engines (some mixed) to prove that Unity
game environment is an imminent choice.
2.2 Review of game development environments
There are plenty of developed game engines on the market which may be purchased to be
used for the development process. On the other hand, the owners of game engines usually offer a
possibility to use it utterly for a free or partially-free model. What concerns the last model, it
bounds one to pay a percentage from sales of one’s deployed, commercial game. Ultimately, if the
advantages of a game engine don’t meet the requirements of a developer, the only solution is to
develop its game engine which would have all features that are needed.
The Table 2 demonstrates the gathered information from Steam marketplace, which depicts
the statistics of the game engines popularity. It shows the popularity of game engines which are
11
used on the market. Each of them has its pros, cons, and objectives. The statistics clearly define
the fact that many developers prefer to use a partially-free model rather than develop an in-house
game engine from scratch.
Table 2 Game engines used in games released on Steam (2018-12-28) [6]
Game Engine Number of projects % Of total games identified
Unreal 1726 25.6%
Unity 889 13.2%
Source 270 4.0%
CryEngine 238 3.5%
Gamebryo 215 3.2%
IW 192 2.9%
Anvil 166 2.5%
Id Tech 113 1.7%
Essence 73 1.1%
Clausewitz 68 1.0%
Identified games with other
engines
3266 48.4%
It is important to state that there is no perfect game engine that can satisfy one’s objectives
on one hundred percent, thus, one should consider a few aspects before taking into consideration
a game engine and review available game engines on the market (Appendix 8.2).
Identification of key features and purposes
The observation of game engines and their features have been done. The pages from 15-18
were useful for emphasizing criteria of game engines, thus the following Table 3 depicts the
criteria used to measure the advantages and disadvantages which had been discussed in those
pages. Additionally, it helps to identify purposes and key features that one may consider before
implementing an idea of the future game. Green color means an advantage whereas red color
means a disadvantage. An engine which has more points is the most optimal and beneficial for
game development process.
12
Table 3 Identification of key features and purposes Godot GameMaker Defold Corona Unity Unreal Engine CryEngine
Scene and
node system
Yes No No No Yes Yes Yes
2D
development
Yes Yes Yes Yes Yes Impractical Impractical
3D
development
Yes No
No No Yes, but not
large-scale
environments
Yes Yes
AAA 2D No Yes No No Yes Yes Yes
AAA 3D No No No No No Yes Yes
Lightweight
for
development
Yes Yes Yes Yes No No No
Cross-
platform
Yes May be
difficulties
Yes Yes Yes Yes Yes
Royalty-free Yes Yes Yes Yes Yes Depends on
annual
Revenue 5%
Depends on
annual revenue
5%
Community Not huge Not huge Not huge Not huge Very huge Very huge Huge
Scripting
language
.NET/C#,
C++,
Visual
Scripting
GM, C++ LUA LUA C# C++ C#, C++, LUA
Asset
marketplace
Not huge Not huge Poor Huge Very huge Very huge Very huge
Excels at
shooters
No No No No Yes, partially Yes Yes
AR, VR Primitive
VR is
added,
AR is not
added
Bad
implementation
No
implementation
No
implementation
Yes, strong
implementation
Yes, strong
implementation
Yes, strong
implementation
Beginner-
friendly
Yes Yes Yes Yes Yes Yes No
Optimality 8 6 5 6 12 11 10
13
The following Figure 2 depicts which game engine among the others is the most optimal
and has more advantages over the rest game engines. The calculation of optimality was done
thanks to criteria in the Table 3 results:
Figure 2. Comparison of game engines [Made by author]
Eventually, Unity is a winner among the other described game engines in Table 3 to start
developing a project and which would accommodate most potential developer’s needs. Thanks to
Table 3, we can make an inference about optimality of this engine by listing features which
inherent to it: since it's AAA 2D-oriented game engine, it provides a strong toolkit for recreating
approximately all attributes of 3D game engine whereas Unreal or CryEngine have abundant
functionality to recreate 2D games. Although not being a AAA 3D-oriented, it can reproduce
decent 3D games but with limited terrain size, nonetheless, comparing with Unreal or CryEngine,
Unity would use technologies which wouldn’t overburden the hardware like pre-made assets
and SRP part of rendering engine which conducts optimization process, thus it becomes easier to
optimize game products with this engine. Most importantly, Unity doesn’t charge on a per title
basis or requires revenue percentage model unlike Unreal or CryEngine.
After familiarization of game engines and their advantages and downsides, the choice of
the game engine is Unity which will satisfy all the needs for development. To start off, it is
significant to develop a sketch design.
2.3 Analysis of methodologies, settlement of requirements, preparatory
design
2.3.1 General information about the game process
The game application is implied to be used by only one player. The game begins from an
established starting point on the playing field and on that point, the game-controlled object
14
(player’s character) is situated. A player controls the character, which can move horizontally and
vertically. The ability to move vertically means jumping, pushing off the walls and sliding down
the walls. The horizontal perspective implies giving the player abilities to make the character hit
the enemies and run, and each player’s action is accompanied by animation.
The condition for obtaining the victory is to get through the level and stay alive by reaching
the most end checkpoint of a location. Destroying enemies is not part of the player's task, at the
same time, it might facilitate the playthrough and it may be impossible to get to some point in the
level without facing an enemy. Points can be earned by killing the enemies. The game ends when
the player reaches the finish point. Each time the player dies from in-game environmental barrier
(spikes), the player starts the level from the very beginning. The health bar of the player will
decrease with every attack from an enemy. The health cannot be restored through level but if the
player dies the health is restored to full.
The camera is attached to the player and moves smoothly thanks to the built-in library in
Unity, every time the player moves, the camera will follow.
2.3.2 Development methodology
There are two main development methodologies which are widely implemented in
contemporary software development: agile and waterfall. The difference between them is that
projects relying on agile methodology are executed iteratively in a cycle whereas projects adhering
to waterfall methodology are executed sequentially [11].
Each approach may have its disadvantages and advantages and should considered by a
team and how it wants to approach a project. Everything depends on how the team wants to
organize the development flow, tasks and how they should be approached and accomplished.
The following statistics of popularity of the approaches clearly define that agile
development approach is implemented much frequently in comparison with waterfall approach:
Figure 3 Agile vs waterfall (2020-04-07) [12]
15
The following Table 4 describes the benefits whereas Table 5 describes the downsides of
each approach one might meet when appeal to one of these methodologies:
Table 4 Advantages of Agile and Waterfall methodologies
Agile Waterfall
Benefits
Faster software development life cycle Better design with whole system approach
Promotes efficient communications Defined scope of work
Ideal for project with non-fixed funding Clear measurements of progress
Flexible in accepting changes Hands-off approach
Adaptability Documentation
A higher quality and user-friendly product Defined team roles
Table 5 Disadvantages of Agile and Waterfall methodologies
Agile Waterfall
Downsides
Communication Less customer involvement
A high degree of customer involvement Changes can be difficult
Ideal for project with non-fixed funding Last-minute testing
Intense engagement Hands-off approach
A time-boxed iteration Sequential approach is not ideal for a large-scaled project
when the final output is too far in the future
Since there is a single member in the team for the research, it’s hard to put in practice these
approaches. Although the methodologies are used by teams working on the tasks together, the
development approach of the game product in the research can be classified as waterfall since all
stages are sequential. Neither the project has a long-term development cycle nor long-time testing
nor customer involvement and nor teamwork, thus some crucial aspects relevant to waterfall
methodology like hands-off approach, sequence and determined scope of work are defined for the
project. Lastly, the project doesn’t pretend to be large-sized, on the contrary, the implementation
of crucial game mechanics may facilitate the subsequent expansion of the game core.
16
2.3.3 Functional and nonfunctional requirements, use-case diagram
It is indispensable to define functional and nonfunctional requirements of software
applications where game application is not an exception. Functional requirements describe what
the product will do, its functions and features whereas nonfunctional requirements are known to
be quality attributes of the product, the characteristics without which it’s not clear how the product
should operate.
During the analysis of requirements of the game application, a UML use-case diagram was
designed [13, 14] (Figure 4).
The game is designed for one person. The player controls the fictional character.
Character - an object, controlled by player, moving horizontally or vertically on the game
field. The control is performed via keyboard buttons AD (Movement), Space (Jump, holding Space
longer will make the character to jump higher), LMB (Hit).
Change game settings: the game application must have preferences of music and effects,
an option to either turn on or off music and effects.
See the score: during the gameplay, player may kill enemies and thus he earns points for
that which serve as an indicator how many enemies have been destroyed in the game session.
Earning points is not obligatory to finish the game being just in-game personal record. Every time
the player finishes the game session, the score is restored to 0.
Begin the game: start the game process from the main menu.
Pause the game: an option to pause the game in any time.
Resume the game: an option to resume the game from the pause menu.
Figure 4 Use-case diagram of the game application [Made by author]
17
The following Table 5, Table 6 describe functional and nonfunctional requirements of the
game application:
Table 6 Functional requirements
Functional
Requirement
No.
Functional Requirement Description
No.1 User must be able to move a character via input devices
No.2 User must be able to jump a character via input devices.
No.3 User must be able to make a damage with a character via input devices
No.4 User must get points from destroying enemies.
No.5 User's character must get damage from attacks from the enemy.
No.6 User’s character must die when a health bar reaches 0.
No.7 User’s character must bounce off and slide down the walls using jump
No.8 Camera must be stick to a character and follow him
No.9 The game must end when a user reaches the ending point and send the player to the main menu
No.10 User’s score for destroying the enemies must be reset each time the player starts the game, dies from the
enemy or an environmental barrier, restarts the game from the main or pause menus.
No.11 User’s character must die instantly if he touches spikes.
No.12 The enemy must change states depending on the player’s actions: patrolling the area, looking for the
player, charging at player, attacking the player.
No.13 User’s character must respawn when he dies.
No.14 User must be able to pause, resume and go to the main menu from the pause menu.
No.15 User must be able to start the game process from the main menu by pressing the “Play” button.
No.16 User must be able to exit the game from the main menu by pressing the “Exit” button.
No.17 Use must be able to go the pause menu by pressing the corresponding button. From that menu, user must
be able to resume, restart or to go to the main menu.
Table 7 Nonfunctional requirements
Nonfunctional
Requirement No. Nonfunctional requirement
No.1 Frame rate. The framerate of the game must not be less than 60 frames per second. The frame rate
can be monitored directly from the graphic engine.
18
No.2 Installation and portability. Installation, configuration of the game application must be successful,
and portability must be present between two operating systems MacOS and Windows.
No.3 Performance with required resources. The game must be able to work with a minimum of 1024
MB of RAM. For the operation used when playing the game, we can check the physical memory
on the Activity monitor in MacOS.
No.4 Maintainability. The code written for the game must be maintainable
2.3.4 External specifications
Thanks to the results of the analysis of the subject area, the UI of the game application was
developed thanks to information gained in the source [15]. It consists of two main screens – main
menu and game screen (Figure 5, Figure 6) Additionally, there is a side menu called pause menu
so if the player wants to stop the game process, he can simply press the corresponding button and
the menu would pop up (Figure 7).
In the main menu there are depicted parameters like the configuration window and the game
screen. The name of the prototype game is “Forsaken: Deep Dark Fantasies”. User can manipulate
with settings and configure them the way he wants it to.
On the game screen there are depicted health bar of the player, the number of points gained
by destroying the enemies, and the game field with the designed level. By playing through the
level, decorations, objects, and obstacles change each other.
On the pause menu screen, there are three buttons “Resume” meaning to continue the game
process, “Restart” gives an ability to relaunch the game process from the very beginning, “Main
Menu” which allows to go to the main menu to adjust sound settings, exit the game or start the
game process. The label implies that the game is paused.
Figure 5 Prototype of the main menu [Made by author]
19
Figure 6 Prototype of the game screen [Made by author]
Figure 7 Prototype of the pause screen [Made by author]
20
3 DESIGN OF THE GAME APPLICATION
3.1 Game architecture
As the result of designing the game application, there was developed UML-diagrams of
classes of the game thanks to the source cited [16]. Some classes are interconnected to provide
functionality and workability of the game elements.
The architecture of the Unity3D is based on the template like Entity-Component-System
[17,18]. Following this template, the game application consists of base entities and their
functionality is expanded by using specialized components.
The Unity3D project consists of two scenes (Scene) like the main scene and menu scene.
The main scene has game objects (GameObject) with attached components to them. Every game
object has a required component Transform that is responsible for object location on the scene. On
top of that, there might be included ready components (for example, Rigidbody 2D since the project
is 2D based, which is responsible for physical simulation, BoxCollider 2D, which is responsible
for collision simulation) as well as user’s components [19]. Additionally, for every acting game
object animator controller is attached (Animator).
Firstly, the programming part in Unity lies in the development of the user’s classes directly,
and then these classes are connected to game objects as components. Thus, all these classes must
be inherited from the superclass called MonoBehaviour. The identification of this relationship
would significantly overload the diagram; thus, the suffix “Script” is added to their names to
identify class-components.
The following classes of the game application were constructed [20]. The diagrams are
dived due to being large and it’s impossible to depict all of them in a single figure. Figure 8 depicts
the interconnection of classes of the player, sound, GUI, scene management, and game barriers.
21
2.1.1 Classes of the game application
Figure 8 The diagram of classes of the player and game application [Made by author]
Class SoundManager accounts for defining the audio source, music volume (which can be
configured according to user’s needs), and sound effect clips which are then assigned to functions
related to player’s actions like sword swing sound effect, damage sound effect, and player death
sound effect. The sound effects volume can be configured in the main menu.
Class Background is responsible for playing ambient soundtrack and it’s set to be in the
loop. The background music is set to start to play in the menu scene and then it seamlessly
continues to be played by transitioning to the game scene. It’s made as a separate class otherwise
that seamlessness would not be achieved. The background music can be configured in the main
menu.
Class ShowValue is designed to show the percentage of the volume for both background
and sound effects, the script is attached to GameObject Text, and then this game object (Text with
22
the script accordingly) is attached to sound sliders responsible for regulating volume dynamically.
Unity.UI class is required for this class.
Class ScoreCounter is created to depict the score count of how many enemies have been
destroyed in the game session. The score counter will be restored to zero if the player restarts the
game from the pause menu, goes to the main menu, dies from the enemy or an environmental
barrier. By respawning, the score counter is reset to 0.
Class HealthBar – class, which is responsible for depicting the player’s health status, the
color of the bar will be changing from red to yellow and from yellow to dark red depending on the
health percentage.
Class GameManger – class, which is responsible for dealing with a respawn point of the
player. It sets the timer for how long the player would have to wait before respawning. This class
can be extended in the future and operate different functionalities of the game application.
Class ChangeScene – class, which is responsible for the transition between menu and game
scenes. Once the “Play” button is pressed, it automatically transmits the user to the game scene
and the gameplay begins, thus the control is given to the user over the character.
Class Spikes – class, which accounts for determining the Player GameObject and instantly
reload the game scene once the GameObject Spikes are triggered (the script is attached to Spike
Trigger). Spike serves as a barrier and once the player touches it, he instantly dies, and the game
scene is reloaded.
Class UIManager – class, which is responsible for the pausing the game and opening the
pause menu in the game scene. The player can pause the game anytime, thus he can restart via
Reload (), resume via Pause () control the game process and go back to the main menu from the
pause menu via LoadLevel (). The pause menu is only shown when the player pressess the pause
button accordingly, it’s done via setting the “ShowOnPause” tag in the inspector in Unity.
Class ExitGame – class, which is responsible for letting the player leave the game from the
main menu. It’s executed via pressing the “Exit” button in the main menu and implemented via
Exit () method.
Class FinishGame – class, which is responsible for the defying the trigger when the player
reaches the end point. It’s done by creating a GameObject BoxCollider2D in Unity, and when the
player’s hitbox collides with the hitbox of the end point with the tag “Player”, the trigger works
out, thus the player is sent to the main menu and the game is finished.
23
Figure 9 The diagram of classes of the player [Made by author]
Class PlayerController - class, which is responsible for predominantly most important
player’s behavior like jumping, moving, checking walls, checking ledges, checking the ground,
wall sliding, updating animations, and knocking back from enemy’s hits. The code example is
demonstrated in Appendix 8.3.
Class PlayerCombatController – class, which is responsible for defying combat mechanics
for the player. There are various parameters which state combat attack radius, attack damage,
attack hitbox position, and different checks for determining inputs, attacks, hitbox, damage the
player can deal, finish of the attack, and the layer mask of what is damageable to define the layer
in Unity of what can be damaged and not.
24
Class PlayerStats – class, which is responsible for defying player health and methods for
applying health decrease and dying. It defines the variables of player’s current health, maximum
health, and then they are implemented in method DecreaseHealth () which would count how many
health points should be taken away from the player according to the Damage () method in
PlayerCombatController.
Structure AttackDetails - structure, which is responsible for setting the position of the hit
and the damage amount which can be dealt with the player.
Figure 10 Classes of the finite state machine model of the enemy [Made by author]
E1_Name and state classes are interconnected, thus it’s important to describe them by
mentioning the base state classes from which E1_Name classes inherit. D_Name data classes just
store the data and the description of them in UML-diagram would be redundant.
Class Entity – class, which is responsible for defying all checks and functionality of the
enemy ranging from checking the ground, walls, ledges, player, visible range to setting velocity,
damage, and death functions.
Class Enemy1 – class, which is responsible for defying objects of E1_Name classes as well
as data fields in the Unity Inspector menu. Enemy1 has reference objects of all D_Data classes
where different parameters are stored.
Class FinateStateMachine – class, which is responsible for defying functions like
initializing current state and changing state methods. ChangeState () method is used throughout
all state classes to switch from one state to another depending on the conditions.
25
Class State – class, which is responsible for setting animations depending on states. It will
change the enemy’s animations in E1_Name state classes depending on other states from which
the enemy would transfer from.
Class AnimationToStateMachine – class, which is responsible for checking the triggering
and finishing off an attack, and depending on it, it will switch animations of these states.
Figure 11 Classes of the states of the enemy [Made by author]
Class IdleState – class, which is responsible for setting the random interval of idling and
updating logic in LogicUpdate () to count time and check when idle time is over. The idling begins
when an enemy reaches a wall or ledge, then he idles and waits for a random idle time interval.
Class MoveState – class, which is responsible for setting the velocity in Enter (), and
detecting barriers like walls, ledges, and check if the player is in the minimum visible range. This
the default state from which the enemy starts and then switches this state to others in
E1_MoveState LogicUpdate () depending on checks correspondingly.
Class PlayerDetectedState – class, which is responsible for defying checks for minimum,
maximum visible range, and perform close-range action depending on the range. The SetVelocity
() sets the velocity to 0 once the player is detected.
26
Class LookForPlayerState – class, which is responsible for checking turns (flips), turns
time interval, and minimum range. It accounts for how many times the enemy should turn
(immediately) to look for the player.
Class ChargeState – class, which is responsible for shortening the distance towards the
player along with defying minimum visible range, range action, charge timer, and different checks
related to walls and ledges. The script checks whether the player is in the minimum visible range
as well as checking if any barriers are ahead, then it can perform a long-range action. Additionally,
it starts the timer to count when charge time is over.
Class MeleeAttackState – class, responsible for performing an attack as well as defying
damage amount, position, attack radius, finish attack (if the animation is finished), and minimum
visible range to the player.
Class DeadState – class, responsible for considering the enemy’s death when the current
health is less or equal to zero. Based on the damage amount, the Damage () function is called in
Enemy1 class to change the state to DeadState.
2.1.2 States model of the enemy
For the design of an enemy in the game process, it should show a decent degree of
intelligent behavior once he bumps into the player. This model is based on Inheritance in OOP
[21], which allows to define a base class that certain variables and functions, and then define
classes that derive or inherit from that base class. Thus, these derived classes will get all the
variables and functions from the base class with the option to override all the base class
functionality if it’s needed. This model is powerfully relevant if one wants to create diverse
enemies with abundance of states. Figure 12 demonstrates the Inheritance model:
Figure 12 Demonstration of inheritance model [Made by author]
The main advantage of this model is that it can be easily reused and expanded for the
implementation of new states and behaviors for various enemy AI.
27
The entry state is the move state (patrolling) at which the enemy begins. Depending on
whether the enemy sees a wall or ledge, it will switch to an idle state for random time intervals set
in settings, once the idle time is over it will switch back to the move state. From both these states,
the enemy can switch to player detected state, if the player is situated in the minimum visible
range. If the player is found and locates in the long-range or tries to leave the range, the enemy
will switch to the charge state to shorten the distance to the player, once the player locates in
sufficiently close range, the enemy will switch to melee attack state to hit the player. If the player
is out of visible range, thus he is not found anymore, the enemy will switch to look for the player
state, once he is found, the enemy will switch back to look for player state. If the player is still
not found, the enemy will switch to the default move state (patrolling). Additionally, if the player
is still out of attack range and charged for time, it will switch from charge state to player detected
state. Moreover, if the distance (range) is maximum, the enemy still sees the player and will switch
to the player detected state from the melee attack state. Finally, if the enemy gets damage and
his current health will be equal to less or zero, he will switch to the dead state.
Figure 13 demonstrates the interconnection of classes of the entity, which a superclass
from which one can build various enemies by using finite state machines and states [22].
Figure 13 Interconnection of states of the enemy [Made by author]
3.2 Diagram of states of the game
As the result of designing, a UML-diagram of states of the game application was developed
[23] (Figure 14).
28
Figure 14 Diagram of states of the game [Made by author]
There were determined such states of the game application.
State “Menu” – the first state of the game application. When you go to it, the main menu
opens, in which you can change the game settings. At the command of the player, a transition is
made to the "Start game" state by pressing the “Play” button.
State “Beginning of the game” - when passing to this state, the objects necessary for the
game are initialized. The transition to the next state is carried out automatically after the
initialization of game objects.
State “Game” – when the game application is in this state, the player can control the
character on the game field. After reaching the end point of the level, the transition to the following
state is carried out.
State “End of the game” – when passing to this state, the game objects are deleted and the
transition to the main menu state “Menu” is carried out.
The end state for the software application is not foreseen because it’s expected that the
player may decide to complete the work with it at any time.
29
4 IMPLEMENTATION OF THE GAME APPLICATION
4.1 Structure of the project
The development was carried out in the C# programming language [24] in the Visual
Studio IDE. C# was used to develop in-game scripts which handle everything happening on the
game and main menu scenes.
Microsoft Visual Studio - a line of Microsoft products, including an integrated software
development environment and a few other tools. The data allows you to develop both console and
GUI applications, including those with support for Windows Forms technologies, as well as
websites, web applications, web services in both native and managed code for all platforms
Supported Windows, Windows Mobile, Windows CE, .NET Framework, Xbox, Windows Phone
.NET Compact Framework, and Silverlight [25].
The game application consists of two scenes: the main menu and the game scene. The
hierarchy of the game objects of the main menu scene is depicted in (Figure 15). The game objects
of the main menu scene account for GUI (Canvas and nested objects), audio and sound
management (BackgroundMusic and SoundManager).
Figure 15 Hierarchy of the main menu game objects [Made by author]
The hierarchy of the game objects of the game scene is demonstrated in (Figure 16). The
game objects of the game scene oversee GUI (Canvas and nested objects), game field (platforms,
background, decoration, foreground decoration). The enemy and player objects are separate game
objects with own nested objects. These objects relate to various checks ranging from ledge, wall,
30
ground to player and attack position checks. Several enemy objects like Enemy1, Enemy2 and
Enemy3 represent the number of enemy objects placed on the game field. This number might be
expanded, additionally, these objects inherit the same functionality and parameters thanks to the
super class “Entity”. UIManager game object is responsible for managing pause menu. Spikes
game object represents the nested objects being a parent object. SoundManager game object
handles seamless playing of the music transmitting from the main menu scene as well as
BackgroundMusic game object does. FinishPoint contains BoxCollider2D element in the inspector
which activates the trigger once the player collides this object. GameManager game object
accounts for managing respawn time, point, game object and its coordinates to respawn
accordingly. If the player dies, he respawns at a given point at a given cooldown time.
Figure 16 Hierarchy of the game scene objects [Made by author]
4.2 Implementation of the Player game object
The Player object accounts for the behavior and logic of the character controlled by the
user on the game field. Components like Sprite Renderer, Rigidbody 2D, Box Collider 2D,
Animator, Player Controller (Script), Player Combat Controller (Script), Player Stats (Script) are
31
connected to the Player object (Figure 17). The Animator controller component is an interface to
control the Mecanim animation system.
The Player Controller component (Script) accounts for the movement, jumping,
knockbacking, and wall sliding on the game field. It allows to assign the buttons for the movement
(CheckInput), constantly check the movement direction whether the player goes right or left, thus
depending on it, the character’s model would be flipped in the corresponding direction. The script
checks if the player can jump depending on the velocity, (isWallSliding, isGrounded). Concerning
the knockback, the player would be knockbacked if he gets damage from the enemy.
The Player Combat Controller component (Script) is responsible for the combat system of
the character. It defines attack radius, attack damage and the hitbox position of the hit. It assigns
the left mouse button as a hit action button and counts the input time to perform several animations
of swinging the character’s sword (CheckCombatInput).
The Player Stats component (Script) is responsible for player’s health statistics. It defines
maximum health of the player which can be adjusted in the inspector menu. Once the player gets
damage his current health would decrease (DecreaseHealth) according to the damage parameter
set in. When the player’s health reaches 0, the player dies, and his game object is destroyed and
respawn time starts counting until respawn. The demonstration of the structure of the player is in
Appendix 8.4.
4.3 Implementation of the Enemy game object
Enemy1, Enemy2, and Enemy3 game objects account for the behavior and logic of the
enemy acting in response to finite state machine model. Thanks to the super class mentioned in
the Design part of the bachelor’s thesis report, the number of states and functionality can be easily
expanded, thus new types of enemies can be created. These three game objects correspond to the
same enemy type. Components like Transform and Enemy1 (Script) are connected to Enemy1,
Enemy2, Enemy3. Additionally, these game objects have nested game objects “Alive”, and the
following components are attached to them: Transform, BoxCollider2D, RigidBody2D, Sprite
Renderer, Animator, and AnimationToStateMachine (Script) (Figure 18).
The Enemy1 component (Script) accounts for putting in action the states defined and
programmed in other classes. It puts moving, idling, detection, charging, looking for player, melee
attack, and dead states to (Start) method, and then the state machine can be configured in animator
controllers.
32
Figure 18 The Structure of the Enemy and nested Alive game object in Enemy object [Made by author]
4.4 Implementation of background and decorative elements
The object Grid is the parent of other nested objects like Platforms, Background,
Decoration, and Foreground Decoration. Grid a modular layout system which helps to align
GameObjects such as Tiles, based on a selected layout. The component transforms Grid cell
positions to the corresponding local coordinates of the GameObject [26]. A 2D tile game is any
game in which levels or play areas are made up of many small tiles (tiles) that together form a tile
grid. Using this system facilitates building a game level, for this purpose, the grid contains several
game objects which account for a couple of tile map layers. The Grid Component is attached to
the base game object Grid and is a foundation for tile map system in Appendix 8.5. All the game
level is divided in tiles; thus, it lets build it brick by brick (Figure 20).
33
Figure 20 The tile map wireframe view [Made by author]
The object Platforms accounts for displaying physical objects (grounds) on which the
player and enemies can stand, move around, or jump from one to another (concerns the player).
The Tilemap, Tilemap Renderer, RigidBody2D, Tilemap Collider 2D, Composite Collider 2D,
and FixGap (Figure 23).
The Tilemap component is used by the Unity engine to store sprites in a schema tagged by
the Grid component - in our case, the GameObject Platforms. The Tilemap Renderer component
assigns a material that will work for rendering tiles in the Tilemap.
The Tilemap Collider 2D component was created specifically for tiled 2D games on Unity.
It simply applies the shape of the physical collider to all the tiles of the layer to which it was added,
without doing any other work.
The Composite Collider 2D component would let get rid of unnecessary square colliders
in the middle of the walls.
The FixGaps component is needed to make apparent black lines to disappear which might
happen due to the small space between the blocks.
Additionally, to draw the tiles on the map field, it’s needed to add Tile Palette demonstrated
in Appendix 8.6.
34
Figure 23 The structure of the Platforms game object [Made by author]
The object Background accounts for displaying the background of the game application
throughout entire map.
The object Decoration oversees the depicting of non-interactive decorative objects on the
game field. They are used to diverse the game map and embellish the game playthrough.
The object Foreground Decoration is created to display non-interactive object on the game
field like grass, it’s used to fill in the platforms with details and decorate the game world.
Since these game objects have the same components, (Figure 24) demonstrates their
content on the example of Background game object.
35
Figure 24 The structure of the Background, Decoration, and Foreground Decoration [Made by author]
4.5 Implementation of the graphical interface
There are two main graphical interfaces implemented in the project but including the side
one: main menu, game view, and pause menu.
The main menu has an object Canvas which serves to display the elements of the graphical
interface (Appendix 8.7). The objects like Background, PlayButton, ExitButton,
SoundEffectsSlider, BackgroundSlider, Label, EffectsVolumePercantage,
BackgroundVolumePercantage are nested in Canvas in game object.
The object Background accounts for the background texture of the main menu and it’s
static. The objects PlayButton and ExitButton are buttons to start the game or exit it. The objects
SoundEffectsSlider and BackgroundSlider correspond to adjusting the volume of the sound effects
like hurt damage sound, whereas background slider allows to adjust the volume of the background
music. The object Label displays the name of the game title. The objects EffectsVolumePercantage
and BackgroundVolumePercantage are used to dynamically display the percentage of the volume.
The game menu has accordingly an object Canvas which contains the elements of the
graphical user interface to display (Appendix 8.8) The pause menu pops up when it’s called by
pressing the corresponding button, and it’s nested in the Canvas game object (Appendix 8.9). The
following objects Score, HealthBar, PauseBackground, PlayButton, RestartButton,
MainMenuButton.
36
The object Score oversees the displaying score of how many enemies have been killed in
total in one game session, every time the game process is relaunched, or the player dies, the score
is restored to zero.
The object HealthBar displays the current health of the player, it will decrease taking in
account damage that was dealt to the player. If the player’s health is 30 percent of the total health,
the health bar line will be colored in yellow, it indicates inadequate health. If the health bar color
is dark red, the player is dead.
The object PauseBackground displays the square background texture of the pause menu.
The objects PlayButton, RestartButton, and MainMenuButton are used to execute explicit
functions to resume the game process, restart the scene and to go to the main menu scene.
4.6 Implementation of the in-game animations
There are implemented the following animations in the game application for the player:
jumping and falling, wall sliding, attack of type 1, attack of type 2, idling and walking animations.
These animations occur by doing certain actions in the game by the player. The animation states
are implemented in Animator Controller. There is a built animation state machine schema in Unity
for every animation for the player (Figure 28).
The entry animation for the player is idling because the character won’t move until the
player starts to control him. From that state, player can start moving and then stop controlling the
character, thus that state would switch back to idling state. Since the jump, fall, wall sliding and
two types of attack animations can switch from any state, there is used “Any State” bar.
Additionally, if any of abovementioned animations are done, they would always switch to default
entry state animation “Idle”. The state machine is implemented via scripting Boolean parameters
isWalking, isGrounded, isWallSliding, isAttacking, firstAttack, attack1, canAttack. The changing
of the states is carried out by making transitions from states to states. On the example of idle and
walk animation states interconnections, if the player starts to move, isWalking Boolean parameter
would be true but if the player stops moving, isWalking would be false. All transitions work the
same pattern.
37
Figure 28 Animator Controller for the player game object [Made by author]
All animations are prepared in Animation Timeline window from the sequence of sprites.
These sprites are put on the timeline and break into frames at a given time interval on the example
of moving animation (Appendix 8.10.1). Every sequence of sprites is put on the timeline and
named to the corresponding animation name. For every animation sprite unit put on the timeline
would be created a frame and its time interval can be adjusted.
The enemy game objects have common animator controllers but different sprites for
animations. There was built a state machine schema for all animations of the enemy (Figure 30).
The transition between the states is described in States model of the enemy.
The state machine is implemented via scripting Boolean parameters idle, move,
playerDetected, charge, lookForPlayer, and meleeAttack. There are created transitions from states
to states.
Figure 30 Animation Controller for the enemy game object [Made by author]
To create an animation, the sprites should be put on the Animation Timeline (Appendix
8.10.2) to recreate the animation from the sequence of sprites on the time interval.
38
5 TESTING OF THE GAME APPLICATION
To check the workability of the game application, the following functional, nonfunctional
tests and usability-testing were conducted.
5.1 Functional testing
Functional testing – this is software testing to verify the implementation of functional
requirements, that is, the ability of software to solve problems required by users under certain
conditions [28, 29].
Testing №1. Changing game application settings.
Input data: the player moves the volume slider for music and effects.
Expected result: Changes in volume and effects.
Result: Same as expected.
The test passed successfully.
Testing №2. Transition between main menu and game scenes.
Input data: the player presses the “Play” button in the main menu.
Expected result: the transition from the main menu scene to the game scene.
Result: Same as expected.
The test passed successfully.
Testing №3. The exit from the game application.
Input data: the player presses the “Exit” button in the main menu
Expected result: the game application would be turned off.
Result: Same as expected.
The test passed successfully demonstrated in Appendix 8.10.3
Testing №4 Transition from the pause menu to main menu, resumption, or restart of the
game process.
Input data: player presses the corresponding button to pause the game, and from that menu
player can resume, restart or to go to the main menu.
Expected result: player restarts, resumes, or goes to the main menu by pressing the
corresponding buttons in the pause menu.
Result: Same as expected.
The test passed successfully demonstrated in Appendix 8.10.4.
Testing №5. Moving and attacking of the player’s character on the game field.
Input data: the player controls the character, tries to do jumping, wall sliding, attacking.
39
Expected result: movement, jumping, wall sliding and attacking of the character on the
game field
Result: Same as expected.
The test passed successfully demonstrated in Appendix 8.10.5.
Testing №6. Interaction with the enemies, combat mechanic, health system, and score
count.
Input data: the player controls the character, tries to hit, and destroy the enemy, get damage
from the enemy, die from the enemy and environmental barriers.
Expected result: while hitting the enemy, the enemy must knockback, get damage, and die
if the health is less or equal zero. The player must get damage from the enemy and see the current
health status on the health bar and die if the health is less or equal zero. The player must receive
points for each destruction of the enemy, and the score status must update in real time. Finally, the
player must instantly die from environmental barriers.
Result: Same as expected.
The test passed successfully demonstrated in Appendix 8.10.6.
Testing №7. Reaching the endpoint of the level and sending the player back to the main
menu.
Input data: the player controls the character, gets through the level, and reaches the
endpoint of the level.
Expected result: the game is finished, and the player is sent back to the main menu.
Result: Same as expected.
The test passed successfully demonstrated in Appendix 8.10.7.
5.2 Nonfunctional testing
Nonfunctional testing – is a software testing of properties that are not related to the
functionality of the system. These characteristics, which define non-functional requirements,
characterize predominantly the product from these sides like robustness, performance, scalability,
security, compatibility, portability, etc. [30]. These requirements characterize the quality of the
software system, which allows one way or another to leave an impression on the user that will
affect the popularity and rating of the developer company.
The testing is performed according to nonfunctional requirements described in the Table
5. The testing was performed on the following hardware:
• Screen resolution 13,3 inch (2560x1600)
• 2 Ghz Quad-Core Intel Core i5
40
• 16 GB 3733 MHz LPDDR4X
• Intel Iris Plus Graphics 1536MB
• Apple SSD AP1024N 1 TB
Framerate testing
According to the requirement, the framerate of the game mustn’t fall less than 60 fps.
Thanks to built-in performance monitoring tools in Unity game engine, the peak performance fps
is 637,3 FPS, 1.6ms (fig. 38) taking in account rendering the game in native resolution
(2560x1600).
Figure 36 The statistics showing the maximum framerate in the game [Made by author]
Installation and portability testing
The testing implies the verification of the successful installation of the application, its
configuration and removal. Additionally, reduction the risk of loss of user data, loss of application
performance, etc. Although target platform is MacOS which launches errorless, the game
application must launch on Windows. Thus, it was tested the availability of Windows build support
and it was discovered that there was no Windows build module, hence it was added. Eventually,
the building of the project for windows x86_64 architecture was successful. Compilation of the
project has created game folder with executable file in it, thus only unarchiving is required for
installation.
41
Figure 37 The Windows build of the application [Made by author]
Performance testing
The testing was performed by launching the game application and play through the game
level. During the game was launched, it didn’t consume more than 240MB of RAM, thus the
requirement of the game working with minimum 1024MB of RAM and not exceeding it was
fulfilled.
Figure 38. The activity monitor showing the consumption of RAM by the game application [Made by
author]
42
5.3 Usability-testing
Usability testing (ergonomics testing) is a method for assessing usability based on
attracting users as testers and summarizing the conclusions obtained from them [31].
Three users were recruited to complete this test. Testers were asked to solve the following
tasks:
• Change the settings of the game application
• Begin the game, exit the game, restart the game, resume the game, call the pause menu
• Go to the main menu from the pause menu
• Destroy all the enemies on the level
• Get through the level and reach the endpoint to finish the game
• Try jumping, wall sliding and bouncing between the walls
• Stumble into the environmental barriers on the game field
• Try to change the music and effects settings after return to the main menu
After the conduction the abovementioned tasks by the users, they passed almost all tasks
successfully except changing the volume of music and effects after the return to the main menu.
Users noted the intuitiveness of the controls and the rules of the game. Usability testing was almost
successful. The demonstration of the full game process can be found in Appendix 8.11.
Table 6 The list of tasks performed by users and the resulting output
Tasks Completion
Change of the in-game settings ✔
Begin the game, exit the game, restart the game, call the pause menu ✔
Going to the main menu through the pause menu ✔
Destruction of all enemies on map ✔
Performing jumping, wall sliding, and bouncing between the walls ✔
Stumbling into the environmental barriers ✔
Changing music after returning to the main menu ×
43
6 RESULTS AND CONCLUSIONS
6.1 Results
1. A development methodology was chosen, functional and nonfunctional requirements
were stated, use-case diagram was drawn, and prototypes were built.
2. The classes of the game application were designed and interconnection of states of the
enemy was elaborated.
3. The hierarchies of game objects were created for game menus. The enemy, player,
background, decorative, and GUI implementations were done. In-game animations were
created.
4. The developed functions and performance of the game application operate as meant
thanks to provided testing. The user-tested features have shown near-satisfactory results.
6.2 Conclusions
1. Thanks to conducted analysis of the subject area, similar analogs, contemporary game
engines, and methodology of the development, Unity game engine was chosen for
development process. After investigation of the vision of the game, project
requirements were determined, and game prototypes were constructed.
2. Developing various states implemented in classes of the enemy contributed to creating
decent artificial intelligence which responds to player’s actions, and it seems like it can
give one a challenge to beat it. Creating game states made it easier to understand the
game model by having a clear idea of where the beginning and end are.
3. By developing user interface, player, enemy, animations, background, and decorative
objects on the game scenes have created a single picture of what have been described
in vision and design chapters.
4. Owing to executed testing of the game application, the functional and nonfunctional
requirements have been fulfilled and usability-testing helped to find out drawbacks and
errors spotted.
6.3 Perspectives
The game product currently has its advantageous sides which can be improved in the future
by adding new functionality and diversity of game levels thanks to the technical foundation. It let
create assets which can be reused to broaden the current vision and enhance the game core. By
having developed programming skills and familiarization with the game environment, it will allow
to develop much more sophisticated game process along with new mechanics like weapon,
44
character in-game upgrade, dynamic complication of the game process through accounting the
number of character deaths as well as simplification of the game process by destroying bosses of
the levels, and encountering unique events depending on the state of the world. To execute it so,
it’s required to increase the number of members in the team to distribute the objectives and have
a clear understanding of how to reach all the tasks successfully and smoothly.
To match contemporary standards of the game industry, the game product can be iteratively
enhanced to constantly reproduce new content which will draw players’ attention and will not let
them get bored. Additionally, it’s possible to create a franchise if the game is highly liked, thus it
gives an opportunity to create a roadmap depicting how the game product would be growing with
the content, hence it would facilitate the pipeline of the development for the team.
45
7 REFERENCES
[1] Armory et al. "What Makes a Good Game?" 1999.
https://serc.carleton.edu/introgeo/games/goodgame.html.
[2] Anderson et al. “The Case for Research in Game Engine Architecture.”
http://eprints.bournemouth.ac.uk/24322/1/FP8GEA.pdf.
[3] 10 Types of Platforms in Platform Video Games. 22 October 2012.
https://www.idtech.com/blog/10-types-of-platforms-in-platform-video-games
[4] Loveridge, Sam. "20 Things you didn't know about Crash Bandicoot.". 9 September 2016.
https://www.digitalspy.com/videogames/a806253/20-things-you-didnt-know-about-crash-bandicoot/
[5] Gallagher, Jason. "10 Best Castlevania Games Ever Made". 26 September 2019.
https://www.denofgeek.com/games/10-best-castlevania-games-ever-made/
[6] Toftedahl, Marcus. “Which are the Most Commonly Used Game Engines?” 30 September 2019.
https://www.gamasutra.com/blogs/MarcusToftedahl/20190930/350830/Which_are_the_most_commonly
_used_Game_Engines.php
[7] Sicienski and Dealessandri. “What is the Best Game Engine: is Godot Right for You?” 15 April
2020. https://www.gamesindustry.biz/articles/2020-04-14-what-is-the-best-game-engine-is-godot-right-
for-you#section-1
[8] Anderson, Benjamin. “What is the Best Game Engine: is Godot Right for You?” 15 April 2020.
https://www.gamesindustry.biz/articles/2020-04-14-what-is-the-best-game-engine-is-godot-right-for-
you#section-2
[9] Sicienski, Marie. “What is the Best Game Engine: is Unity Right for You?” 16 January 2020.
https://www.gamesindustry.biz/articles/2020-01-16-what-is-the-best-game-engine-is-unity-the-right-
game-engine-for-you
[10] Petty, Josh. “Top 12 Free Game Engines for Beginners & Experts Alike.” 2020.
https://conceptartempire.com/free-game-engines/
[11] Brooklin, Nash. "Agile vs Waterfall: Learn the Differences in 5 Minutes." 7 April 2020.
https://www.trustradius.com/buyer-blog/difference-between-agile-vs-waterfall
[12] Fig 3 "Agile vs waterfall". 2019. https://unity.trustradius.com/wp-
content/uploads/agilevswaterfall.png
[13] Flower M. UML Distilled: A Brief Guide to the Standard Object Model- ing Language. –
USA: Addison-Wesley Publishing Company, 2004. – 150 p.
[14] Rambo Joe. UML 2.0. Объектно-ориентированное моделирование разработка [Object-
oriented model development] – СПб.: Питер [Saint-Peterburg], 2007. – 544 с.
[15] Tidwell J. Designing Interfaces. – USA: O’Reilly Media, 2004. – 578 p
46
[16] Larman K. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-
ориентированный анализ, проектирование и итеративную разработку [Application of UML 2.0
and patterns of design. Intorduction to object-oriented analysis, design, and iterative development – M:
Williams, 2013. – 736 с.
[17] Gold J. Object-Oriented Game Development. – UK: Pearson Education Limited, 2004. – 404
p.
[18] Gregory J. Game Engine Architecture. – USA: A K Peters/CRC Press, 2009. – 864 p.
[19] Unity3D Manual. [Electornical source] URL: http://docs.unity3d.com/Manual/index.html
(date of appeal: 29.04.2017).
[20] Gamma E., Helm R., Johnson R., Vlissids D. Object-oriented programming techniques.
Design patterns. - SPb.: Peter, 1994. -- 395 p.
[21] Gold J. Object-Oriented Game Development. – UK: Pearson Education Limited, 2004. – 404
p.
[22] Shora, Najmm. "State Pattern Usinng Unity". 8 January 2020.
https://www.raywenderlich.com/6034380-state-pattern-using-unity
[23] Cambell Joe. UML 2.0. Object-oriented programming C#. – SPb.: Peter, 2005. – 530 с.
[24] C# Programming Guide. [Electronical source] URL: https://msdn.microsoft.com/en-
us/library/67ef8sbd.aspx (date of appeal: 30.04.2017).
[25] Official Visual Studio website. [Electronical source] URL:
https://www.visualstudio.com/ru/vs/ (date of appeal: 28.04.2017).
[26] Official Unity documentation website. [Electronical source] URL:
https://docs.unity3d.com/Manual/class-Grid.html (1.01.2020).
[27] Fig 23 "The Tile Palette Configuration View" 31 May 2018.
https://hsto.org/getpro/habr/post_images/e9c/4c4/681/e9c4c46814518dadf262f42ceab70563.png.
[28] Kaner C., Bach J., Pettichord B. Lessons Learned in Software Testing. – USA: Wiley, 2001.
– 320 p
[29] Myers G., Budget T. The art of software testing. - M .: Williams, 2012 .-- 272 p.
[30] Non-functional Requirements: Examples, Types, How to Approach. [Electronical source].
https://www.altexsoft.com/blog/non-functional-requirements/. 24 November 2019.
[31] Vigens K., Beatty D. Development of software requirements. - M.: Russian Edition, 2014 .--
736 p.
47
8 APPENDIXES
8.1 Term Paper Abstract
ABSTRACT
Author Vdovenko Daniil
Title The Impact of Video Game Engines Implementation on a
Game Development Process
Supervisor Vytautas Barzdaitis
Presented at Vytautas Magnus University,
Faculty of Informatics, Kaunas
Number of
pages
25
To find out why game engines implementation in game development process is essential.
Discover architecture, approaches of creation of game engines, their kinds and expediency of using
ready-made technologies rather than developing new ones and how it impacts on game
development process.
8.2 The review of game development environments
Simple and complex 2D game engines
In this section, it will be reviewed the kinds of games which are easy enough to create,
nevertheless, you would have to learn the basics of the picked engine to create diverse levels,
design and artwork.
Below are the most popular and robust game engines available.
• Godot
This engine is open-source and fits for 2D game development, and it works well with 3D
too. Nonetheless, it transcends 2D games and reveals a strength like a dedicated 2D engine that
operates in pixel coordinates and makes 2D development easier to accomplish. The native
measurement in Godot, which is extraordinarily helpful when designing 2D pixel art games
48
[7]. The scripting language is inspired by Python, but Godot uses its own scripting language
called GDScript as well as featuring official support for C# and C++. Thus, it would be easy
to build a team of programmers thanks to these popular programming languages. On top of
that, the engine makes organizing your games easy by offering a scene and node system which
speed game development and improves the scalability of projects. Unfortunately, this engine
is not ready for complex 3D projects because currently, it lacks optimizations to render large
game worlds [8].
• GameMaker
This a high-end 2D game engine which is designed to be easy for beginners, and powerful
enough to accommodate the needs of a large studio. Unlike the “Corona” game engine, it can
produce AAA products, which means high-budget and large-scale products. It is quite a
versatile engine, puzzle-platformers engine and the pixel art engine. It supports a quite number
of platforms ranging from PS4 to HTML5. With GameMaker, you have seamless access to a
dedicated 2D physics engine, as well as the ability to play online, cross-platform deployment,
and stunning visuals using shaders. Unfortunately, it is not free but offers a 30-day trial license.
• Defold
This is an ultimate engine that offers a full package of what you may need for 2D game
development. It is packed with tools for web and mobile designers. It would take several hours
to get into the basics of the engine and then one is ready to start developing simple platformers,
arcade, text adventures, puzzles, and racing games.
• Corona
This 2D engine is designed for rapid prototyping and cross-platform deployment of
products that aim at beginners and mobile developers. By using this game engine, one avoids
learning complex processes that big IDE would require. Consequently, one should not count
on developing AAA games because it is just a good step into the game engine development
world.
Mixed and complex 3D game engines
The following game engines are mastodonts and perfectly suit for the development of
nearly any games one wants to. Some of them aim to deliver the best cross-platform experience
along with agile and robust AAA product development.
• Unity
49
Unity is an entrance to the go-to development environment for indie and mobile games.
This engine supports over 25 platforms ranging from iOS to Android TV. The real-time
development platform allows for the creation of 2D, 3D, VR, and AR content and the platform
reached 3 billion devices in the last 12 months [9]. Thanks to a powerful cross-platform toolset,
it becomes very easy to port products across all products as well as having comprehensible C#
scripting language. Unity uses pre-made assets and an advanced rendering engine which is
divided into SRP, HDRP, and LWRP. For SRP, it is designed to create a luxuriant video
sequence for 2D or 3D for mobile phones or consoles, and conduct optimization process for
specific hardware. Concerning HDRP, it is dedicated to high-performance PCs and consoles
whereas LWRP is intended for mobile devices. Unfortunately, one has to reconsider a choice
to develop AAA games, except AAA 2D games, using Unity due to heavy optimizations.
• Unreal Engine
This engine has a long story and is known to be one of the most polished and user-friendly
game engines for overwhelming high-quality game development. Unreal Engine uses C++
scripting language thus one can reap a great benefit from a programming knowledge
background. The engine may facilitate one’s development process by offering a variety of
tutorials to help beginners along with the asset marketplace which contains tools and models
to be used in their projects [10]. The platform proposes raytracing which means the next-gen
experimental lighting which depicts real-time reflection from each object in the scene as well
as real-time technology which permits to receive data in the real-time that a physical procedure
happens. On top of that, the engine is a perfect fit for AAA development due to it is very great
for large-scale games, but it is very abundant for very small games, otherwise, some
development processes may run slowly and not efficient, thus, Unity better suits here. The key
technological advantage of the engine is photorealism which leaves one unsure about whether
it’s a real-life image of it created from scratch.
• CryEngine
It is a state-of-the-art game engine that offers all technologies from Unreal Engine, but it
is known to be complicated to use and challenging to master than most engines. It is a must-
use for VR and AR development by demonstrating highly detailed and super realistic
characters. It’s worth mentioning that it excels at shooters and first-person games, but it is not
restricted to them, therefore, it supports a quite variety of genres and formats
50
8.3 PlayerController code example
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using static UnityEngine.Mathf;
public class PlayerController : MonoBehaviour
{
private float movementInputDirection;
private float knockBackStartTime;
[SerializeField]
private float knockbackDuration;
private int amountOfJumpsLeft;
private int facingDirection = 1;
private bool isFacingRight = true;
private bool isWalking;
private bool isGrounded;
private bool isTouchingWall;
private bool isWallSliding;
private bool canJump;
private bool canFlip;
private bool knockback;
[SerializeField]
private Vector2 knockbackSpeed;
private Rigidbody2D rb;
private Animator anim;
public int amountOfJumps = 1;
public float movementSpeed = 10.0f;
public float jumpForce = 16.0f;
public float groundCheckRadius;
public float wallCheckDistance;
public float wallSlideSpeed;
public float movementForceInAir;
public float airDragMultiplier = 0.95f;
public float variableJumpHeightMultiplier = 0.5f;
51
public float wallHopForce;
public float wallJumpForce;
public Vector2 wallHopDirection;
public Vector2 wallJumpDirection;
public Transform groundCheck;
public Transform wallCheck;
public LayerMask whatIsGround;
// Start is called before the first frame update
void Start()
{
rb = GetComponent<Rigidbody2D>();
anim = GetComponent<Animator>();
amountOfJumpsLeft = amountOfJumps;
wallHopDirection.Normalize();
wallJumpDirection.Normalize();
}
// Update is called once per frame
void Update()
{
CheckInput();
CheckMovementDirection();
UpdateAnimations();
CheckIfCanJump();
CheckIfWallSliding();
CheckKnockback();
}
private void FixedUpdate()
{
ApplyMovement();
CheckSurroundings();
}
private void CheckIfWallSliding()
{
if (isTouchingWall && !isGrounded && rb.velocity.y < 0)
52
{
isWallSliding = true;
}
else
{
isWallSliding = false;
}
}
private void CheckSurroundings()
{
isGrounded = Physics2D.OverlapCircle(groundCheck.position,
groundCheckRadius, whatIsGround);
isTouchingWall = Physics2D.Raycast(wallCheck.position,
transform.right, wallCheckDistance, whatIsGround);
}
private void CheckIfCanJump()
{
if((isGrounded && rb.velocity.y <= 0) || isWallSliding)
{
amountOfJumpsLeft = amountOfJumps;
SoundManagerScript.PlaySound("playerJumpEffect");
}
if(amountOfJumpsLeft <= 0)
{
canJump = false;
}
else
{
canJump = true;
}
}
private void CheckMovementDirection()
{
if(isFacingRight && movementInputDirection < 0)
{
Flip();
}
53
else if(!isFacingRight && movementInputDirection > 0)
{
Flip();
}
if(Mathf.Abs(rb.velocity.x) >= 0.01f)
{
isWalking = true;
}
else
{
isWalking = false;
}
}
private void UpdateAnimations()
{
anim.SetBool("isWalking", isWalking);
anim.SetBool("isGrounded", isGrounded);
anim.SetFloat("yVelocity", rb.velocity.y);
anim.SetBool("isWallSliding", isWallSliding);
}
private void CheckInput()
{
movementInputDirection = Input.GetAxisRaw("Horizontal");
if (Input.GetButtonDown("Jump"))
{
Jump();
}
if (Input.GetButtonUp("Jump"))
{
rb.velocity = new Vector2(rb.velocity.x, rb.velocity.y *
variableJumpHeightMultiplier);
}
}
private void Jump()
{
if (canJump && !isWallSliding)
54
{
rb.velocity = new Vector2(rb.velocity.x, jumpForce);
amountOfJumpsLeft--;
}
else if (isWallSliding && movementInputDirection == 0 && canJump)
//Wall hop
{
isWallSliding = false;
amountOfJumpsLeft--;
Vector2 forceToAdd = new Vector2(wallHopForce *
wallHopDirection.x * -facingDirection, wallHopForce * wallHopDirection.y);
rb.AddForce(forceToAdd, ForceMode2D.Impulse);
}
else if((isWallSliding || isTouchingWall) &&
movementInputDirection != 0 && canJump)
{
isWallSliding = false;
amountOfJumpsLeft--;
Vector2 forceToAdd = new Vector2(wallJumpForce *
wallJumpDirection.x * movementInputDirection, wallJumpForce *
wallJumpDirection.y);
rb.AddForce(forceToAdd, ForceMode2D.Impulse);
}
}
private void ApplyMovement()
{
if (isGrounded && !knockback)
{
rb.velocity = new Vector2(movementSpeed *
movementInputDirection, rb.velocity.y);
}
else if(!isGrounded && !isWallSliding && movementInputDirection
!= 0)
{
Vector2 forceToAdd = new Vector2(movementForceInAir *
movementInputDirection, 0);
rb.AddForce(forceToAdd);
if(Mathf.Abs(rb.velocity.x) > movementSpeed)
{
55
rb.velocity = new Vector2(movementSpeed *
movementInputDirection, rb.velocity.y);
}
}
else if(!isGrounded && !isWallSliding && movementInputDirection
== 0)
{
rb.velocity = new Vector2(rb.velocity.x * airDragMultiplier,
rb.velocity.y);
}
if (isWallSliding)
{
if(rb.velocity.y < -wallSlideSpeed)
{
rb.velocity = new Vector2(rb.velocity.x, -
wallSlideSpeed);
}
}
}
public void DisableFlip()
{
canFlip = false;
}
public void EnableFlip()
{
canFlip = true;
}
private void Flip()
{
if (!isWallSliding && !knockback)
{
facingDirection *= -1;
isFacingRight = !isFacingRight;
transform.Rotate(0.0f, 180.0f, 0.0f);
}
}
public void Knockback(int direction)
{
knockback = true;
knockBackStartTime = Time.time;
56
rb.velocity = new Vector2(knockbackSpeed.x*direction,
knockbackSpeed.y);
}
private void CheckKnockback()
{
if(Time.time >= knockBackStartTime+knockbackDuration &&
knockback)
{
knockback = false;
rb.velocity = new Vector2(0.0f, rb.velocity.y);
}
}
private void OnDrawGizmos()
{
Gizmos.DrawWireSphere(groundCheck.position, groundCheckRadius);
Gizmos.DrawLine(wallCheck.position, new
Vector3(wallCheck.position.x + wallCheckDistance, wallCheck.position.y,
wallCheck.position.z));
}
57
8.4 The structure of the player game object
Figure 17 The structure of the player game object
8.5 The grid component for the game level
58
Figure 19 The grid component for the game level
8.6 The tile palette configuration and actual views
This is done by opening the editor and clicking Window -> Tile Palette to open the 2D
Tile Palette window. The work with the tiles is impossible without this window when working
on tile games in Unity (Figure 21). The following list presents the functionality of the tile palette:
1. This series of icons provides basic tile manipulation, painting, and deletion tools.
2. This selector allows us to create different palettes, which can be thought of as
drawing palettes, in which we place "colors", and in this case, tiles.
3. This selector allows you to create brushes with different behaviors. You can add your
own brushes, the behavior of which differs from the default brush (for example,
painting prefab tiles with additional functionality)
Figure 21 The Tile Palette configuration view [27]
The following (Figure 22) presents the actual view of the tile palette that was used to
draw the game map. There are presented all the decorative items and blocks which may be seen
during the gameplay.
59
Figure 22 The Tile Palette actual view with decorative items
8.7 The graphical user interface for the main menu
Figure 26 The graphical user interface for the main menu
60
8.8 The graphical user interface for the game menu
Figure 27 The graphical user interface of the game menu
8.9 The graphical user interface for the pause menu
Figure 27 The graphical user interface of the pause menu
61
8.10 Animations
8.10.1 Demonstration of the animation frames on the timeline of the player
Figure 29 Demonstration of the animation frames on the timeline of the player
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EYOhj03qfO1InxQvghJ5S4MBcR1sd
TQtRWsHp1opBHCblQ?e=KuYlNQ
8.10.2 Demonstration of the animation frames on the timeline of the enemy
Figure 31 Demonstration of the animation frames on the timeline of the enemy
62
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EWKZ0DpbqtRGsePuQkI8RagBNdvB
qwUGeuZWaahhQ4HP2Q?e=RmBMtd
8.10.3 The demonstration of the main menu tested functions
Figure 31 The demonstration of the main menu tested functions
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EauzAz2XJMtKucG7fNHUoLcBiIhYo
yaSV6keNtR6d3jH9w?e=yRpeFN
8.10.4 The demonstration of the pause menu tested functions
Figure 32 The demonstration of the pause menu tested functions
63
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EZ9k02k7ppFNh4xEO8uREqwB8KLu
TUQGSGOREZPVsmxXJA?e=4qIynI
8.10.5 The demonstration of the tested functions of the player
Figure 33 The demonstration of the tested functions of the player
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EauzAz2XJMtKucG7fNHUoLcBiIhYo
yaSV6keNtR6d3jH9w?e=yRpeFN
8.10.6 The demonstration of the tested functions of the combat and interaction
64
Figure 34 The demonstration of the tested functions of the combat and interaction
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EWUIM5trp3ZKohfAmzQ6gmkBWqO
NaOH-uELTY335emjAxQ?e=avPwUb
8.10.7 The demonstration of the tested functions of finishing the game by
reaching the endpoint in the level
Figure 35 The demonstration of the tested functions of finishing the game by reaching the endpoint in the
level.
https://vduedu-
my.sharepoint.com/:i:/g/personal/daniil_vdovenko_vdu_lt/EVG987KWPyZDvzbt3hltrcEBkcc7PI
5pj1SjGcoDJBzZ_g?e=daBBrg
65
8.11 Sources
The video demonstration of the game process:
https://vduedu-
my.sharepoint.com/:v:/g/personal/daniil_vdovenko_vdu_lt/EfHmXBMLfBVJpOTzkj4nzZwBx6
smqcg_E8QdMSG9d7pcUA?e=AX8vE1
The project has been pushed to GitHub:
https://github.com/ichbinkaz/dungeon-game.git