diff --git a/latex/main.pdf b/latex/main.pdf index bd6786f..b7b488b 100644 Binary files a/latex/main.pdf and b/latex/main.pdf differ diff --git a/latex/main.tex b/latex/main.tex index 1c6eba6..00f118f 100644 --- a/latex/main.tex +++ b/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} diff --git a/latex/tex/1-wstep.tex b/latex/tex/1-wstep.tex index cf0a3a4..0761d31 100644 --- a/latex/tex/1-wstep.tex +++ b/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. diff --git a/latex/tex/2-przeglad-literatury.tex b/latex/tex/2-przeglad-literatury.tex index 2dcd1c9..a7a6b25 100644 --- a/latex/tex/2-przeglad-literatury.tex +++ b/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 -aspektach, takich jak wydajność renderowania, łatwość użycia czy +silników gier, jednak większość z nich koncentruje się na wybranych \\ +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. diff --git a/latex/tex/3-silniki-gier.tex b/latex/tex/3-silniki-gier.tex index 620fead..37a2f7a 100644 --- a/latex/tex/3-silniki-gier.tex +++ b/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ą -liczbę komponentów definiujących jego zachowanie. -Podejście to promuje kompozycję nad dziedziczeniem i ułatwia +\\ gdzie każdy obiekt w scenie (GameObject) może posiadać dowolną +liczbę \\ komponentów definiujących jego zachowanie. +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 diff --git a/latex/tex/4-metodologia.tex b/latex/tex/4-metodologia.tex index 91ab3d8..7d7c440 100644 --- a/latex/tex/4-metodologia.tex +++ b/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), - z~dodatkowym ,,finalnym szturmem'' przez ostatnie 5~sekund + \\ spawnem zmniejsza się liniowo od 0,25~s (początek) \\ do 0,08~s (koniec), + 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 diff --git a/latex/tex/implementacja-gry.tex b/latex/tex/implementacja-gry.tex index d319f3f..82c3607 100644 --- a/latex/tex/implementacja-gry.tex +++ b/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 -w~Unreal Engine, głównie ze względu na natywne wsparcie 2D i~prostszy system object poolingu. +Implementacja gry bullet-hell w~Unity zajęła około 60\% czasu potrzebnego na implementację +analogicznej funkcjonalności +w Unreal Engine, głównie ze względu na natywne wsparcie 2D i prostszy system object poolingu. \ No newline at end of file diff --git a/latex/tex/narzedzia-profilowania.tex b/latex/tex/narzedzia-profilowania.tex index 18dbf37..d04fc36 100644 --- a/latex/tex/narzedzia-profilowania.tex +++ b/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} diff --git a/latex/tex/wywiady-analiza.tex b/latex/tex/wywiady-analiza.tex index 947c4e0..63726b7 100644 --- a/latex/tex/wywiady-analiza.tex +++ b/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