engineer-thesis-WUT/Thesis/Thesis.tex

\documentclass[a4paper,11pt,twoside]{report}
% From specification:
% kroj bezszeryfowy rozmiar 11
% Druk dwustronny A4
% Pod rozdzialy do trzech poziomow -> domyslnie zalatwione przez latexa 
% Rozdzialy poziomu I od nowej strony -> domyslnie przez latexa 
% Wyliczenia -> tylko kropka lub myslnik -> tylko kropka domylsnie przez latexa

\usepackage{ulem}
\usepackage{fontspec}
\usepackage{anyfontsize}
\usepackage{graphicx}
\usepackage{geometry}
\usepackage{leading}
\usepackage[nottoc]{tocbibind}
\usepackage{titleps}
\usepackage{float}
% From specification:
% Tytuł tabeli
% Umieszczony nad tabelą (manually by setting caption above table)
% Justowany do lewej -> raggedright
% Czcionka bezszeryfowa rozmiar 9 -> footnotesize (see: https://www.sascha-frank.com/latex-font-size.html)
% Podpis rysunku -> pod rysunkiem (manually by setting caption below table)
% Źródło rysunku/tabeli -> Pod rysunkiem lub tabelą (manually by setting caption below table)
% Przypis dolny -> numeracja ciagla w calej pracy, kroj bezszeryfowy analogiczy jak w tekscie, rozmiar 9
\usepackage[font=footnotesize, justification=raggedright]{caption}
\usepackage{svg}
% Kroj pisma tytulow glownych rozdzialow
% pogrubiony bezszeryfowy -> wyzej
% tytul 1 poziomu 14
% tytul 2 poziomu 13
% tytul 3 poziomu 12
\usepackage{sectsty}

\chapterfont{\fontsize{14}{14}\selectfont}

\sectionfont{\fontsize{13}{13}\selectfont}

\subsectionfont{\fontsize{12}{12}\selectfont}


% From specification:
% Numeracja tabel i rysunków:
% Ciagła w całej pracy <-----
% Kolejna w rozdziałach
\usepackage{chngcntr}
\counterwithout{figure}{chapter}
\counterwithout{table}{chapter}

% From specification:
% Odwołania do źródeł
% Styl numeracyjny wg normy PW
% OR Styl Harwardzki <-----
% Bibliografia w układzie alfabetycznych wg nazwisk autorów (has to be ensured manually)
\usepackage{natbib}
\usepackage{hyperref}
\hypersetup{
    colorlinks=true,
    linkcolor=blue,
    filecolor=magenta,      
    urlcolor=cyan,
    pdftitle={Overleaf Example},
    pdfpagemode=FullScreen,
    }
\bibliographystyle{agsm}

% From specification:
% Numeracja stron:
% U dolu
% Po zewnetrznej stronie
% Odbicie lustrzane na stronach parzystych i nie parzystych
\renewpagestyle{plain}{%
\sethead{}{}{}
\setfoot[\thepage][][]{}{}{\thepage}
}%
\pagestyle{plain}

% From specification:
% kroj bezszeryfowy rozmiar 11
\renewcommand{\familydefault}{\sfdefault}

% From specification:
% Akapit wciecie 0.5 cm  <-----
% OR bez wciecia z odstepem 4 przed akapitem
\setlength{\parindent}{0.5cm}






% From specification:
% Marginesy:
%   wewnetrzny - 30 mm
%   Zewnetrzny - 20 mm
%   Gorny/dolny - 25 mm 
 \geometry{
    inner=30mm, 
    outer=20mm,
    top=25mm,
    bottom=25mm,
 }
\graphicspath{ {./images/} }


\newenvironment{centereq}[1][0.90]
 {%
  \trivlist
  \centering
  \setlength{\leftskip}{\dimexpr(\columnwidth-#1\columnwidth)/2\relax plus 1em}%
  \setlength{\rightskip}{\leftskip}%
  \item\relax
 }
 {\endtrivlist}




\fontfamily{helvet}\selectfont
% \newfontfamily{\adagio}{Adagio_Slab}
% \newfontfamily{\adagioLight}{Adagio Slab Light}
% \newfontfamily{\helveticaLight}{HelveticaLTStd-Light}
% \newfontfamily{\helvetica}{Helvetica}
\newcommand{\tytul}{
    Creating multiplatform match three game engine
}
\newcommand{\tytulEng}{
    Example of creation of multiplatform apps on basis of creating match-three game engine
}
\begin{document} 
\begin{titlepage}
\begin{minipage}{0.9\textwidth}%
    \begin{center}
        {\fontsize{24}{24}\adagio Warsaw University of Technology }
    
    
        \end{center}
        \begin{center}
            {\fontsize{12}{12}\adagio \addfontfeature{LetterSpace=41.0} FACULTY OF ELECTRONICS AND INFORMATION TECHNOLOGY}
            
        \end{center}
    \end{minipage}
\begin{minipage}{0.1\textwidth}%
    \includegraphics[width=25mm, height=25mm]{logo.jpg}%
    \end{minipage}
    \\[100pt]



    \begin{center}
    {\fontsize{43}{43}\adagioLight Bachelor's diploma thesis}
    \\[24pt]
    {\fontsize{12}{12}\helveticaLight in the field of study Computer Science} 

    {\fontsize{12}{12}\helveticaLight and specialization Computer Systems and Networks \\[50pt]} 
    
    
    {\fontsize{14}{14}\helvetica \tytul \\[50pt]} 

    {\fontsize{12}{12}\helveticaLight numer pracy według wydzia{\fontsize{12}{12}\adagioLight ł}owej ewidencji prac \{liczba\} \\[12pt]} 

    {\fontsize{21}{21}\helvetica Krzysztof Rudnicki  \\[12pt]}

    {\fontsize{12}{12}\helveticaLight numer albumu 307585 \\[24pt]}

    {\fontsize{12}{12}\helveticaLight promotor }

    {\fontsize{12}{12}\helvetica dr hab. inż. Tomasz Martyn \\[12pt]}

    {\fontsize{12}{12}\helveticaLight konsultacje }

    {\fontsize{12}{12}\helvetica dr hab. inż. Tomasz Martyn \\[40pt]}

    {\fontsize{12}{12}\helveticaLight Warszawa 2023}
\end{center}


    
\end{titlepage}


\subsubsection{Streszczenie pracy}
{\fontsize{12}{12}
\tytul \\
\{SLOWA KLUCZOWE\}
}
\newpage
\subsubsection{Thesis abstract}
\fontsize{12}{12}{\tytulEng \\
\{KEYWORDS\}
}

\tableofcontents

\chapter{ Introduction }
\section{Background and Motivation}
Among us, computer science students, video games were—and still are—one of the driving forces pushing us into the field of IT. Video games allow people with technical background to express their artistic side and create visually stunning projects. In particular "Match Three" games, characterized by their intuitive mechanics and satisfying gameplay, have attracted millions of players around the globe. They offer statisfying experience of aligning three or more similar game pieces, often resulting in gratyfying chain reactions. This lead to success of titles like "Candy Crush Saga" and "Bejeweled", staple titles for both mobile and desktop market.

\begin{figure}[h]

\includegraphics[scale=0.5]{allgates}
\caption{Minecraft redstone offers introduciton to logical gates \cite{raspberrypi2023}}
\end{figure}

Match three games are from technological point of view relatively easy to make, despite that there is no dedicated open-source game engine designed just for them. This engineering thesis aims to fill this void, to give back to the world of game developers and open-source projects.

Another motivation is a chance to learn one of the most popular graphical API - OpenGL, It is a graphical API which proved useful again and again with video game engines, rendering engines or for desktop applications.



\section{Scope of the Thesis}
Game development is a broad spectrum, This section aims to define to what extent the game engine will be developed

\subsection{Game Engine Focus: Match Three Genre}

While game engines can be created for multiple game genres, this thesis focuses on Match Three genre. This decision comes from its ease of implementation, combined with relatively high popularity and applicability on all platforms. We will focus on core logic, rendering techniques, and controls focused on Match Three games.

\subsection{Multiplatform Development}

Another important part of the thesis is multiplatform game development. We will focus on three major desktop operating systems: Windows, Mac, and GNU/Linux. The challenges associated with creating an uniform gaming experience across these platforms, taking into consideration differences in architecture, functionality and graphics.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.50]{platforms.png}
\caption{Logos of platforms we will be focusing on, from left: Windows, Mac and Linux \cite{platforms}}
\label{}
\end{figure}

\subsection{Tool and Library Integration}

This thesis will make biggest use of OpenGL API together with libraries: GLFW, GLAD, FreeType, stb\_image, and ft2build. In order used for platform-independed creation of windows, context and handling inputs, loader for OpenGL, library for rendering text, library for loading images and library for building free type sources. Later in the thesis we will dvelfe deeper into those libraries

\begin{figure}[htp]
\centering
\includegraphics[scale=1.00]{images/glfw.png}
\caption{GLFW project logo \cite{glfwLogo} }
\label{}
\end{figure}

\subsection{Theoretical and Practical Exploration}

Main portion of this thesis is practical implementation, still we are going to explore theoretical concepts crucial for game engine development.

\subsection{Limitations}

Since the engine aims to be simple and robust, it will not contain every possible feature or optimization like in commercial-grade game engines. The primary intent is to create a solid structure for which further advancements can be made.

In conclusion, this thesis goal is to provide an understanding of multiplatform Match Three game engine development. By setting managable boundaries, it aims to dive deep into specific challenges, tools, and solutions, providing valuable insights for aspiring engine developers. Next sections will further describe the objectives, methodologies, and findings of this exploration into the world of game development.

\section{Objectives of the Thesis}
Clear objectives allow for accomplishments that can be measured. Therefore it is important to define goals that underpin this thesis. In this section, we describe the primary goals of this thesis.

\subsection{Design of a Cross-Platform Core Architecture}

The foremost objective is to design a core multiplatform engine architecture. This demands a good understanding of the operating systems differences, from their system calls to their graphics pipelines. The engine should be modular and scalable, in order to make sure that the core mechanics and logic can be implemented across Windows, Mac, and GNU/Linux platforms.

\subsection{Effective Integration of Libraries}

With numerous libraries at our disposal, an important goal is to combine them into the engine in a cohesive manner. We will make use of GLFW for window management, GLAD for OpenGL function pointers, FreeType and ft2build for text rendering, and stb\_image for image handling. In addition to integrating them into an engine, these libraries must operate in such a way that they complement each other to improve the engine's overall performance and capability.

\subsection{Development of Core Match Three Mechanics}

Architecture and libraries used form the skeleton, the Match Three mechanics are the most important part of the engine. The aim is to create algorithms and techniques to take care of typical Match Three functionalities – from matching detection to gravity-induced piece drops and chain reactions.

\subsection{Providing a Blueprint for Future Development}

While the first objective is the engine's development, a broader goal is to expand upon created engine. By addressing challenges and sharing solutions, this thesis hopes to offer an example for engine developers. Whether they wish to enhance this engine or create new game engines. This thesis tries to improve their understanding of the topic

\section{Match Three Games and Engines}
The world of video games is vast and varied, Offering anything from massive multiplayer role playing games to small mobile puzzles. Match Three games offer players a blend of strategy, pattern recognition, and instant gratification. To better understand the significance of our task in creating a multiplatform Match Three game engine, it's important to trace how the genre evolved, understanding its roots, its development, and its appeal.

\subsection{Origins and Early Forerunners}

Match Three games owe their existence to the broader genre of tile-matching video games. The earliest entrants in this category were games like "Tetris" in the 1980s, where players manipulated falling blocks to create complete lines. "Tetris" kickstarted games focused on spatial reasoning and pattern recognition.

Expandin on this formula, 1980s and 1990s saw games like "Columns" and "Dr. Mario". These games introduced the mechanic of matching three or more identical items, but they were still using the falling-block paradigm. The true prototype of modern Match Three mechanics can be credited to "Shariki," a 1994 game where players swapped adjacent pieces to form chains of three or more identical items.

\subsection{Mainstream Adoption and Innovations}

In 2001 game titled "Bejeweled" came out. Simplifying and refining the mechanics of "Shariki", "Bejeweled" was the first mainstream success of Match Three genre. It provided intuitive gameplay,  visually appealing graphics and set the benchmark for games that followed.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.50]{images/bejeweld.jpg}
\caption{Bejeweled gameplay \cite{bejeweledGameplay} }
\label{}
\end{figure}

The success of "Bejeweled" lead to several innovation. Developers experimented with various twists on the core mechanics. Games introduced power-ups, barriers, objectives, and narrative elements. "Candy Crush Saga", released in 2012, integrated a level-based progression system, increasing the genre's complexity and depth.

\subsection{Technological Influences and Platform Diversification}

The evolution of Match Three games is interlocked with technological improvements in the gaming industry. Initially developed to PCs and consoles, the rise of mobile devices opened a new opportunities for the genre. The touch interface of smartphones and tablets proved to be an ideal medium for the drag-and-swap mechanics of Match Three games.

At the same time, browser-based games, using technologies like Flash, allowed players to engage with Match Three puzzles without heavy downloads or installations. As technology progressed, the need for engines that worked on multiple platforms – mobile, browser, consoles and desktop – became apparent.

\subsection{Enduring Appeal and Contemporary Significance}

Despite multiple competing genres, Match Three games remain popular. Their success can be attributed to their 'easy to learn, hard to master' trait. The games offer immediate rewards – the satisfaction of creating a match, beauty of pieces disappearing, and the strategic depth of planning several moves ahead. Additionally, the modular nature of their design allows for easy adaptation, whether it's incorporating a narrative, integrating with popular cultures, or tailoring to specific demographics.

In conclusion, the history of Match Three games is a proof to their adaptability and universal charm. They established themselves as one of the most recognizable genres in mobile and desktop gaming, they continue to gather players. This perspective marks significance of engines tailored to Match Three games specificaly.
\section{Overview of Multiplatform Game Development}
Game developres try to reach wider audiences by ensuring that their creations are accessible across a variety of operating systems. Multiplatform game development aims to deliver the same experience to different user bases. This section describes challenges and methodologies connected with multiplatform game development.

\subsection{The Need for Multiplatform Development}

There are three main operating systems, Windows, Mac, and GNU/Linux which together are responsible for over 90\% of desktop market share \cite{marketShareChart}, the potential to reach a bigger audience increases when a game is made available across all of these platforms.

\begin{figure}[H]
\centering
\includegraphics[scale=0.50]{chart.png}
\caption{Desktop OS market share worldwide \cite{marketShareChart}}
\label{}
\end{figure}

\subsection{Challenges in Multiplatform Development}

Idea of developing once and deploying everywhere comes with its set of challenges:
\begin{itemize}
    \item Hardware Disparity: Different platforms might have varying hardware specifications, which can influence the game's performance.
        \item OS Specific Limitations: Each operating system operates under its own rules, from system calls to user interface.
        \item Toolchain Variability: Development tools and libraries might have platform-specific versions or may not be available for all platforms.
\end{itemize}

\subsection{Tools and Libraries for Cross-Platform Development}

In order to face multiplatform development challenges, we use a set of tools and libraries. Libraries like OpenGL offer an unified graphics rendering solution, while GLFW enforces consistent window management and input handling. stb\_image, and ft2build are other libraries that offer consistent behavior across platforms for handling images and font rendering.

\subsection{Strategies for Effective Multiplatform Development}

\begin{itemize}
    \item Modular Design: By dividing the game engine into distinct modules, developers can isolate platform-specific code, ensuring that core logic remains unchanged by platform dependencies.
        \item Continuous Integration and Testing: Automated testing across platforms can identify inconsistencies, ensuring that the game offers an uniform experience.
        \item Community Engagement: Using the community that uses the game engine across multiple platforms offers developers insights into existing bugs and potential optimizations
    \end{itemize}

\subsection{Future Trajectory of Multiplatform Development}

With the cloud gaming on the rise, ressurection of web-based games, and increasingly powerful mobile devices, multiplatform development's scope is constantly expanding. There will be newer platforms and more varied devices to handle. The goal will remain the same: ensuring that games offer a consistent, engaging, and seamless experience, independent of the platform.

Multiplatform game development requires technological knowledge and good design. By understanding its challenges and methodologies, developers are better equipped to face-on multiple platforms of modern gaming. This foundation will become crucial later into the development of our multiplatform Match Three game engine.
\section{Existing Game Engines and Their Limitations}
The gaming industry has seen rise of various game engines, each offering a unique set of tools and functionalities for different needs. While these engines have facilitated the creation of iconic games, they also come with certain limitations, especially concerning specific genres or platforms. This section will describe prominent game engines and analyze their shortcomings, providing a reference for our multiplatform Match Three game engine.

\subsection{Unity Game Engine}

\begin{figure}[htp]
\centering
\includegraphics[scale=0.25]{images/unity.png}
\caption{Unity engine logo \cite{unityLogo}}
\label{}
\end{figure}

Unity is one of the most popular game engines available today. It's known for its versatility, supporting a wide range of platforms, from PCs to consoles to mobile devices.

\begin{itemize}
   \item Strengths: Plenty of community resources, a vast asset store, and an intuitive interface make Unity a popular choice among both beginners and professional developers.
     \item  Limitations: Unity's all-purpose nature might introduce unnecessary load for simpler games, like Match Three titles, potentially impacting performance.
        \end{itemize}

\subsection{Unreal Engine}

\begin{figure}[htp]
\centering
\includegraphics[scale=0.10]{images/unreal.png}
\caption{Unreal engine logo \cite{unrealLogo}}
\label{}
\end{figure}

Epic Games' Unreal Engine stands out for its impressive graphical capabilities, often employed in AAA game titles.

Strengths:
\begin{itemize}
    \item Blueprints: Blueprint visual scripting system allows for easier game development especialy for non-technical users
    \item Graphics: Unreal Engine offers top-tier rendering capabilities, which makes it ideal for creating visually stunning games.
\end{itemize}

Limitations:
\begin{itemize}
\item Learning Curve: Its advanced features can be overwhelming for beginners.
\item Simpler Genres: As with Unity, for a simple game like Match Three game, the engine might be too sophisticated, leading to longer load times and increased resource consumption compared to custom solution.
\end{itemize}

\subsection{Godot}

\begin{figure}[H]
\centering
\includegraphics[scale=0.05]{images/godot.png}
\caption{Godot game engine logo \cite{godotLogo}}
\label{}
\end{figure}

Godot is the biggest multipurpose game engine that is also free and open-source.

Strengths:
\begin{itemize}
\item No licensing: Godot is free to use
\item Open: Godot source code can be accessed and modified by anyone
\item Community: As with many open source projects community offers huge support for potential developers
\end{itemize}
    Limitations:
\begin{itemize}
        \item Limited professional presence: While unity and unreal dominate professional market, Godot is a less popular alternative
		\item Scalability: Godot game engine is not famous for building big game projects
\end{itemize}

\subsection{RPG Maker and Ren'Py}

\begin{figure}[htp]
\centering

\begin{minipage}{0.5\textwidth}
\centering
\includegraphics[scale=0.25]{images/renpy.png}
\caption{Ren'Py engine logo \cite{renpyLogo}}
\label{fig:renpylogo} % You might want to give a label for future referencing
\end{minipage}%
\begin{minipage}{0.5\textwidth}
\centering
\includegraphics[scale=0.25]{images/rpgMaker.jpg}
\caption{RPG Maker engine logo \cite{rpgMakerLogo}}
\label{fig:rpgmakerlogo} % You might want to give a label for future referencing
\end{minipage}

\end{figure}


RPG Maker and Ren'Py are examples of game engines focusing on one genre of games.
RPG Maker focues on top-down rpg games, while ren'py aims to ease the process of making visual novel games. Both of those engines were used with commercial and critical success, with creation of games like "To The Moon" and "Doki Doki Literature Club". Their limitations are both their strenght and weaknesses, allowing to speedup development process but blocking the developer for leaving the area of interest for those engines.

\subsection{Limitations}

While each game engine has its unique strengths and weaknesses, some common limitations come apparent when considering the development of a specialized game like a Match Three title, those engines either do not allow for match three development (RPG Maker or Ren'Py) or deliver match three titles with too much technological bloat (Unity/Unreal/Godot)

While existing game engines offer a lot of tools and capabilities, there exists a space for specialized engines made for specific genres. Recognizing the limitations of mainstream engines explains development of our multiplatform Match Three game engine, which tries to fix these gaps while providing an easy development.
\chapter{Basics of Game Engine Design}
\section{Core Components of Game Engines}

Game engines serve as the backbone for game development, providing a selection of tools and features that simplify the process of creating a game from scratch. At the heart of every game engine lie its core components, which define its capabilities, flexibility, and performance. This section explains those elements that we are going to implement in our engine.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.50]{images/gameEngineComponents.drawio.pdf}
\caption{Components used in our game engine}
\label{}
\end{figure}


\subsection{Rendering Engine}


The rendering engine is responsible for all visual aspects within a game. It takes the game's data – including textures and shaders – and converts them into pixels on the screen.

\begin{itemize}
    \item Role: Ensures that all visual elements, from static backgrounds to animations, are displayed with clarity, smoothness, and consistency.
    \item Key Features: Supports various rendering techniques such as ray tracing, rasterization, and shadow mapping to enhance visual quality.
\end{itemize}

\subsection{Input Handling}

Games are interactive by nature, and this interaction is delivered by the engine's input handling system.

\begin{itemize}
    \item Role: Processes user inputs from various sources, like a keyboard, mouse, gamepad, or touch screen. Translates these inputs into in-game actions or commands.
    \item Key Features: Detects multiple simultaneous key presses, supports touch gestures, and allows for input remapping.
\end{itemize}

\subsection{Transformations}
In order for object in game to move, game engine must handle its position on screen, this is a job of transformation system
\begin{itemize}
	\item Role: Move objects based on user input, delete, add and modify existing coordinates
	\item Key Features: Matrices and vectors calculation
\end{itemize}

Each component of game engine plays a different role, in combination they ensure that the game runs smoothly, offers an enjoyable experience, and responds to user interactions. These core parts form the foundation upon which our multiplatform Match Three game engine will be built and updated.
\section{The Role of OpenGL in Game Development}
Game engines need graphics libraries, those libraries provide the necessary tools to bring visual elements to the screen. Among these libraries, OpenGL (Open Graphics Library) has established itself as one of the most popular choices for graphics rendering. This section explores the role of OpenGL in game development, focusing on library functionalities and how they can be used.

\subsection{Introduction to OpenGL}

OpenGL is a cross-language, cross-platform application programming interface (API) designed for rendering vector graphics. Initially developed by Silicon Graphics in the 1990s, it is now taken care by the non-profit technology organization, the Khronos Group. It is platform-agnostic which makes experience consistent across different platforms.

\subsection{Rendering Mechanism}

At its core, OpenGL is about rendering. It provides developers with the tools needed to draw complex 3D and 2D graphics.

\begin{itemize}
    \item Role: OpenGL communicates directly with a system's GPU (Graphics Processing Unit) and translates the game's data into visual elements displayed on screen.
    \item Key Features: Supports techniques such as texture mapping, anti-aliasing, and shader programming.
\end{itemize}

\subsection{Shader Programming}

Shaders allow for creating stunning visuals programatticaly, and OpenGL provides extensive support for shader programming.

\begin{itemize}
    \item Role: Shaders allow developers to program the GPU directly, which gives massive control over how individual pixels or vertices are processed.
    \item Key Features: OpenGL's GLSL (OpenGL Shading Language) lets developers create custom shaders, enabling dynamic lighting, shadows, and other advanced visual effects.
\end{itemize}


\subsection{Extensibility}

One of OpenGL's strengths lies in its extensible design, allowing to include advancements in hardware and software.

\begin{itemize}
    \item Role: As hardware evolves, new extensions can be added to OpenGL without changing the entire API. This makes OpenGL relevant, independent of technological improvements.
    \item Key Features: These extensions can be used to utilize latest graphics hardware capabilities, making games look and perform their best.
\end{itemize}

\subsection{Cross-Platform Development}

\begin{figure}[htp]
\centering
\includegraphics[scale=0.70]{images/openglWikipedia.png}
\caption{Connection between Linux and OpenGL-based games \cite{openGLWikipedia}}
\label{}
\end{figure}

Gamers are spread across Windows, Mac, GNU/Linux, and other platforms, OpenGL's platform-independent allows for creating games for all platforms.

\begin{itemize}
    \item Role: OpenGL ensures that games look consistent across different platforms, easing the process of multiplatform game development.
    \item Key Features: It abstracts underlying platform-specific differences, allowing developers to focus on creating the game without need to adapt to platform-specific constraints.
\end{itemize}

\subsection{Integration with Other Libraries and Tools}

OpenGL is compatible with many libraries and development tools.

\begin{itemize}
    \item Role: Enhances OpenGL capabilities by working with libraries like GLFW for window management, GLAD for handling extensions, and more.
    \item Key Features: Provides an unified development environment, where various tools and libraries work together under OpenGL, again simplifying the process of game development.
\end{itemize}

In summary, OpenGL combines software and hardware, enabling developers to create experiences with enough precision and speed. Understanding impact of OpenGL will make explaining our own game engine inner workings much easier.
\section{Multiplatform Considerations}
In order to reach as wide an audience as possible, developers try to develop a game for multiple platforms – mostly Windows, Mac, and GNU/Linux. Creating multiple platforms game engine is filled with challenges and considerations. This section explores difficulties of multiplatform game development, describing what developers must be conscious of when targeting multiple operating systems.

\subsection{Platform-Specific Hardware and Software}

Every platform has its unique hardware and software configurations, which influence a game's performance and appearance.

\begin{itemize}
    \item Role: Ensuring the game runs smoothly across different hardware setups, from different GPU architectures to memory configurations.
    \item Key Features: Developers need tools to abstract these hardware-software differences, allowing the game engine to react dynamically based on the platform.
\end{itemize}

\subsection{User Input Variations}

Different platforms often have different input methods, from touchscreens to gamepads to keyboard-mouse setups.

\begin{itemize}
    \item Role: Making sure that the game responds accurately to various input methods.
    \item Key Features: Input handling system that can detect and adapt to different input devices.
\end{itemize}

\subsection{Graphical Rendering Nuances}

There are platform-specific nuances in how graphics are presented.

\begin{itemize}
    \item Role: Making engine work under different display resolutions, aspect ratios, and screen sizes.
    \item Key Features: Dynamic resolution scaling and responsive UI layouts to ensure the game looks similar across platforms.
\end{itemize}

\subsection{File System and Data Management}

\begin{figure}[htp]
\centering
\includegraphics[scale=1.00]{images/windowsLinuxSlash.jpg}
\caption{Separating folders with backslash and forward slash is one of many differneces between Windows and Linux systems \cite{windowsLinuxSlash} }
\label{}
\end{figure}

File systems varies between Windows, Mac, and GNU/Linux, influencing how game data is stored, retrieved, and updated.

\begin{itemize}
    \item Role: Managing game saves, configurations, and other data across platforms.
    \item Key Features: Data management system that behaves the same for platform-specific directory structures and access permissions.
\end{itemize}

\chapter{Toolchain and Libraries Overview}
\section{Introduction to GLFW}
In the arena of game development, libraries related to window management and input handling play crucial role. GLFW offers an interface for developers to create interactive applications. This section offers an introduction to GLFW, explaining into its origins, functionalities, and relevance in game development.

\subsection{Historical Context}

GLFW, which stands for Graphics Library Framework, was a response to the need for an open-source library that simplifies the challenges of window management and input handling, especially for OpenGL applications. Initially developed to provide a more straightforward alternative to existing solutions, GLFW has grown in popularity due to its simplicity, efficiency, and cross-platform capabilities.

\subsection{GLFW's Core Competencies}

GLFW serves as a bridge between the game's logic and the operating system, handling tasks that are crucial for interactive applications.

\begin{itemize}
    \item Window Management: GLFW's manages window creation, querying, and manipulation. It allows developers to focus on their game logic rather than handling platform-specific windowing.

    \item Input Handling: GLFW provides a system to capture and process user inputs. It forms for keyboard strokes, mouse movements, or even joystick inputs, GLFW makes sure that user interactions are detected and communicated to the application efficiently.

    \item Context Management: Especially relevant for OpenGL applications, GLFW helps create contexts, manage profiles, and handle extensions, for easier development experience.
\end{itemize}

\subsection{Integration with OpenGL}

While GLFW is platform-agnostic and can support multiple rendering systems, its mostly used with OpenGL.

\begin{itemize}
    \item Role: It functions as the companion to OpenGL, offering an environment where OpenGL can work more efficiently by addressing system-specific challenges that are outside OpenGL's specification.

    \item Key Features: Context creation for OpenGL.
\end{itemize}

\subsection{Cross-Platform Capabilities}

GLFW's is able to work across Windows, Mac, and GNU/Linux.

\begin{itemize}
    \item Role: GLFW is a consistent interface for developers, regardless of the target platform. This ensures uniformity in window creation, input handling, and other functionalities across different operating systems.

    \item Key Features: An architecture that ensures platform-specific norms while offering a consistent API for developers.
\end{itemize}

\subsection{Community and Support}

Being open-source, GLFW benefits from a huge community that continually refines, optimizes, and extends the library.

\begin{itemize}
    \item Role: Ensures GLFW remains up-to-date, addreses challenges and evolves with the needs of developers.

    \item Key Features: Tutorials and forums, assisting both new and trained developers in using GLFW
\end{itemize}

GLFW proves useful to many game developers, especially those using OpenGL. Its ability to handle window management, input processing, and other tasks ensures that developers can focus on crafting game mechanics and narratives.
\section{Role of GLAD in OpenGL Loading}
GLAD is a robust and flexible loader-generator designed for OpenGL. It ensures the dynamic loading of OpenGL functions based on the specific version and extensions a developer chooses. GLAD was developed to automate handling OpenGL extensions.

\subsection{The Need for Loading OpenGL Extensions}

OpenGL's is an extensible API. With changes in hardware, new functionalities are introduced through extensions without changing the core API. This creates new challenges on their own.

\begin{itemize}
    \item Role: Extensions allow developers to use the latest graphics capabilities, which are not always part of the core OpenGL library.

    \item Key Features: Handling these extensions requires dynamic loading at runtime, so that the game can access and utilize these advanced functionalities.
\end{itemize}

\subsection{GLAD's Functionality in Extension Loading}

GLAD simplifies working with OpenGL extensions through its automated approach.

\begin{itemize}
    \item Role: Provided with the OpenGL version and extensions, GLAD generates C/C++ code to load these extensions dynamically at runtime. This removes the need to manually address each extension, reducing errors and inefficiencies.

    \item Key Features: GLAD supports multiple languages and specifications. It is also up-to-date with the latest OpenGL specifications, making it compatible with newest graphics capabilities.
\end{itemize}

\subsection{Integration with GLFW and OpenGL}

GLAD interacts with both OpenGL and GLFW, creating an unified development environment. Once GLFW creates the OpenGL context, GLAD is utilized to load the necessary functions. This collaboration ensures that GLFW handles the platform-specific instructions, while GLAD focuses on OpenGL's extensibility.

\section{Handling text and images with FreeType, ft2build and stb\_image}
\subsection{Introduction to FreeType}

FreeType is an open-source software font engine, It offers ability to render text onto bitmaps and other font-related functionalities.

\subsection{Key Capabilities of FreeType}

\begin{itemize}
    \item Font Parsing and Loading: Before rendering, fonts need to be parsed and loaded. FreeType supports many font formats, ensuring broad compatibility.

    \item Glyph Rendering: FreeType is good at converting individual glyphs into bitmaps, handling anti-aliasing and hinting to create clear, sharp text rendering.

    \item Font Metrics and Kerning: Rendering text isn't just about individual glyphs. The spacing between them (kerning) and their metrics are crucial for readability and aesthetics, and FreeType is able to deliver this functionality.
\end{itemize}

\subsection{Understanding ft2build}

ft2build serves as an essential interface, allowing for the inclusion and deployment of FreeType headers in development projects. ft2build was created to ease the integration process of FreeType 2.

\subsection{Introduction to stb\_image}

While FreeType takes charge of fonts, stb\_image is a solution for image loading and decoding, popular for its simplicity and compactness. It is part of the stb collection of single-file libraries.

\subsection{Key Capabilities of stb\_image}

\begin{itemize}
    \item Image Loading: It is capable of handling popular formats like JPEG, PNG, BMP, and more, this way developers can incorporate multiple types of graphical assets into their game

    \item Image Decoding: stb\_image decodes images into a format that can be directly used with OpenGL or other rendering systems.

    \item Simplicity and Efficiency: stb\_image has minimalistic design. With just a single header file, developers can use its capabilities without employing complex dependencies or configurations.
\end{itemize}

Specialized tools like FreeType and stb\_image elecate the visual experience of games with text rendering and images inclusion into game engine

\chapter{Design and Architecture of the Match Three Engine}
\section{Game Loop and State Management}
In the heart of every video game lies the game loop. This cycle dictates the game's pacing, ensuring that events, updates, and rendering processes all appear in a correct order. Game loop functions together with state management, which ensures the game behaves consistently in response to player actions and internal events. This section will focus on both the game loop and state management and how they influence our multiplatform Match Three game engine.

\subsection{The Anatomy of a Game Loop}

The game loop is a repetitive process that continues for the lifespan of the game session. It tries to:

\begin{itemize}
    \item Poll Input: Gather and process player inputs.

    \item Update Game State: Based on the inputs and game rules, modify game entities and overall state.

    \item Render: Draw the current state of the game onto the screen.

    \item Sleep (Optional): Introduce a short delay, if necessary, to control the loop's frequency and match the target framerate.
\end{itemize}

\subsection{Importance of State Management}

As games grow complex, they may contain numerous states, including:

\begin{itemize}
    \item Menu Screens: Where players can start, configure settings, or view credits.

    \item Gameplay Modes: Different modes or levels of gameplay, each with its unique rules and environments.

    \item Pause/Resume States: Allowing players to stop the game and later resume it.

    \item Endgame Scenarios: Winning, losing, or drawing conditions.
\end{itemize}

State management ensures the game recognizes and responds appropriately to these states.

\subsection{Interlinking Game Loop and State Management}

Game Loop and State Management must work together:

\begin{itemize}
    \item State-Driven Rendering: What the game displays during each loop iteration depends on its current state. For instance, the game may render a main menu, gameplay screen, or a 'game over' message based on its active state.

    \item State Transitions: Player inputs or internal events can trigger state changes. The game loop continually checks for such triggers and initiates the necessary transitions.
\end{itemize}

\subsection{Challenges and Considerations}
Managing a game loop and states is filled with challenges:

\begin{itemize}
    \item Performance: The game loop must run efficiently to maintain smooth gameplay, especially crucial for real-time games where fast decisions matter.

    \item State Persistence: Some states may require data persistence, like saving a game, which requires storing and retriving game data.

    \item Synchronization: Ensuring that state transitions and game loop iterations are in sync is essential to avoid unexpected behaviors.
\end{itemize}

\subsection{Role in the Multiplatform Match Three Game Engine}

For our game engine, the game loop and state management fullfill following functions:

\begin{itemize}
    \item Cross-Platform Consistency: The game's behavior, pacing, and responses should be consistent across Windows, Mac, and GNU/Linux platforms.

    \item Match-Three Logic: The game engine will manage states specific to match-three mechanics, like checking for matches, handling cascades, and introducing new game pieces.
\end{itemize}

In summary, game loop maintains the rhythm of the game, while state management ensures logic in the game's behavior.
\section{Asset Management and Rendering}
Game development consists of art and logic, where visual assets behave based on game code. Ensuring these assets are well-organized, efficiently loaded, and rendered is vital for any gaming experience. This section explores asset management and rendering.

\subsection{What are Game Assets?}

In the context of game development, assets refer to:

\begin{itemize}
    \item Graphics: These include textures, sprites, animations, and UI elements.

    \item Data: Configurations, level designs, scripts, and other data structures that define gameplay mechanics.
\end{itemize}

\subsection{Rendering: Bringing Assets to Life}

Once assets are organized and loaded, rendering puts them onto the screen:

\begin{itemize}
    \item Displaying Graphics: Textures and sprites are mapped onto game entities.

    \item Shaders \& Effects: Advanced graphical effects, such as lighting, shadows, and particle effects, are layered on to assets to elevate visuals.
\end{itemize}
    
\subsection{Cross-Platform Considerations in Asset Management}

Given our engine's multiplatform nature, certain challenges arise:

\begin{itemize}
    \item Format Compatibility: Not all asset formats are supported uniformly across platforms. Ensuring assets are in universally compatible formats and using libraries like stb\_image that unify asset formats among different operating systems is crucial.

    \item Optimization: Different platforms may have varying memory capacities and processing power. Assets might need to be optimized, resized, or compressed to respond to those limitations.
\end{itemize}

\subsection{Role in the Multiplatform Match Three Game Engine}
Our game engine’s being multiplatform complicates assets rendering:

\begin{itemize}
    \item Uniformity Across Platforms: Visual experience should remain consistent across Windows, Mac, and GNU/Linux.

    \item Match-Three Specifics: Given the genre, the engine must effectively manage assets like gems, power-ups, grid structures, and cascade animations and then render them in a visually pleasing way.
\end{itemize}

\section{Event Handling and User Input}
Main trait of video game is interactivity. Game must have the ability to capture, interpret, and respond to user input, whether it is the click of a mouse, the press of a keyboard key, or the swipe on a touchscreen. Managing those interactions is called event handling. In this section we will describe event handling and user input, and their role in our game engine.

\subsection{Understanding User Input and Events}

Every action by the user generates an event. This event contains specific data, such as:

\begin{itemize}
    \item Type of Input: Whether it's a key press, mouse movement, click, or touch.

    \item Coordinates: In case of mouse or touch, the precise location of the interaction.

    \item Duration: The length of time an input is maintained, like a long press.
\end{itemize}

\subsection{Event Polling vs. Event Callbacks}

There are two primary ways to handle these events:

\begin{itemize}
    \item Event Polling: The game loop consistently checks (or "polls") for user inputs at fixed intervals, processing any detected events.

    \item Event Callbacks: The system is set up to notify (or "call back") the game engine immediately when an event occurs.
\end{itemize}

\subsection{Role in the Multiplatform Match Three Game Engine}

Our game engine should provide following features connected with user input:

\begin{itemize}
    \item Intuitive Matching: Selecting and swaping game pieces should be easy and convenient, with the engine accurately capturing and responding to these interactions.

    \item Feedback Loop: Upon receiving an input, the game engine must also provide immediate feedback, such as highlighting a selected piece, initiating a combo move or playing animation.
\end{itemize}

Event handling and user input are ways for players to communicate with the game. It is crucial to make them intuitive and smooth.

\chapter{Cross-Platform Development Challenges and Solutions}
\section{Operating System Variabilities}
Operating systems (OS) are a middle ground between human interaction and hardware functionality. With Windows, Mac, and GNU/Linux operating systems as the most popular desktop environments, a multiplatform game engine must work under each of them. This section describes differences between these operating systems and how our engine can handle them.

\subsection{Core Architectural Differences}

Some of the distinctive features of OS architecture are:

\begin{itemize}
    \item Kernel Design: Windows uses a hybrid kernel, while Linux is a monolithic kernel, MacOS is based around Unix XNU kernel.

    \item File Systems: Windows primarily offers NTFS, MacOS stores files using APFS, and GNU/Linux has multiple options like ext4, Btrfs, and many, many more.

    \item APIs \& System Calls: Each OS provides developers with its own set of APIs and system calls, changing how software communicates with the system.
\end{itemize}

\subsection{Graphical User Interface (GUI) Divergence}

Differences in GUI of each OS:

\begin{itemize}
    \item Window Management: Windows uses a floating window system, MacOS has its unique mission control, and Linux distributions can use anything from floating, fixed to no graphical interface at all.

    \item Input Methodologies: Multi-touch gestures work different under MacOS than under Windows. Linux, depending on its distribution and desktop environment, may have a the same or different approach altogether.
\end{itemize}

\subsection{Driver Support}

Certain hardware, sometimes crucial to game engine like graphics card or keyboad, might be optimized for one OS over the others, or might not be supported entirely.

\subsection{Middleware \& Third-party Libraries}

The accessibility, performance, and support of middleware and third-party libraries can differ, while some libraries are universally compatible, others might be OS-specific, another problem might be with the update cycle, the frequency of libraries updates can vary, impacting game engine compatibility and performance.

\subsection{Implications for the Multiplatform Match Three Game Engine}

Operating system variances impact directly on our game engine:
	
\begin{itemize}
    \item Performance Optimizations: Depending on the OS, certain code paths might be more efficient. The engine must be adaptable.

    \item Consistent Gameplay Experience: Players on all platforms should have a similar gameplay experience.

    \item Updates \& Maintenance: As OSs changes, the game engine must be ready for regular updates to ensure compatibility.
\end{itemize}

Multitude of operating systems poses challenges for game engine developers. By understanding these differences, developers can make sure that the game functions across different platforms.
\section{Addressing Hardware and Driver Differences}
Hardware and its associated drivers act as the final execution devices for any game engine. When creating a game engine, developer must keep in mind a variety of hardware configurations and their driver implementations. This section focuses on understanding these differences and how we can challenge them.
\subsection{A Landscape of Diverse Hardware}

Across all platforms, multiple hardware components exists:

\begin{itemize}
    \item Processors: Mostly Intels and AMD's x86 architecture (32 and 64 bits), together with ever more popular ARM processors
    \item Graphics Cards: NVIDIA, AMD, and Intel dominate the market, each with their architectures and feature sets.
    
    \item Memory Configurations: RAM specifications, speeds, and type of storage devices (SSDs and HDDs) can influence performance.

    \item Input Devices: Various keyboards, mice, touchpads, touchscreens, and game controllers, each have unique specs and capabilities.
\end{itemize}

\subsection{Drivers: The Link to Hardware}

Drivers allow an operating system to interact with hardware:

\begin{itemize}
    \item Proprietary vs. Open-Source: While NVIDIA provides proprietary drivers, AMD and Intel often offer open-source alternatives for Linux. There are also community driven, universal, open-source drivers.

    \item Update Frequencies: Hardware vendors release driver updates at different intervals, each update possibly affects game performance and compatibility.

    \item Feature Support: New hardware features may be enabled in driver updates.
\end{itemize}

\subsection{Challenges Posed to Game Engines}

\begin{itemize}
    \item Optimization Issues: What's optimized for one graphics card might not be for another.

    \item Feature Inconsistencies: Some hardware may support specific graphical features, while others might not.

    \item Input Latency Variations: Different input devices and their drivers can lead to varied response times and incosistent responses.
\end{itemize}

\subsection{Abstraction Layers in Match Three Game Engine}

To address these challenges, our engine adopts abstraction layers: by utilizing existing libraries and solutions (OpenGL, GLAD and GLFW), our game engine is ready for easier adjustments for specific hardware.

\chapter{Implementation Details}
\section{Core Engine Implementation}
For our Match Three game engine, we aimed to create a simple core, capable of ensuring basic gameplay and small codebase allowing developers to extend or modify the engine's capabilities as needed. This section describes the implementation of the Match Three game engine.

\subsection{Foundational Principles}
\begin{itemize}
    \item Platform Independence: Core engine functionalities independent of any specific platform, allowing for easy porting across Windows, MacOS, and GNU/Linux.

    \item Simplicity: There are no more than 2500 lines of code in the entire engine
    
    \item Good coding style: When writing code, popular coding styles of cpplint and clang-tidy were used
    
    \item Good coding principles: when writing code, clang-tidy was extensively used to highlight potential errors and eliminate bad practices 
\end{itemize}

\subsection{Core Modules}

The engine's architecture is segmented into modules:

\begin{itemize}
    \item Game object: (game\_object.cpp) Defines base class for game objects used by the engine, this class is later used to define tiles

    \item Main Game class: (game.cpp) This class combines all of the other modules and runs the game loop

    \item Game Level: (game\_level.cpp) Loads and saves game levels.

    \item Particle Generator: (particle\_generator.cpp) Generates particle effects for tiles

    \item Post Processor: (post\_processor.cpp) Combines particle and shader effects
    
    \item Resource Manager: (resource\_manager.cpp) Handles assets and shaders files
    
    \item Shader: (shader.cpp) calculates shaders and applies their effects
    
    \item Sprite Renderer: (sprite\_renderer.cpp) Renders sprites from images
    
    \item Text Renderer: (text\_renderer.cpp) Renders text
    
    \item Texture Renderer: (texture.cpp) Renders textures
\end{itemize}

\subsection{Dependency Management}
There are several libraries: OpenGL, GLFW, stb\_image and freetype being integrated into engine, they are simply included at the top of any files that need them. 

\subsection{Constants file}
Game parameters, from graphics settings to gameplay variables, are stored in constants.cpp file, which can be modified, to apply the changes the engine must be compiled again.

\section{Match Three Logic and Mechanics}
Match Three game challenges players to align identical items in rows or columns of three or more. This section describes how the Match Three logic and mechanics were implemented within our game engine.

\subsection{The Fundamental Game Grid}

A Match Three game takes place on a grid, where each cell holds an item (tile):

\begin{itemize}
    \item Dynamic Grid Generation: The engine supports grids of various sizes, ensuring adaptability for different game designs or levels.

    \item Item Diversity: While classic Match Three games primarily used jewels or candies, our engine supports any kind of 2d image assets user wants to use, these assets can later be processed by user created shaders
\end{itemize}

\subsection{Matching Logic}

\begin{itemize}
    \item Pattern Recognition: The engine monitors the grid, identifies patterns where three or more items align vertically or horizontally.

    \item Combo Chains: Beyond the basic three-item match, the engine recognizes and rewards larger matches and cascading chain reactions.

    \item NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION! \sout{Special Items: Some matches can generate special items with unique properties, such as the ability to clear an entire row or explode surrounding tiles.}
\end{itemize}

\subsection{Player Interactions and Moves}

\begin{itemize}
    \item Drag and Swap: The primary interaction method, where players drag items to swap positions and create matches.

    \item Move Validation: Not every swap leads to a match. The engine predicts potential matches before finalizing a move, ensuring players don't make invalid swaps.

    \item NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION! \sout{Move Limitations: Some levels might introduce a maximum move count, adding a strategic layer to gameplay.}
\end{itemize}


\subsection{Game Progression and Levels}
NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION!
\sout{
Keeping players engaged:

    Dynamic Difficulty: As players advance, the game introduces larger grids, more item types, or challenging obstacles, ensuring a progressively challenging experience.

    Level Objectives: Beyond mere matching, players might need to achieve specific objectives, such as reaching a certain score or clearing particular grid cells.

    Reward System: Completing levels or achieving special combos can grant players rewards, from in-game currency to new levels or challenges.
}

\subsection{Challenges and Obstacles}

NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION!
\sout{
Introducing variety:

    Static Blocks: Some grid cells might be occupied by immovable blocks, adding a puzzle element to gameplay.

    Movable Obstacles: Items that shift position, grow, or change over time, forcing players to adapt their strategies.

    Timed Challenges: Levels where players need to achieve objectives within a set time frame.
}

Our engine offers basic match three experience with couple of additional features added on the top.
\section{Integration of Libraries and Tools}
In this section we will explain rationality for choosing libraries and tools for our engine and how they were implemented

\subsection{ Choice of graphic renderning API }
There are 3 main APIs for graphical rendering
\begin{itemize}
    \item DirectX
    \item OpenGL 
    \item Vulkan
\end{itemize}
DirectX developed by Microsoft focues on Windows operating systems and 
Microsoft line of consoles Xbox, it is deemed as being harder with more 
low level programming and requiring better understanding of how underlying
mechanisms work but in turn offers functionalities and better performance. 
It does not have free license. \\
OpenGL is developed by Khronos Group and offers good compatibility, 
especially if using OpenGL ES subset which works on Windows, Linux, 
Mac OS, Android, iOS and all major consoles. 
It is widely recognized as easiest of APIs and most popular choice 
for writing first game engine. On the other hand it lacks some of 
more advanced features which have to be written manually. 
It uses open source license similar to BSD
\\
Vulkan is also developed by Khronos Group and as such is deemed as a 
spiritual successor of OpenGL with focus on using modern C++ features and 
fixing issues created by OpenGL 30 years old development time. 
Out of these three it is recognized as the hardest one as 
it is both complicated and newest. Similarly as OpenGL 
it uses open source license, namely Apache License 2.0. 
\\
Considering all of those characteristics I decided to go with OpenGL API, 
specifically OpenGL ES subset with its focus on compatibility as 
making a multiplatform application is one of the focues of this thesis.
I decided that since this will be my first attempt at game engine development 
I need something that is relatively easy and has a lot of resources online.
I would most likely not use advanced features of Vulkan and DirectX and 
therefore finish my thesis before approaching problems where OpenGL 
does not deliver more complicated architecture. 
From my own private preferences I also prefer software with 
open source license.

\subsection{Choice of OpenGL Library}
There are 4 basic OpenGL libraries that I considered:
\begin{itemize}
    \item freeGLUT
    \item SDL 
    \item SFML 
    \item GLFW
\end{itemize}
freeGLUT was created as opensource alternative to GLUT, 
is considered to be the worst out of all 4, 
written in archaic way, using C or very old C++, 
which in turn results in unexpected "buggy" behaviour,
it is also not really popular with lack of online guides \\
SDL - Simple DirectMedia Layer has big userbase, 
it is not designed to by used as a standalone 
library and requires additional libraries to do networking 
or to create more complex applications. \\
SFML is the library with most features out of all 4, 
it supports networking, audio and has system features by 
default. It uses modern object oriented C++. 
Main problem with SFML is that it is not very popular API,
therefore troubleshooting problems with SFML is quite hard and
it has only few use guides online \\
GLFW is an library that is both the most popular and with fewest features by default. 
It forces users to use additional libraries for networking, 
sound, physic calculations and so on but in turn is also 
quite small and flexible. It has biggest community and a 
lot of guides, like one hosted at 
\href{learnopengl.com}{learnopengl.com} or one created by 
programming youtuber Cherno \\
I decided to use GLFW library. I wanted something that is 
relatively easy to troubleshoot and has abundance of 
learning materials online. 

\subsection{GLAD and OpenGL Extension Handling}
GLAD enabled the dynamic loading of OpenGL functions, this way engine can use the latest OpenGL features.

\subsection{Text and Image Rendering with FreeType, stb\_image, and ft2build}

FreeType and stb\_image were choosen for their simplicity and popularity

\begin{itemize}
    \item Font Rendering: With FreeType and ft2build, the engine can render text, crucial for messages, scores, and menus.

    \item Image Loading: stb\_image simplifies the task of loading and processing various image formats, from PNGs and JPGs to more complex formats, making asset integration much easier.
\end{itemize}

\chapter{Case Study: Development of a Prototype Match Three Game}
\section{Game Concept and Design}
In order to gauge the usability of our game engine, we decided to create a sample match three game using royalty free assets. First part of this process was game design

\subsection{Game Theme and Narrative}

We decided to create a classic gem filled match three game, comparable to old bejeweled games.

\subsection{Core Mechanics and Gameplay}

Game utilizes full functionality of our engine, player needs to match three or more gems, chaining matches or achieving higher combos grants the player higher score

\subsection{User Interface and User Experience}

\begin{itemize}
    \item Game HUD: The Heads-Up Display is minimalistic, showcasing only essential elements like score and moves left.

    \item, Feedback Mechanics: Animations, particles and shaders provide feedback for successful matches and combos.

\end{itemize}

\section{Application of the Engine in Real-world Development}
After designing the game, we started creating it using our game engine.

\subsection{Seamless Integration with Game Design}
Since the engine was created exactly with this type of game in mind, brining design decisions to life was very easy

\subsection{Challenges in Implementation}

Biggest challenge was our toolset, we had to either modify the existing engine solutions or create new one from scratch.

\subsection{Advantages of a Custom-built Engine}

\begin{itemize}
    \item Optimized Performance: Tailored specifically for a Match Three game, the engine could be highly optimized for this genre, reducing unnecessary overheads. Using OpenGL and plain C++ also added to engine speed

    \item Direct Control: Having complete control over engine we could introduce, modify, or remove features as needed.
\end{itemize}

We were able to create a game using our engine, which means that the goal of this entire thesis was reached. 

\chapter{Future Work and Enhancements}
\section{Potential Extensions to the Engine}
While we were able to produce a game using our engine, it still has a potential to grow more and introduce many new features.

\subsection{Enhanced Graphics and Physics}

Enhancing the visual and interactive experience:

\begin{itemize}
    \item Ray Tracing: Using ray tracing can provide more realistic lighting, shadows, and reflections, increasing visual depth with little cost to an engine user.

    \item Advanced Particle Systems: Enhancing particle effects can create more immersive environments, from weather effects to more dynamic game elements.

    \item Physics Enhancements: More advanced physics simulations can improve feel to game interactions, from simple collisions to complex motion dynamics.
\end{itemize}

\subsection{Adaptive Difficulty}
Machine learning can analyze player performance and adjust game difficulty in real-time, ensuring a balanced challenge.

\subsection{Real-time Multiplayer}
Adding capabilities for online multiplayer modes can increase engagement, replayability and competetivnes.

\subsection{More platforms}
Engine could be adapted to work under mobile systems (Android and IOs) and consoles (Xbox, PlayStation and Switch)

As can be seen there are still a lot of features that can be added to our engine to make it even more useful

\chapter{Conclusion}
\section{Summary of Achievements}
In this section we will look back at our project and describe our achievments.
\subsection{Multiplatform Support}

\begin{itemize}
    \item OS Versality: We successfully developed a game engine that operates across Windows, Mac, and GNU/Linux platforms, addressing the title of this thesis.

    \item Addressed Platform-specific Challenges: Overcame technical challenges associated with different operating systems, ensuring a consistent user experience.
\end{itemize}

\subsection{Library Integrations}
We managed to itegrate libraries such as GLFW, glad, freetype, stb\_image, and ft2build, all within one game engine

\begin{itemize}
	\item GLFW/glad: easying the process of using OpenGL
	\item freetype/ft2build: allowing for rendering text within game
	\item stb\_image: for ease of importing image assets into game engine
\end{itemize}

\subsection{Robust Game Mechanics}

\begin{itemize}
    \item Match Three Logic: Core match three logic was implemented, matching 3 or more tiles, chain reactions and limited moves

    \item Event Management: The game responds successfuly to user interactions
\end{itemize}

\subsection{Practical usage}
We managed to create a fully functional match-three game, using only our game engine and royalty free assets.

\subsection{Contributions to the Field of Game Development}
Our engine allows aspiring game developers to create their own match three games, and engine developers to learn from it and expand it.

In conclusion, we managed to accomplish all of the goals we set for this thesis, our engine successfuly produces a game for all three operating systems we were aiming for.


\section{Reflection on the Development Process}
Creating this game engine was a long process, it took almost a year to bring it to the state it is now in, during this time several reflections came about.

\subsection{Embracing the Multiplatform Challenge}
In order to overcome differences for different operating system, a lot of time was put into choosing correct graphical api and libraries that could work on Windows, GNU/Linux and MacOS. This proved crucial when later developing the engine as this issue did not came back and I could focus on creating the engine itself.

\subsection{Library Integrations}
Using multiple different libraries and integrating them with our game engine was a challenge, thanks to existing solutions like learnopengl repository which already overcame those difficulties and KDevelop easy approach to external libraries it was possible to implement all of libraries within our game engine.

\subsection{Time management}
Lastly, probably the biggest challenge was managing time for this thesis. Finishing it required a lot of determination, setting barriers and working every day to ensure that the thesis is finished on time. Thankfully past experiences helped in guiding through this task that could be compared to colos\textbf{sus}.
\chapter{References}

\chapter{Appendices}


\bibliography{references}



\end{document}