mirror of
https://github.com/kuhyx/praca_magisterska.git
synced 2026-07-04 13:43:05 +02:00
fix: most hbox issues
This commit is contained in:
parent
066ab6e805
commit
01940e6ae1
BIN
latex/main.pdf
BIN
latex/main.pdf
Binary file not shown.
@ -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}
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user