fix: most hbox issues

latex/main.tex

@@ -62,9 +62,31 @@
 %-------------------------------------
 \cleardoublepage % Zaczynamy od nieparzystej strony
 \abstract 
-Przez ostatnią dekadę rynek tworzenia gier komputerowych zdominowały dwa silniki: Unity oraz Unreal Engine. Niniejsza praca podejmuje się wyzwania przeprowadzenia analizy porównawczej obu tych silników pod kątem wydajności oraz procesu programowania gier. W~tym celu wykorzystano narzędzie do profilowania NVIDIA Nsight, służące do oceny wydajności aplikacji graficznych, w~szczególności do pomiaru czasu klatki, obciążenia GPU oraz efektywności renderowania. Przeprowadzono również wywiady środowiskowe z~osobami związanymi profesjonalnie z~tworzeniem gier na obu platformach, jak również opisano proces twórczy, napotkane trudności oraz przewagi każdego z~silników. Na potrzeby pracy stworzono dwie gry w~tym samym gatunku --- \emph{bullet hell} --- słynącym z~mnogości elementów na ekranie i~efektów specjalnych, a~jednocześnie będącym relatywnie łatwym do zaimplementowania. Jedna gra została stworzona w~języku C\# (Unity), druga w~C++ (Unreal Engine). Następnie obie gry zostały poddane analizie w~programie NVIDIA Nsight w~celu oceny możliwości optymalizacji obu silników. Na podstawie wywiadów oraz analizy procesu twórczego scharakteryzowano również inne aspekty obu silników, takie jak próg wejścia, współpraca z~systemami kontroli wersji oraz architektura silnika. Praca stara się wypełnić niszę w~literaturze i~badaniach związanych z~oceną obu silników do gier.
+Przez ostatnią dekadę rynek tworzenia gier \\ 
+komputerowych zdominowały dwa silniki: Unity oraz 
+Unreal Engine. \\ Niniejsza praca podejmuje się wyzwania przeprowadzenia analizy \\
+porównawczej 
+obu tych silników pod kątem wyd ajności oraz procesu \\ 
+programowania gier. W~tym celu wykorzystano 
+narzędzie do \\ 
+profilowania NVIDIA Nsight, służące do oceny wydajności aplikacji \\ graficznych, 
+w~szczególności do pomiaru czasu klatki, obciążenia GPU oraz
+efektywności renderowania. 
+Przeprowadzono również wywiady \\ środowiskowe z~osobami związanymi profesjonalnie z~tworzeniem 
+gier na obu platformach, jak również opisano proces twórczy, napotkane \\ trudności oraz przewagi 
+każdego z~silników. Na potrzeby pracy stworzono dwie gry w~tym samym gatunku --- 
+\emph{bullet hell} --- słynącym z \\ mnogości elementów na ekranie i~efektów specjalnych, 
+a~jednocześnie będącym relatywnie łatwym do zaimplementowania. Jedna gra została stworzona 
+w~języku C\# (Unity), druga w~C++ (Unreal Engine). \\ Następnie obie gry zostały poddane analizie 
+w~programie NVIDIA Nsight w~celu oceny możliwości optymalizacji obu silników. Na podstawie 
+wywiadów oraz analizy procesu twórczego scharakteryzowano również inne aspekty obu silników, 
+takie jak próg wejścia, współpraca z \\ systemami kontroli wersji oraz architektura silnika. 
+Praca stara się wypełnić niszę w~literaturze i~badaniach związanych z~oceną obu silników do gier.
 
-\keywords Gry, Silniki do gier, C\#, C++, Unreal Engine, Unity, Gry \emph{bullet hell}, NVIDIA Nsight, Wydajność, Wywiady, Analiza porównawcza, Profilowanie, Renderowanie, Optymalizacja, Programowanie gier, Tworzenie gier, Czas klatki, Architektura silnika, Kontrola wersji, GPU
+\keywords Gry, Silniki do gier, C\#, C++, Unreal Engine, Unity, Gry \emph{bullet hell}, 
+NVIDIA Nsight, Wydajność, Wywiady, Analiza porównawcza, Profilowanie, Renderowanie, 
+Optymalizacja, Programowanie gier, \\ Tworzenie gier, Czas klatki, Architektura silnika, 
+Kontrola wersji, GPU
 
 %----------------------------------------
 % Streszczenie po angielsku dla \langpol
@@ -97,7 +119,7 @@ Over the past decade, the video game development market has been dominated by tw
 \input{tex/wywiady-analiza}  
 \input{tex/implementacja-gry}           % Analiza wywiadów z deweloperami gier
 \input{tex/narzedzia-profilowania}      % Narzędzia profilowania wydajności
-% \input{tex/5-testy-wydajnosci}          % Testy wydajności
+%\input{tex/5-testy-wydajnosci}          % Testy wydajności
 % \input{tex/6-analiza-mozliwosci}        % Analiza możliwości i funkcjonalności
 % \input{tex/7-porownanie-wynikow}        % Porównanie wyników i analiza
 % \input{tex/8-podsumowanie}        

latex/tex/1-wstep.tex

@@ -64,7 +64,9 @@ Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~nas
 \begin{enumerate}
     \item \textbf{Intensywne wykorzystanie zasobów} -- jednoczesne renderowanie setek lub tysięcy obiektów (pocisków) stanowi znaczące obciążenie dla systemu renderowania
     
-    \item \textbf{Testowanie zarządzania pamięcią} -- ciągłe tworzenie i~niszczenie obiektów pocisków eksponuje różnice w~implementacji garbage collectora (Unity/C\#) versus ręcznego zarządzania pamięcią (Unreal/C++)
+    \item \textbf{Testowanie zarządzania pamięcią} -- ciągłe tworzenie i~niszczenie obiektów 
+    pocisków eksponuje różnice w~implementacji \\ garbage collectora (Unity/C\#) versus ręcznego 
+    zarządzania pamięcią (Unreal/C++)
     
     \item \textbf{Wymagania systemu fizyki} -- wykrywanie kolizji między graczem a~setkami pocisków w~każdej klatce obciąża system fizyki
     
@@ -109,13 +111,9 @@ Praca składa się z~następujących rozdziałów:
 
 \subsection{Metodologia}
 
-W~pracy zastosowano metodologię badawczą łączącą podejście ilościowe z~jakościowym:
-
 \begin{itemize}
-    \item \textbf{Testy wydajnościowe} -- obiektywne pomiary z~wykorzystaniem NVIDIA Nsight Graphics, zapewniające porównywalność wyników między silnikami
+    \item \textbf{Testy wydajnościowe} -- Pomiary z~wykorzystaniem NVIDIA Nsight Graphics, zapewniające porównywalność wyników między silnikami
     \item \textbf{Wywiady z~deweloperami} -- badania jakościowe dostarczające kontekstu praktycznego użytkowania silników
     \item \textbf{Implementacja porównawcza} -- stworzenie identycznej gry w~obu silnikach, dokumentując różnice w~procesie deweloperskim
-    \item \textbf{Analiza dokumentacji} -- przegląd oficjalnej dokumentacji i~materiałów edukacyjnych
 \end{itemize}
 
-Takie wieloaspektowe podejście pozwala na kompleksową ocenę silników, uwzględniającą zarówno mierzalne parametry techniczne, jak i~subiektywne doświadczenia użytkowników.

latex/tex/2-przeglad-literatury.tex

@@ -42,7 +42,7 @@ Gregory \cite{gregory2018game} przedstawia taksonomię architektur silników gie
 
 \begin{itemize}
     \item \textbf{Silniki obiektowe} - bazujące na hierarchii obiektów gry z dziedziczeniem
-    \item \textbf{Silniki komponentowe} - wykorzystujące systemy entity-component-system (ECS)
+    \item \textbf{Silniki komponentowe} - wykorzystujące systemy \\ entity-component-system (ECS)
     \item \textbf{Silniki hybrydowe} - łączące elementy różnych podejść architektonicznych
 \end{itemize}
 
@@ -83,8 +83,8 @@ Barczak i Woźniak \cite{barczak2019comparative} przeprowadzili kompleksowe stud
 \subsection{Motywacja i cel pracy}
 
 Przegląd literatury pokazuje, że istnieje wiele badań porównawczych
-silników gier, jednak większość z nich koncentruje się na wybranych
+silników gier, jednak większość z nich koncentruje się na wybranych \\
-aspektach, takich jak wydajność renderowania, łatwość użycia czy
+aspektach, takich jak wydajność renderowania, łatwość użycia czy \\
 wsparcie dla konkretnych platform. Niniejsza praca wpisuje się w ten
 nurt, przeprowadzając praktyczne porównanie silników Unity i Unreal
 Engine pod kątem wydajności w wybranych scenariuszach testowych.

latex/tex/3-silniki-gier.tex

@@ -14,7 +14,7 @@ kilkoma kluczowymi czynnikami:
 \begin{itemize}
     \item \textbf{Dominacja rynkowa} -- według raportu Video Game Insights,
     w~2024 roku 51\% gier wydanych na platformie Steam powstało w~Unity,
-    a~28\% w~Unreal Engine \cite{vgi2025engines}
+    \\ a 28\% w~Unreal Engine \cite{vgi2025engines}
     \item \textbf{Reprezentatywność podejść architektonicznych} --
     silniki reprezentują odmienne filozofie: Unity opiera się na
     języku C\# z~garbage collectorem,
@@ -59,9 +59,9 @@ platformie .NET/Mono, co zapewnia:
 \end{itemize}
 
 Architektura Unity opiera się na wzorcu \textit{GameObject-Component},
-gdzie każdy obiekt w scenie (GameObject) może posiadać dowolną
+\\ gdzie każdy obiekt w scenie (GameObject) może posiadać dowolną
-liczbę komponentów definiujących jego zachowanie.
+liczbę \\ komponentów definiujących jego zachowanie.
-Podejście to promuje kompozycję nad dziedziczeniem i ułatwia
+Podejście to promuje \\ kompozycję nad dziedziczeniem i ułatwia
 tworzenie modularnego kodu.
 
 \subsubsection{Możliwości i funkcjonalności}
@@ -90,7 +90,7 @@ funkcjonalnościami \cite{unity_wikipedia}:
 \begin{itemize}
     \item Hierarchiczny widok sceny z możliwością edycji w czasie
     rzeczywistym
-    \item Inspektor właściwości z obsługą serializacji pól poprzez
+    \item Inspektor właściwości z obsługą serializacji pól \\ poprzez
     atrybut \texttt{[SerializeField]}
     \item Wbudowany profiler wydajności (CPU, GPU, pamięć)
     \cite{unity_profiler}
@@ -162,19 +162,20 @@ Unreal Editor oferuje rozbudowane środowisko deweloperskie~\cite{unreal_docs}:
 \centering
 \caption{Porównanie kluczowych cech Unity i Unreal Engine}
 \label{tab:unity-vs-unreal}
-\begin{tabular}{|l|c|c|}
+\small
+\begin{tabular}{|l|l|l|}
 \hline
-\textbf{Cecha} & \textbf{Unity} & \textbf{Unreal Engine} \\
+\textbf{Cecha} & \textbf{Unity} & \textbf{Unreal} \\
 \hline
-Język programowania & C\# & C++ / Blueprints \\
+Język & C\# & C++ \\
 \hline
-Zarządzanie pamięcią & Automatyczne (GC) & Ręczne / Smart pointers \\
+Pamięć & Automatyczne (GC) & Ręczne (smart pointers) \\
 \hline
-Architektura & GameObject-Component & Actor-Component \\
+Architektura & GameObject Component & Actor Component \\
 \hline
-Natywne wsparcie 2D & Tak & Nie (symulowane) \\
+2D & Natywne & Ograniczone \\
 \hline
-Kod źródłowy & Częściowo dostępny & Pełny dostęp \\
+Kod źródłowy & Częściowy & Pełny \\
 \hline
 Główne zastosowania & Mobile, indie, 2D & AAA, FPS, 3D \\
 \hline

latex/tex/4-metodologia.tex

@@ -19,7 +19,7 @@ za pomocą narzędzia NVIDIA Nsight Systems:
 \begin{itemize}
     \item \textbf{Czas klatki} (ang. \emph{frame time}) -- czas potrzebny
     na wyrenderowanie pojedynczej klatki, wyrażony w~milisekundach
-    \item \textbf{Liczba klatek na sekundę} (FPS) -- wartość pochodna
+    \item \textbf{Liczba klatek na sekundę} (FPS) -- wartość \\ pochodna
     od czasu klatki, kluczowa dla płynności rozgrywki
     \item \textbf{Wykorzystanie GPU} -- procentowe obciążenie karty graficznej,
     mierzone poprzez liczniki sprzętowe NVIDIA
@@ -89,8 +89,8 @@ progresywnie zwiększała obciążenie poprzez:
 
 \begin{itemize}
     \item \textbf{Przyspieszanie spawnu przeciwników} -- interwał między
-    spawnem zmniejsza się liniowo od 0,25~s (początek) do 0,08~s (koniec),
+    \\ spawnem zmniejsza się liniowo od 0,25~s (początek) \\ do 0,08~s (koniec),
-    z~dodatkowym ,,finalnym szturmem'' przez ostatnie 5~sekund
+    z~dodatkowym ,,finalnym szturmem'' przez \\ ostatnie 5~sekund
     \item \textbf{Zwiększanie różnorodności typów przeciwników} -- początkowo
     (0--25\% czasu) pojawiają się tylko podstawowi przeciwnicy, później
     wprowadzane są kolejno szybsze jednostki (25--50\%), strzelające wieżyczki

latex/tex/implementacja-gry.tex

@@ -3,8 +3,6 @@
 \subsection{Implementacja w Unity}
 \label{subsec:impl-unity}
 
-\subsubsection{Środowisko i konfiguracja projektu}
-
 Projekt Unity został utworzony w~wersji LTS z~wykorzystaniem standardowego renderera 2D. Instalacja 
 silnika na systemie Linux przebiegła bezproblemowo dzięki Unity Hub 
 \cite{unity_hub} \cite{unity_hub_download_arch}, który zapewnia spójne 
@@ -12,14 +10,14 @@ zarządzanie wersjami edytora i~projektami.
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=1.0\textwidth]{tex/img/unity_hub_default_screen.png}
+    \includegraphics[width=0.9\textwidth]{tex/img/unity_hub_default_screen.png}
     \caption{Ekran powitalny Unity Hub.}
     \label{fig:unity_hub_welcome}
 \end{figure}
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=1.0\textwidth]{tex/img/unity_hub_editor_view.png}
+    \includegraphics[width=0.9\textwidth]{tex/img/unity_hub_editor_view.png}
     \caption{Widok edytora Unity.}
     \label{fig:unity_hub_editor_view}
 \end{figure}
@@ -29,7 +27,9 @@ zarządzanie wersjami edytora i~projektami.
 Implementacja Unity wykorzystuje kilka kluczowych wzorców projektowych:
 
 \paragraph{Wzorzec Bootstrap}
-Klasa \texttt{GameBootstrap} wykorzystuje atrybut \texttt{[Runtime\-Initialize\-OnLoad\-Method]} do zapewnienia, że obiekt \texttt{GameInitializer} istnieje w~scenie przed rozpoczęciem gry. Jest to eleganckie rozwiązanie problemu inicjalizacji singletonów w~Unity.
+Klasa \texttt{GameBootstrap} wykorzystuje atrybut \\ \texttt{[Runtime\-Initialize\-OnLoad\-Method]} 
+do zapewnienia, że obiekt \\ \texttt{GameInitializer} istnieje w~scenie przed rozpoczęciem gry. 
+Jest to eleganckie rozwiązanie problemu inicjalizacji singletonów w~Unity.
 
 \paragraph{Object Pooling}
 System \texttt{BulletPool} stanowi rdzeń optymalizacji wydajnościowej. Zamiast ciągłego tworzenia i niszczenia obiektów pocisków (co generowałoby znaczące obciążenie garbage collectora), pociski są recyklingowane z puli:
@@ -70,9 +70,9 @@ Przeciwnicy są definiowani przez strukturę \texttt{EnemyBlueprint}, która zaw
 Podczas implementacji napotkano następujące wyzwania:
 
 \begin{enumerate}
-    \item \textbf{Garbage Collection} -- początkowa implementacja bez object poolingu powodowała zauważalne spadki klatek przy dużej liczbie pocisków
+    \item \textbf{Garbage Collection} -- początkowa implementacja bez \\ object poolingu powodowała zauważalne spadki klatek przy dużej liczbie pocisków
     \item \textbf{Kolejność inicjalizacji} -- konieczność użycia wzorca Bootstrap wynikała z~nieprzewidywalnej kolejności wywoływania metod \texttt{Awake()} i~\texttt{Start()}
-    \item \textbf{Serializacja} -- atrybuty \texttt{[SerializeField]} wymagały starannego rozplanowania, które pola powinny być edytowalne w~inspektorze
+    \item \textbf{Serializacja} -- atrybuty \texttt{[SerializeField]} wymagały \\ starannego rozplanowania, które pola powinny być edytowalne w~inspektorze
     \item Interfejs użytkownika nie jest odświeżany po otwarciu menu \cite{linux_editor_does_not_redraw} -- wymagało to ręcznego wymuszenia odświeżenia inspektora
 \end{enumerate}
 
@@ -146,7 +146,7 @@ tradycyjny sposób
 
 \subsubsection{Object Pooling w Unreal}
 
-Implementacja object poolingu w~Unreal wymaga innego podejścia niż w~Unity. 
+Implementacja object poolingu w~Unreal wymaga innego podejścia \\ niż w Unity.
 Zamiast prostego \texttt{SetActive(true/\allowbreak false)}, Unreal wykorzystuje:
 
 \begin{itemize}
@@ -164,7 +164,7 @@ Ta granularność daje większą kontrolę, ale wymaga więcej kodu do osiągni
     \item \textbf{Czas kompilacji} -- kompilacja projektów C++ jest znacznie wolniejsza niż kompilacja C\# w Unity
     \item \textbf{Rozmiar projektu} -- nawet prosty projekt Unreal zajmuje wielokrotnie więcej miejsca na dysku
     \item \textbf{Dokumentacja} -- dla mniej popularnych zastosowań (jak gry 2D) dokumentacja jest ograniczona
-    \item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co utrudnia merge'owanie i code review
+    \item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co \\ utrudnia merge'owanie i code review
 \end{enumerate}
 
 \subsubsection{Pozytywne aspekty Unreal}
@@ -204,7 +204,7 @@ Rozmiar projektu & Mały & Duży \\
 \hline
 \end{tabular}
 \end{table}
-
+\newpage
 \subsection{Wnioski z implementacji}
 
 Doświadczenia z implementacji gry bullet-hell potwierdzają, że wybór silnika powinien być uzależniony od typu projektu:
@@ -213,8 +213,10 @@ Doświadczenia z implementacji gry bullet-hell potwierdzają, że wybór silnika
     \item \textbf{Dla gier 2D} -- Unity oferuje znacznie lepsze wsparcie natywne, niższy próg wejścia i szybszy cykl iteracji
     \item \textbf{Dla gier 3D AAA} -- Unreal Engine dysponuje lepszymi narzędziami do tworzenia fotorealistycznej grafiki
     \item \textbf{Dla prototypowania} -- Unity pozwala na szybsze testowanie koncepcji dzięki hot reloadowi i prostszej konfiguracji
-    \item \textbf{Dla zespołów mieszanych} -- Blueprinty Unreal mogą być wartościowe dla współpracy z designerami, choć problemy z kontrolą wersji stanowią wyzwanie
+    \item \textbf{Dla zespołów mieszanych} -- Blueprinty Unreal mogą być \\ wartościowe dla współpracy 
+    z designerami, choć problemy \\ z kontrolą wersji stanowią wyzwanie
 \end{enumerate}
 
-Implementacja gry bullet-hell w~Unity zajęła około 60\% czasu potrzebnego na implementację analogicznej funkcjonalności 
+Implementacja gry bullet-hell w~Unity zajęła około 60\% czasu potrzebnego na implementację 
-w~Unreal Engine, głównie ze względu na natywne wsparcie 2D i~prostszy system object poolingu.
+analogicznej  funkcjonalności 
+w Unreal Engine, głównie ze względu na natywne wsparcie 2D i prostszy system object poolingu.

latex/tex/narzedzia-profilowania.tex

@@ -14,7 +14,7 @@ Zarówno Unity, jak i~Unreal Engine oferują własne, wbudowane narzędzia do an
 Unity dostarcza rozbudowany profiler dostępny bezpośrednio w~edytorze (Window $\rightarrow$ Analysis $\rightarrow$ Profiler)~\cite{unity_profiler}. Narzędzie to oferuje:
 
 \begin{itemize}
-    \item \textbf{CPU Profiler} -- analiza czasu wykonania poszczególnych funkcji, z~podziałem na kategorie (rendering, skrypty, fizyka, animacje)
+    \item \textbf{CPU Profiler} -- analiza czasu wykonania poszczególnych funkcji, z podziałem na kategorie (rendering, skrypty, fizyka, animacje)
     \item \textbf{GPU Profiler} -- pomiar czasu renderowania na karcie graficznej
     \item \textbf{Memory Profiler} -- szczegółowa analiza alokacji pamięci, wykrywanie wycieków
     \item \textbf{Audio Profiler} -- monitorowanie obciążenia systemu dźwiękowego
@@ -26,7 +26,7 @@ Unity Profiler umożliwia również zdalne profilowanie aplikacji uruchomionej n
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=1.0\textwidth]{tex/img/unity_profiler.png}
+    \includegraphics[width=0.9\textwidth]{tex/img/unity_profiler.png}
     \caption{Interfejs Unity Profiler z~widokiem analizy wydajności CPU i~GPU.}
     \label{fig:unity-profiler}
 \end{figure}
@@ -47,7 +47,7 @@ Dodatkowo Unreal Engine udostępnia komendy konsolowe (np.~\texttt{stat fps}, \t
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=1.0\textwidth]{tex/img/unreal_profiler.png}
+    \includegraphics[width=0.9\textwidth]{tex/img/unreal_profiler.png}
     \caption{Interfejs Unreal Insights z~widokiem analizy wydajności.}
     \label{fig:unreal-profiler}
 \end{figure}
@@ -58,7 +58,7 @@ Pomimo rozbudowanych możliwości, wbudowane profilery silników posiadają isto
 
 \begin{enumerate}
     \item \textbf{Brak standaryzacji metryk} -- każdy silnik definiuje i~mierzy parametry w~odmienny sposób, co utrudnia bezpośrednie porównania
-    \item \textbf{Różna granularność danych} -- poziom szczegółowości raportów różni się między silnikami
+    \item \textbf{Różna granularność danych} -- poziom szczegółowości raportów \\ różni się między silnikami
     \item \textbf{Narzut profilowania} -- wbudowane profilery same generują obciążenie, które może być różne dla każdego silnika
     \item \textbf{Nieporównywalność formatów wyjściowych} -- dane eksportowane przez różne profilery mają odmienne struktury
 \end{enumerate}
@@ -74,7 +74,7 @@ niezależnie od używanego silnika czy API graficznego~\cite{nvidia_nsight}.
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=1.0\textwidth]{tex/img/nvidia_nsight.jpg}
+    \includegraphics[width=0.9\textwidth]{tex/img/nvidia_nsight.jpg}
     \caption{Interfejs NVIDIA Nsight Graphics z~widokiem analizy GPU.}
     \label{fig:nvidia-nsight}
 \end{figure}
@@ -88,7 +88,7 @@ był następującymi czynnikami:
     \item \textbf{Niezależność od silnika} -- Nsight analizuje aplikację na poziomie wywołań API graficznego (DirectX, Vulkan, OpenGL), co zapewnia porównywalność wyników między Unity a~Unreal Engine
     \item \textbf{Standaryzowane metryki} -- narzędzie dostarcza zunifikowany zestaw metryk sprzętowych (GPU utilization, memory bandwidth, shader throughput)
     \item \textbf{Minimalny narzut} -- profilowanie na poziomie sterownika generuje mniejsze zakłócenia niż profilery działające wewnątrz silnika
-    \item \textbf{Dostęp do danych niskopoziomowych} -- możliwość analizy poszczególnych wywołań draw call, shaderów, transferów pamięci
+    \item \textbf{Dostęp do danych niskopoziomowych} -- możliwość analizy \\ poszczególnych wywołań draw call, shaderów, transferów pamięci
     \item \textbf{Spójny format danych} -- wyniki z~obu silników mają identyczną strukturę, co ułatwia automatyzację analizy
 \end{itemize}
 

latex/tex/wywiady-analiza.tex

@@ -81,7 +81,9 @@ Jednocześnie wskazywano na problemy wynikające z długu technologicznego Unity
 
 \subsubsection{Struktura Unreal Engine}
 
-Architektura Unreal Engine wymusza bardziej uporządkowany styl pracy. Respondenci zauważali, że nawet podstawowe projekty tworzone w Unreal mają tendencję do bycia lepiej zorganizowanymi, ponieważ silnik narzuca określoną strukturę.
+Architektura Unreal Engine wymusza bardziej uporządkowany \\ styl pracy. Respondenci zauważali, 
+że nawet podstawowe projekty tworzone w Unreal mają tendencję do bycia lepiej zorganizowanymi, 
+ponieważ silnik narzuca określoną strukturę.
 
 Struktura aktor-komponent w Unreal (level zawiera aktorów, aktorzy zawierają komponenty) została opisana jako bardziej restrykcyjna niż prefaby w Unity. Próby tworzenia zagnieżdżonych struktur (aktor w aktorze) często prowadzą do problemów, podczas gdy w Unity hierarchie prefabów są bardziej elastyczne.
 
@@ -141,9 +143,13 @@ Unity wymaga więcej pracy przy tworzeniu narzędzi dla osób nietechnicznych. R
 
 \subsubsection{Dostępność i jakość assetów}
 
-Asset Store Unity był oceniany jako lepiej zarządzany i bogatszy. Respondenci wskazywali na silniejsze wsparcie społeczności i większe szanse na znalezienie potrzebnych zasobów.
+Asset Store Unity był oceniany jako lepiej zarządzany i bogatszy. \\
+Respondenci wskazywali na silniejsze wsparcie społeczności i większe szanse na 
+znalezienie potrzebnych zasobów.
 
-Interesującą obserwacją było to, że najlepsze produkty z Asset Store mają tendencję do opuszczania platformy -- twórcy zakładają własne strony internetowe po osiągnięciu określonego poziomu popularności.
+Interesującą obserwacją było to, że najlepsze produkty z Asset Store mają tendencję do 
+opuszczania platformy -- twórcy zakładają własne \\ strony internetowe po osiągnięciu określonego 
+poziomu popularności.
 
 Unreal Marketplace przeszedł niedawno transformację w platformę Fab, co według respondentów pogorszyło doświadczenie użytkownika i zwiększyło liczbę kroków potrzebnych do pobrania darmowych zasobów.
 
@@ -184,7 +190,9 @@ Problem garbage collectora w Unity był wielokrotnie wspominany jako znany probl
 
 \subsubsection{Entity Component System (ECS)}
 
-Nowy system DOTS/ECS w Unity był oczekiwaną funkcjonalnością, która w momencie przeprowadzania wywiadów została już oficjalnie wydana. System ten pozwala na pisanie wysoce wydajnego, zorientowanego na dane kodu, kosztem większej złożoności programistycznej.
+Nowy system DOTS/ECS w Unity był oczekiwaną funkcjonalnością, \\ która w momencie przeprowadzania 
+wywiadów została już \\ oficjalnie wydana. System ten pozwala na pisanie wysoce wydajnego, 
+zorientowanego na dane kodu, kosztem większej złożoności programistycznej.
 
 \subsubsection{UI Toolkit}
 
@@ -221,7 +229,7 @@ Na podstawie przeprowadzonych wywiadów można sformułować następujące wnios
 \subsubsection{Silne strony Unreal Engine}
 \begin{itemize}
     \item Wymuszona struktura projektu promująca dobre praktyki
-    \item System Blueprints ułatwiający współpracę z osobami nietechnicznymi
+    \item System Blueprints ułatwiający współpracę z osobami \\ nietechnicznymi
     \item Więcej gotowych funkcjonalności ,,out of the box''
     \item Lepsze wsparcie dla projektów wysokobudżetowych (grafika, multiplayer)
     \item Dostęp do kodu źródłowego silnika