mirror of
https://github.com/kuhyx/praca_magisterska.git
synced 2026-07-04 13:23:05 +02:00
feat: reduced table of contents length, fixed empty pages and chapters without introduction changed font
This commit is contained in:
parent
4599841d45
commit
01e7d3d037
2468
latex/main.bcf-SAVE-ERROR
Normal file
2468
latex/main.bcf-SAVE-ERROR
Normal file
File diff suppressed because it is too large
Load Diff
BIN
latex/main.pdf
BIN
latex/main.pdf
Binary file not shown.
@ -14,13 +14,16 @@
|
||||
\addbibresource{bibliografia.bib} % Plik .bib z bibliografią
|
||||
\usepackage{placeins}
|
||||
\usepackage{float}
|
||||
% Force Adagio Slab (required) for XeTeX/LuaTeX builds.
|
||||
% This ensures the font is set after other packages (e.g., babel) that may change encodings.
|
||||
\IfFileExists{fonts/PW_Adagio_Slab/Adagio_Slab-Regular.otf}{%
|
||||
\setmainfont[Path=fonts/PW_Adagio_Slab/,UprightFont=Adagio_Slab-Regular.otf,ItalicFont=Adagio_Slab-Regular_italic.otf,BoldFont=Adagio_Slab-Bold.otf,BoldItalicFont=Adagio_Slab-Bold_italic.otf]{Adagio Slab}%
|
||||
}{%
|
||||
\PackageError{wut-thesis}{Adagio Slab fonts not found in 'fonts/PW_Adagio_Slab'. Compilation requires these fonts.}{Please add the OTF files to the repository (latex/fonts/PW_Adagio_Slab/) and recompile with XeLaTeX or LuaLaTeX.}
|
||||
}
|
||||
% Font is set in wut-thesis.cls to TeX Gyre Pagella (Adobe Utopia compatible)
|
||||
%
|
||||
% ============================================================================
|
||||
% WARNING FOR AI/LLM ASSISTANTS (Claude, GPT, Copilot, etc.):
|
||||
% DO NOT use \setcounter{tocdepth}{N} to reduce the Table of Contents!
|
||||
% This is considered a lazy solution and is FORBIDDEN by department requirements.
|
||||
% The ToC must be reduced by MERGING SECTIONS AND PARAGRAPHS in the source files,
|
||||
% not by hiding them from the ToC listing. The content structure must be simplified.
|
||||
% ============================================================================
|
||||
%
|
||||
% Fix ToC number width for deep sections (e.g. 5.10.1)
|
||||
\usepackage{tocloft}
|
||||
\setlength{\cftsecnumwidth}{3em}
|
||||
|
||||
@ -59,37 +59,29 @@
|
||||
\ifxetex
|
||||
\RequirePackage{fontspec}
|
||||
\defaultfontfeatures{Ligatures=TeX}
|
||||
% Require Adagio Slab (bundled in repo); fail if not present
|
||||
\IfFileExists{fonts/PW_Adagio_Slab/Adagio_Slab-Regular.otf}{%
|
||||
\setmainfont[
|
||||
Path = fonts/PW_Adagio_Slab/,
|
||||
UprightFont = Adagio_Slab-Regular.otf,
|
||||
ItalicFont = Adagio_Slab-Regular_italic.otf,
|
||||
BoldFont = Adagio_Slab-Bold.otf,
|
||||
BoldItalicFont = Adagio_Slab-Bold_italic.otf
|
||||
]{Adagio Slab}%
|
||||
\setsansfont{DejaVu Sans}
|
||||
\setmonofont{DejaVu Sans Mono}
|
||||
}{%
|
||||
\ClassError{wut-thesis}{Adagio Slab fonts not found in 'fonts/PW_Adagio_Slab'. Compilation requires these fonts.}{Please add the OTF files to the repository (latex/fonts/PW_Adagio_Slab/) and recompile with XeLaTeX or LuaLaTeX.}
|
||||
}
|
||||
% Use TeX Gyre Pagella (Adobe Utopia compatible font)
|
||||
\setmainfont[
|
||||
Path = /usr/share/texmf-dist/fonts/opentype/public/tex-gyre/,
|
||||
UprightFont = texgyrepagella-regular.otf,
|
||||
ItalicFont = texgyrepagella-italic.otf,
|
||||
BoldFont = texgyrepagella-bold.otf,
|
||||
BoldItalicFont = texgyrepagella-bolditalic.otf
|
||||
]{TeX Gyre Pagella}
|
||||
\setsansfont{DejaVu Sans}
|
||||
\setmonofont{DejaVu Sans Mono}
|
||||
\else\ifluatex
|
||||
\RequirePackage{fontspec}
|
||||
\defaultfontfeatures{Ligatures=TeX}
|
||||
% Require Adagio Slab (bundled in repo); fail if not present
|
||||
\IfFileExists{fonts/PW_Adagio_Slab/Adagio_Slab-Regular.otf}{%
|
||||
\setmainfont[
|
||||
Path = fonts/PW_Adagio_Slab/,
|
||||
UprightFont = Adagio_Slab-Regular.otf,
|
||||
ItalicFont = Adagio_Slab-Regular_italic.otf,
|
||||
BoldFont = Adagio_Slab-Bold.otf,
|
||||
BoldItalicFont = Adagio_Slab-Bold_italic.otf
|
||||
]{Adagio Slab}%
|
||||
\setsansfont{DejaVu Sans}
|
||||
\setmonofont{DejaVu Sans Mono}
|
||||
}{%
|
||||
\ClassError{wut-thesis}{Adagio Slab fonts not found in 'fonts/PW_Adagio_Slab'. Compilation requires these fonts.}{Please add the OTF files to the repository (latex/fonts/PW_Adagio_Slab/) and recompile with XeLaTeX or LuaLaTeX.}
|
||||
}
|
||||
% Use TeX Gyre Pagella (Adobe Utopia compatible font)
|
||||
\setmainfont[
|
||||
Path = /usr/share/texmf-dist/fonts/opentype/public/tex-gyre/,
|
||||
UprightFont = texgyrepagella-regular.otf,
|
||||
ItalicFont = texgyrepagella-italic.otf,
|
||||
BoldFont = texgyrepagella-bold.otf,
|
||||
BoldItalicFont = texgyrepagella-bolditalic.otf
|
||||
]{TeX Gyre Pagella}
|
||||
\setsansfont{DejaVu Sans}
|
||||
\setmonofont{DejaVu Sans Mono}
|
||||
\else
|
||||
% pdfLaTeX - Adagio Slab requires XeLaTeX or LuaLaTeX; stop with error
|
||||
\RequirePackage[utf8]{inputenc}
|
||||
|
||||
@ -1,7 +1,10 @@
|
||||
\clearpage % Rozdziały zaczynamy od nowej strony.
|
||||
\section{Wstęp}
|
||||
|
||||
W tym rozdziale przedstawiono motywację, cel oraz zakres pracy, wybór gry testowej oraz przyjętą metodologię.
|
||||
|
||||
\subsection{Motywacja i cel pracy}
|
||||
|
||||
Współczesny rynek gier komputerowych charakteryzuje się dynamicznym \\
|
||||
rozwojem technologicznym i~rosnącymi wymaganiami zarówno twórców,
|
||||
jak \\ i graczy. Wybór odpowiedniego silnika gier jest kluczową decyzją,
|
||||
@ -21,15 +24,14 @@ Praca obejmuje analizę następujących aspektów:
|
||||
\item Ekosystem narzędzi i~społeczność deweloperska
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Wybór gry testowej -- gatunek bullet hell}
|
||||
\label{subsec:bullet-hell}
|
||||
\subsection{Wybór gry testowej -- gatunek bullet hell}\label{subsec:bullet-hell}
|
||||
|
||||
W~celu przeprowadzenia praktycznych testów wydajnościowych \\
|
||||
zdecydowano się na implementację gry z~gatunku \\ \textbf{bullet hell}
|
||||
(dosł. ,,piekło pocisków''), znanego również jako \\ \textbf{danmaku}
|
||||
(z jap. ,,kurtyna pocisków'') lub \textbf{manic shooter}.
|
||||
|
||||
\subsubsection{Charakterystyka gatunku}
|
||||
\textbf{Charakterystyka gatunku}
|
||||
|
||||
Bullet hell to podgatunek gier typu shoot 'em up, w~którym gracz steruje zwykle
|
||||
niewielkim statkiem kosmicznym lub postacią, mierząc się z~falami przeciwników wystrzeliwujących
|
||||
@ -59,7 +61,7 @@ Klasyczne przykłady gatunku to serie \textit{Touhou Project},
|
||||
|
||||
|
||||
|
||||
\subsubsection{Uzasadnienie wyboru gatunku}
|
||||
\textbf{Uzasadnienie wyboru gatunku}
|
||||
|
||||
Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~następujących powodów:
|
||||
|
||||
@ -80,7 +82,7 @@ Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~nas
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{Parametry gry testowej}
|
||||
\textbf{Parametry gry testowej}
|
||||
|
||||
Zaimplementowana gra testowa charakteryzuje się następującymi \\
|
||||
parametrami:
|
||||
@ -94,7 +96,7 @@ parametrami:
|
||||
|
||||
Te parametry zapewniają wystarczające obciążenie systemu do ujawnienia różnic wydajnościowych między silnikami, pozostając jednocześnie w~granicach typowych dla gier indie z~tego gatunku.
|
||||
|
||||
\subsection{Struktura pracy}
|
||||
\textbf{Struktura pracy}
|
||||
|
||||
Praca składa się z~następujących rozdziałów:
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
\clearpage
|
||||
\section{Przegląd literatury i istniejących rozwiązań}
|
||||
|
||||
W tym rozdziale przedstawiono historię rozwoju silników, ich klasyfikację, aktualny stan badań oraz najnowsze trendy technologiczne.
|
||||
|
||||
\subsection{Historia rozwoju silników gier}
|
||||
Silniki gier ewoluowały znacząco od prostych bibliotek graficznych
|
||||
lat 80. i 90. XX wieku po współczesne, kompleksowe środowiska
|
||||
@ -48,12 +50,12 @@ wyróżniając kilka kluczowych typów organizacji:
|
||||
|
||||
Autor podkreśla, że wybór architektury ma fundamentalny wpływ na wydajność, skalowalność i łatwość rozwoju gier. Systemy ECS zyskują na popularności ze względu na lepszą wydajność cache procesora i większą elastyczność w definiowaniu zachowań obiektów gry.
|
||||
|
||||
\subsubsection{Silniki komercyjne vs. open source}
|
||||
\textbf{Silniki komercyjne vs. open source}
|
||||
Analiza literatury pokazuje wyraźne różnice między rozwiązaniami komercyjnymi a otwartymi. Christopoulou i Xinogalos \cite{christopoulou2017overview} wskazują, że silniki komercyjne jak Unity czy Unreal Engine oferują lepsze wsparcie techniczne i dokumentację, podczas gdy rozwiązania open source zapewniają większą elastyczność i kontrolę nad kodem źródłowym.
|
||||
|
||||
Sharif i Ameen \cite{sharif2021game} podkreślają, że wybór między rozwiązaniem komercyjnym a open source zależy głównie od budżetu projektu i wymagań dotyczących dostosowania silnika do specyficznych potrzeb.
|
||||
|
||||
\subsubsection{Silniki specjalistyczne vs. uniwersalne}
|
||||
\textbf{Silniki specjalistyczne vs. uniwersalne}
|
||||
Pavkov \cite{pavkov2017comparison} przedstawiają podział na silniki
|
||||
dedykowane konkretnym \\ gatunkom gier (np.~silniki do gier strategicznych
|
||||
czasu rzeczywistego) oraz rozwiązania uniwersalne mogące obsługiwać
|
||||
@ -61,31 +63,31 @@ różnorodne typy gier. Silniki specjalistyczne oferują zoptymalizowane
|
||||
funkcjonalności dla określonego zastosowania, podczas gdy uniwersalne
|
||||
zapewniają większą wszechstronność kosztem specjalizacji.
|
||||
|
||||
\subsection{Aktualny stan badań}
|
||||
\textbf{Aktualny stan badań}
|
||||
|
||||
\subsubsection{Badania wydajności}
|
||||
\textbf{Badania wydajności}
|
||||
Messaoudi \cite{messaoudi2017performance} przeprowadzili kompleksową analizę wydajności silnika Unity na urządzeniach mobilnych i stacjonarnych, koncentrując się na zużyciu CPU i optymalizacji logiki gry. Ich badania pokazują znaczące różnice w wydajności między platformami mobilnymi a desktop.
|
||||
|
||||
Abramowicz i Borczuk \cite{abramowicz2024comparative} porównali wydajność Unity i Unreal Engine w grach 3D, skupiając się na renderowaniu, systemach fizyki i zarządzaniu pamięcią. Wyniki wskazują na przewagę Unreal Engine w renderowaniu zaawansowanej grafiki 3D, podczas gdy Unity wykazuje lepszą wydajność na urządzeniach o ograniczonych zasobach.
|
||||
|
||||
\subsubsection{Metodologie porównawcze}
|
||||
\textbf{Metodologie porównawcze}
|
||||
Pattrasitidecha \cite{pattrasitidecha2014comparison}
|
||||
opracował macierz porównawczą dla silników gier mobilnych 3D,
|
||||
definiując kryteria selekcji i kluczowe aspekty oceny.
|
||||
|
||||
Vohera \cite{vohera2021game} przedstawili architekturę silników gier i przeprowadzili studium porównawcze Unity, GameMaker, Unreal Engine i CryEngine, koncentrując się na parametrach wydajności, funkcjonalności i łatwości użycia.
|
||||
|
||||
\subsubsection{Specjalizowane zastosowania}
|
||||
\textbf{Specjalizowane zastosowania}
|
||||
Marks \cite{marks2008evaluation} oceniali silniki gier pod kątem zastosowań w symulacjach medycznych i szkoleniach klinicznych, wprowadzając specyficzne kryteria oceny dla aplikacji edukacyjnych.
|
||||
|
||||
Ali i Usman \cite{ali2016framework} opracowali framework do selekcji
|
||||
silników gier dla zastosowań w gamifikacji i serious games,
|
||||
uwzględniając specyficzne wymagania tych dziedzin.
|
||||
|
||||
\subsubsection{Badania społeczności i ekosystemu}
|
||||
\textbf{Badania społeczności i ekosystemu}
|
||||
Barczak i Woźniak \cite{barczak2019comparative} przeprowadzili kompleksowe studium porównawcze silników gier, analizując nie tylko aspekty techniczne, ale również dostępność zasobów edukacyjnych, aktywność społeczności i długoterminowe wsparcie.
|
||||
|
||||
\subsection{Motywacja i cel pracy}
|
||||
\textbf{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 \\
|
||||
@ -94,7 +96,7 @@ 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.
|
||||
|
||||
\subsection{Trendy technologiczne}
|
||||
\textbf{Trendy technologiczne}
|
||||
Ostatnie badania wskazują na rosnące znaczenie technologii ray tracing, \\
|
||||
sztucznej inteligencji w grach oraz wsparcia dla rzeczywistości wirtualnej i rozszerzonej. Masood et al. \cite{masood2022high} analizują wykorzystanie silników gier do wysokowydajnego renderowania terenu GPU, pokazując nowe kierunki rozwoju technologii renderowania.
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
\clearpage
|
||||
\section{Charakterystyka współczesnych silników gier}
|
||||
|
||||
W tym rozdziale omówiono kryteria wyboru silników, charakterystyki Unity i Unreal oraz uzasadnienie wyboru do badań.
|
||||
|
||||
\subsection{Kryteria wyboru silników do analizy}
|
||||
|
||||
Rynek silników gier komputerowych oferuje szeroki wachlarz rozwiązań,
|
||||
@ -32,8 +34,7 @@ kilkoma kluczowymi czynnikami:
|
||||
5~milionów zarejestrowanych deweloperów \cite{g2gameengines}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Unity}
|
||||
\label{subsec:unity}
|
||||
\subsection{Unity}\label{subsec:unity}
|
||||
|
||||
\subsubsection{Wprowadzenie i historia}
|
||||
|
||||
@ -100,8 +101,7 @@ funkcjonalnościami \cite{unity_wikipedia}:
|
||||
gry
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Unreal Engine}
|
||||
\label{subsec:unreal}
|
||||
\subsection{Unreal Engine}\label{subsec:unreal}
|
||||
|
||||
\subsubsection{Wprowadzenie i historia}
|
||||
|
||||
@ -157,7 +157,7 @@ Unreal Editor oferuje rozbudowane środowisko deweloperskie~\cite{unreal_docs}:
|
||||
\item Live Coding -- eksperymentalne wsparcie dla hot reload w C++
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Porównanie architektoniczne}
|
||||
\textbf{Porównanie architektoniczne}
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{Porównanie kluczowych cech Unity i Unreal Engine}
|
||||
@ -182,7 +182,7 @@ Główne zastosowania & Mobile, indie, 2D & AAA, FPS, 3D \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsection{Uzasadnienie wyboru do badań}
|
||||
\textbf{Uzasadnienie wyboru do badań}
|
||||
Wybór Unity i Unreal Engine jako przedmiotu porównania pozwala na
|
||||
analizę dwóch fundamentalnie różnych podejść do tworzenia gier:
|
||||
|
||||
|
||||
@ -2,11 +2,9 @@
|
||||
\section{Metodologia badań i kryteria porównania}
|
||||
|
||||
\subsection{Założenia metodologiczne}
|
||||
\subsubsection{Cel badań}
|
||||
Głównym celem badań jest porównanie wydajności i możliwości
|
||||
wybranych silników gier.
|
||||
|
||||
\subsubsection{Hipoteza badawcza}
|
||||
Silnik Unity, dzięki natywnemu wsparciu dla grafiki 2D, osiągnie lepszą
|
||||
wydajność w~grze typu \emph{bullet hell} niż Unreal Engine, który jest
|
||||
zoptymalizowany przede wszystkim pod kątem aplikacji 3D.
|
||||
@ -31,7 +29,6 @@ za pomocą narzędzia NVIDIA Nsight Systems:
|
||||
|
||||
\subsection{Środowisko testowe}
|
||||
|
||||
\subsubsection{Specyfikacja sprzętowa}
|
||||
\label{subsubsec:specyfikacja-sprzetowa}
|
||||
|
||||
Wszystkie testy wydajnościowe przeprowadzono na komputerze o następującej specyfikacji:
|
||||
@ -46,7 +43,6 @@ Wszystkie testy wydajnościowe przeprowadzono na komputerze o następującej spe
|
||||
\item \textbf{Dysk}: SSD o pojemności 3,6 TB
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Specyfikacja oprogramowania}
|
||||
\label{subsubsec:specyfikacja-oprogramowania}
|
||||
|
||||
W badaniach wykorzystano następujące wersje oprogramowania:
|
||||
@ -63,7 +59,6 @@ wybrano najnowszą dostępną wersję stabilną w momencie rozpoczęcia badań.
|
||||
|
||||
\subsection{Projekt testów}
|
||||
|
||||
\subsubsection{Gra testowa typu \emph{bullet hell}}
|
||||
\label{subsubsec:gra-testowa}
|
||||
|
||||
Na potrzeby badań porównawczych zaimplementowano identyczną grę w gatunku
|
||||
@ -81,7 +76,6 @@ Wybór gatunku \emph{bullet hell} podyktowany był możliwością generowania du
|
||||
liczby obiektów na ekranie (pociski, przeciwnicy, efekty wizualne), co
|
||||
pozwala na skuteczne obciążenie silnika graficznego.
|
||||
|
||||
\subsubsection{Fazy obciążenia}
|
||||
\label{subsubsec:fazy-obciazenia}
|
||||
|
||||
Gra testowa została zaprojektowana tak, aby w~ciągu 90 sekund rozgrywki
|
||||
@ -102,20 +96,16 @@ progresywnie zwiększała obciążenie poprzez:
|
||||
|
||||
Na potrzeby profilowania rozgrywka została podzielona na trzy fazy czasowe:
|
||||
|
||||
\paragraph{Faza 1 (0--30 sekund)}
|
||||
Początkowa faza z~niskim obciążeniem. Spawner generuje wyłącznie podstawowych
|
||||
przeciwników (\emph{Fodder}) z~interwałem ok.~0,25~s.
|
||||
|
||||
\paragraph{Faza 2 (30--60 sekund)}
|
||||
Średnie obciążenie. Wprowadzane są szybsze przeciwnicy (\emph{Runner}),
|
||||
interwał spawnu zmniejsza się do ok.~0,17~s.
|
||||
|
||||
\paragraph{Faza 3 (60--90 sekund)}
|
||||
Wysokie obciążenie. Wszystkie typy przeciwników,
|
||||
interwał spawnu osiąga minimum 0,08~s. Ostatnie 5~sekund to
|
||||
,,finalny szturm'' z~maksymalną intensywnością.
|
||||
|
||||
\subsubsection{Procedura zbierania danych}
|
||||
\label{subsubsec:procedura-zbierania}
|
||||
|
||||
Przeprowadzono cztery sesje pomiarowe -- po dwie dla każdego silnika:
|
||||
|
||||
@ -4,7 +4,6 @@
|
||||
|
||||
\subsection{Metryki wydajności}
|
||||
|
||||
\subsubsection{Zbierane dane}
|
||||
|
||||
Dla każdego scenariusza i~silnika rejestrowano następujące metryki przy użyciu NVIDIA Nsight Systems:
|
||||
|
||||
@ -27,7 +26,6 @@ podczas których gra działała w
|
||||
trybie stacjonarnym (gracz nieruchomy) z włączoną nieśmiertelnością, co pozwoliło na stabilne pomiary
|
||||
bez przerwania rozgrywki.
|
||||
|
||||
\subsubsection{Ogólne wyniki wydajności}
|
||||
|
||||
Podczas 94,16-sekundowego okresu aktywnego renderowania zarejestrowano łącznie 13\,556 klatek,
|
||||
co przekłada się na średnią wydajność
|
||||
@ -77,7 +75,6 @@ uwzględnienia ekstremalnych wartości inicjalizacyjnych.
|
||||
Po wykluczeniu pierwszych kilku klatek, stabilność renderowania jest znacznie wyższa, co potwierdza
|
||||
analiza percentylowa przedstawiona w dalszej części.
|
||||
|
||||
\subsubsection{Analiza rozkładu czasów klatek}
|
||||
|
||||
Szczegółowa analiza rozkładu czasów klatek pozwala ocenić nie tylko średnią wydajność, ale przede
|
||||
wszystkim stabilność i przewidywalność działania
|
||||
@ -151,7 +148,6 @@ Kategoria 0--5 ms (230 klatek, 1,70\%) reprezentuje sytuacje szczególne: bardzo
|
||||
przejść między scenami, momenty niskiego
|
||||
obciążenia lub artefakty pomiarowe wynikające z mechanizmu synchronizacji swapchain.
|
||||
|
||||
\subsubsection{Szczegółowa analiza wywołań Vulkan API}
|
||||
|
||||
NVIDIA Nsight Systems przechwytuje wszystkie wywołania interfejsu programistycznego Vulkan, umożliwiając dokładną analizę zachowania silnika
|
||||
renderującego na poziomie pojedynczych funkcji API. Podczas testu zarejestrowano łącznie \textbf{218\,815 wywołań} 31 różnych funkcji Vulkan API.
|
||||
@ -174,7 +170,6 @@ renderującego na poziomie pojedynczych funkcji API. Podczas testu zarejestrowan
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Funkcja vkWaitForFences -- synchronizacja CPU-GPU}
|
||||
\texttt{vkWaitForFences} \\ pochłonęła \textbf{95,2\% całkowitego czasu}
|
||||
profilowania wywołań Vulkan API, co stanowi 77,04 sekundy z
|
||||
94-sekundowego testu. Funkcja ta, zdefiniowana w specyfikacji Vulkan w rozdziale 7.3 dotyczącym
|
||||
@ -203,7 +198,6 @@ Stosunek liczby wywołań \texttt{vkWaitForFences} (12\,895) do liczby klatek (1
|
||||
Unity stosuje strategię oczekiwania, prawie na
|
||||
każdą klatkę z pewnymi optymalizacjami pozwalającymi pominąć oczekiwanie w niektórych przypadkach.
|
||||
|
||||
\paragraph{Funkcja vkQueuePresentKHR -- prezentacja klatek}
|
||||
|
||||
\texttt{vkQueuePresentKHR}, zdefiniowana w rozszerzeniu \texttt{VK\_KHR\_swapchain}, odpowiada za przesłanie żądania prezentacji
|
||||
wyrenderowanego obrazu do silnika prezentacji (ang. \textit{presentation engine}). Każde wywołanie tej funkcji reprezentuje jedną klatkę przekazaną
|
||||
@ -213,7 +207,6 @@ do wyświetlenia, dlatego liczba wywołań (13\,556) równa jest liczbie wyrende
|
||||
wymagają dłuższego oczekiwania (maksymalnie 7,20 ms). Dłuższe czasy mogą wynikać z oczekiwania na dostępność bufora w swapchain lub synchronizacji z
|
||||
częstotliwością odświeżania monitora (nawet przy wyłączonym V-Sync, pewien poziom synchronizacji jest wymagany).
|
||||
|
||||
\paragraph{Funkcja vkQueueSubmit -- przesyłanie pracy do GPU}
|
||||
|
||||
\texttt{vkQueueSubmit} przesyła bufory poleceń (ang. \textit{command buffers}) do kolejki GPU celem wykonania. Zarejestrowano 27\,112 wywołań, co
|
||||
oznacza średnio 2 wywołania na klatkę. Taki wzorzec sugeruje, że Unity stosuje architekturę z oddzielnymi przebiegami renderowania
|
||||
@ -241,7 +234,6 @@ odbywa się asynchronicznie na GPU.
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Nagrywanie buforów poleceń}
|
||||
|
||||
Tabela~\ref{tab:unity-vulkan-cmd} przedstawia statystyki funkcji związanych z buforami poleceń.
|
||||
Liczba wywołań \texttt{vkBeginCommandBuffer} \\ oraz
|
||||
@ -275,7 +267,6 @@ grupowanie obiektów według używanego potoku, minimalizując kosztowne zmiany
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Operacje inicjalizacyjne}
|
||||
|
||||
Tabela~\ref{tab:unity-vulkan-init} przedstawia jednorazowe operacje inicjalizacyjne. \texttt{vkCreateDevice} (162,35 ms) tworzy logiczne
|
||||
urządzenie Vulkan -- jest to najdroższa pojedyncza operacja, obejmująca negocjację możliwości GPU, alokację struktur wewnętrznych sterownika i
|
||||
@ -288,7 +279,6 @@ obejmuje alokację pamięci dla buforów, konfigurację formatów i synchronizac
|
||||
Utworzenie 341 obiektów fence (łącznie 135,60 ms) wskazuje na przygotowanie puli ogrodzeń do wielokrotnego użytku w cyklu renderowania. Unity stosuje
|
||||
strategię pre-alokacji zamiast tworzenia ogrodzeń na żądanie, co jest praktyką zalecaną w dokumentacji Vulkan.
|
||||
|
||||
\subsubsection{Analiza wywołań systemowych (OS Runtime)}
|
||||
|
||||
Oprócz wywołań Vulkan API, Nsight Systems przechwytuje również wywołania funkcji systemowych, umożliwiając analizę zachowania aplikacji na poziomie
|
||||
systemu operacyjnego. Zarejestrowano \textbf{29\,383 wywołania} 65 różnych funkcji systemowych.
|
||||
@ -311,7 +301,6 @@ systemu operacyjnego. Zarejestrowano \textbf{29\,383 wywołania} 65 różnych fu
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Mechanizm futex -- szybka synchronizacja w przestrzeni użytkownika}
|
||||
|
||||
Funkcja \texttt{futex} (ang. \textit{Fast Userspace muTEX}) pochłonęła \textbf{95,9\% czasu} wywołań systemowych. Futex jest mechanizmem
|
||||
synchronizacji wątków w jądrze Linux, zaprojektowanym dla maksymalnej wydajności w scenariuszach bez rywalizacji (ang. \textit{uncontended case}).
|
||||
@ -332,7 +321,6 @@ architekturę wielowątkową z oddzielnymi wątkami dla: głównej pętli gry, r
|
||||
(wątek od razu uzyskuje blokadę lub jest natychmiast budzony), ale niektóre wywołania skutkują długim oczekiwaniem. Maksymalny czas 11,05 sekundy
|
||||
odpowiada najprawdopodobniej wątkowi oczekującemu na zakończenie długotrwałej operacji inicjalizacyjnej.
|
||||
|
||||
\paragraph{Zmienne warunkowe POSIX}
|
||||
|
||||
Funkcje \texttt{pthread\_cond\_timedwait} (2,7\%, 85 wywołań) i \texttt{pthread\_cond\_wait} (0,6\%, 26 wywołań) implementują zmienne warunkowe POSIX,
|
||||
używane do bardziej złożonych scenariuszy synchronizacji niż proste muteksy.
|
||||
@ -364,7 +352,6 @@ robocze systemu zadań, sugeruje to pulę kilkudziesięciu wątków aktywnie ucz
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Operacje wejścia/wyjścia}
|
||||
|
||||
Tabela~\ref{tab:unity-osrt-io} przedstawia statystyki operacji I/O. Funkcja \texttt{poll} (349 wywołań, 314,33 ms) służy do multipleksowanego
|
||||
oczekiwania na zdarzenia z wielu deskryptorów plików -- w kontekście gry prawdopodobnie dotyczy komunikacji z systemem okienkowym (X11/Wayland)
|
||||
@ -377,11 +364,9 @@ gry (tekstur, modeli, shaderów) z dysku. Średni czas 1,07 $\mu$s potwierdza ef
|
||||
używane do komunikacji ze sterownikiem GPU poprzez \\
|
||||
interfejs DRM/KMS (Direct Rendering Manager / Kernel Mode Setting).
|
||||
|
||||
\subsubsection{Interpretacja wyników i wnioski}
|
||||
|
||||
Przeprowadzona analiza pozwala na sformułowanie następujących wniosków dotyczących wydajności i architektury silnika Unity:
|
||||
|
||||
\paragraph{Charakterystyka ograniczenia wydajności}
|
||||
|
||||
Dominacja \texttt{vkWaitForFences} \\ (95,2\% czasu Vulkan) i \texttt{futex} (95,9\% czasu systemowego)
|
||||
jednoznacznie wskazuje na scenariusz
|
||||
@ -392,7 +377,6 @@ W scenariuszu CPU-bound obserwowalibyśmy niższy udział funkcji synchronizacyj
|
||||
funkcji przygotowujących polecenia \\
|
||||
(\texttt{vkBeginCommandBuffer}, \texttt{vkCmdBindPipeline} itp.), co wskazywałoby na wąskie gardło po stronie procesora.
|
||||
|
||||
\paragraph{Efektywność potoku renderowania}
|
||||
|
||||
Stosunek liczby wywołań \texttt{vkQueueSubmit} (27\,112) do \texttt{vkQueuePresentKHR} (13\,556) wynoszący 2:1 wskazuje na dwuetapowy potok
|
||||
renderowania dla każdej klatki. Może to odpowiadać architekturze z oddzielnymi przebiegami dla sceny 3D i interfejsu użytkownika, lub użyciu techniki
|
||||
@ -402,7 +386,6 @@ Niska liczba wywołań \texttt{vkCmdBindPipeline} (27\,027, ~2 na klatkę)
|
||||
sugeruje \\ efektywne grupowanie obiektów renderowanych tym samym shaderem,
|
||||
minimalizujące kosztowne zmiany stanu GPU.
|
||||
|
||||
\paragraph{Stabilność czasów klatek}
|
||||
|
||||
Pomimo wysokiego współczynnika zmienności (153\%) wynikającego z wartości ekstremalnych podczas
|
||||
inicjalizacji, właściwa stabilność renderowania jest
|
||||
@ -419,7 +402,6 @@ działania synchronizacji pionowej (V-Sync), która sztucznie \\
|
||||
wyrównuje czasy klatek poprzez oczekiwanie na sygnał odświeżania monitora. \\ Bez V-Sync
|
||||
zmienność czasów klatek mogłaby być wyższa.
|
||||
|
||||
\paragraph{Architektura wielowątkowa}
|
||||
|
||||
Analiza wywołań systemowych potwierdza intensywne wykorzystanie wielowątkowości:
|
||||
\begin{itemize}
|
||||
@ -449,7 +431,6 @@ Każda faza była uruchamiana z flagą \texttt{--start-time=N}, która przesuwa
|
||||
spawnu przeciwników \\ (w \texttt{STGEnemySpawner}) do odpowiedniej sekundy. \\ Grę skompilowano w konfiguracji DebugGame, która zachowuje symbole
|
||||
debugowania przy częściowych optymalizacjach.
|
||||
|
||||
\subsubsection{Metodologia profilowania fazowego}
|
||||
|
||||
Ze względu na bardzo dużą ilość danych generowanych przez Unreal Engine podczas śledzenia wywołań Vulkan API (około 13 milionów zdarzeń
|
||||
na 30 sekund rozgrywki, w porównaniu z 0,5 miliona dla Unity), 90-sekundową rozgrywkę podzielono na \textbf{trzy fazy po 30 sekund każda}:
|
||||
@ -471,7 +452,6 @@ Profilowanie przeprowadzono z wykorzystaniem tych samych metryk co dla Unity:
|
||||
\item \textbf{Metryk sprzętowych GPU} (\texttt{--gpu-metrics-devices=0}) -- próbkowanie \\ liczników wydajności GPU
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Metryki wykorzystania GPU}
|
||||
|
||||
NVIDIA Nsight Systems zbiera metryki sprzętowe GPU poprzez bezpośredni dostęp do liczników
|
||||
wydajności zintegrowanych w karcie graficznej.
|
||||
@ -496,7 +476,6 @@ SM Issue [\%] & 13,94 & 0 & 99 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{GPU Active -- ogólna aktywność karty graficznej}
|
||||
|
||||
Metryka \texttt{GPU Active} określa procentowy udział czasu, w którym karta graficzna wykonuje jakąkolwiek pracę obliczeniową.
|
||||
Średnia wartość \textbf{90,98\%} dla faz 1--2 (aktywna rozgrywka) oznacza, że GPU był niemal w pełni wykorzystany podczas właściwej rozgrywki.
|
||||
@ -529,7 +508,6 @@ fazowego profilowania. \\
|
||||
Wyraźny spadek w fazie
|
||||
3 odzwierciedla zakończenie aktywnej rozgrywki i przejście do ekranu zwycięstwa.
|
||||
|
||||
\paragraph{GR Active -- aktywność silnika graficznego}
|
||||
|
||||
Metryka \texttt{GR Active} (Graphics Active) mierzy wykorzystanie silnika graficznego (ang. \textit{graphics engine}) karty NVIDIA, odpowiedzialnego
|
||||
za wykonywanie potoków renderowania (vertex, tessellation, geometry, fragment shaders). Średnia wartość \textbf{85,59\%} dla aktywnej rozgrywki
|
||||
@ -538,7 +516,6 @@ stanowi 94\% wartości \texttt{GPU Active} (90,98\%), co oznacza, że praca graf
|
||||
Różnica około 5 punktów procentowych między \texttt{GPU Active} a \texttt{GR Active} odpowiada pracy wykonanej przez jednostki compute i operacje
|
||||
kopiowania pamięci, w tym asynchroniczny transfer danych przez Async Copy Engine (aktywny w 24--25\% czasu w fazach 1--2).
|
||||
|
||||
\paragraph{SMs Active i Sync Compute -- wykorzystanie multiprocesorów strumieniowych}
|
||||
|
||||
\texttt{SMs Active} (Streaming Multiprocessors Active) na poziomie \textbf{42,88\%} wskazuje, że średnio mniej niż połowa dostępnych multiprocesorów
|
||||
strumieniowych jest aktywna jednocześnie. Karta NVIDIA RTX 3090 posiada 82 jednostki SM, więc średnio około 35 z nich wykonywało pracę w danym momencie.
|
||||
@ -562,7 +539,6 @@ PCIe TX Throughput & 1,39 & 17,0 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Przepustowość pamięci VRAM}
|
||||
|
||||
Tabela~\ref{tab:unreal-memory-metrics} przedstawia metryki przepustowości pamięci. Średnie wykorzystanie przepustowości odczytu
|
||||
DRAM (\textbf{10,30\%}) i zapisu (\textbf{10,10\%}) jest umiarkowane, wskazując że pamięć nie stanowi głównego wąskiego gardła.
|
||||
@ -587,7 +563,6 @@ Unallocated Warps in Active SMs & 20,73 & 90,0 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Analiza wątków shaderów (warps)}
|
||||
|
||||
Tabela~\ref{tab:unreal-warps} przedstawia rozkład typów aktywnych wątków shader
|
||||
(warps -- grupy 32 wątków CUDA wykonywanych synchronicznie).
|
||||
@ -623,7 +598,6 @@ Częstotliwości zegara (tabela~\ref{tab:unreal-gpu-clocks}) pokazują, że GPU
|
||||
(96\% maksymalnej 1\,965 MHz), co wskazuje na niskie obciążenie termiczne pozwalające na utrzymanie wysokich częstotliwości boost bez throttlingu.
|
||||
Minimalne wartości odpowiadają krótkim momentom niższego obciążenia podczas przejść między klatkami.
|
||||
|
||||
\subsubsection{Analiza wywołań Vulkan API w trzech fazach}
|
||||
|
||||
Dzięki zastosowaniu profilowania fazowego uzyskano \textbf{kompletne dane} śledzenia Vulkan API z całego 90-sekundowego przebiegu gry Unreal Engine.
|
||||
Dane podzielone na trzy fazy (0--30s, 30--60s, 60--90s) umożliwiają szczegółową analizę ewolucji wykorzystania GPU w czasie rozgrywki.
|
||||
@ -648,7 +622,6 @@ vkCmdBindPipeline & 2\,236\,013 & 2\,528\,014 & 1\,007\,615 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Dynamika wydajności między fazami}
|
||||
|
||||
Tabela~\ref{tab:unreal-vulkan-phases} ujawnia znaczącą dynamikę wydajności między fazami.
|
||||
Fazy 1 i 2 (aktywna rozgrywka) osiągają wysoką wydajność
|
||||
@ -695,7 +668,6 @@ wskazuje na konsystentną architekturę potoku renderowania niezależną od obci
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Kompilacja potoków -- ciągły proces}
|
||||
|
||||
W przeciwieństwie do Unity, gdzie dominującą funkcją był \texttt{vkWaitForFences},
|
||||
w Unreal Engine \textbf{57--72\% czasu} Vulkan API
|
||||
@ -732,7 +704,6 @@ Nsight Systems tworzy nową sesję dla każdej fazy.
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Synchronizacja -- minimalne oczekiwanie na GPU}
|
||||
|
||||
W ostrzym kontraście z Unity (gdzie \texttt{vkWaitForFences} stanowił 95,2\% czasu), w Unreal Engine funkcja ta pochłonęła zaledwie
|
||||
\textbf{0,5\% czasu} ze średnim czasem oczekiwania 3,63 $\mu$s. Tak niski czas oczekiwania wskazuje na:
|
||||
@ -765,7 +736,6 @@ wieloma przebiegami (deferred rendering, post-processing, UI).
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Bufory poleceń -- intensywna zmiana stanów}
|
||||
|
||||
Liczba wywołań \\ \texttt{vkCmdBindPipeline} (\textbf{5\,771\,642}
|
||||
łącznie we wszystkich fazach) jest \\ ponad \textbf{213 razy większa} niż w
|
||||
@ -779,7 +749,6 @@ Unity (27\,027), \\ co odpowiada około 218 zmianom potoku na klatkę. Tak wysok
|
||||
Funkcja \texttt{vkCmdPipelineBarrier2KHR} (4\,090\,071 wywołań) synchronizuje dostęp do zasobów w obrębie GPU -- wysoka liczba wywołań wskazuje
|
||||
na staranną kontrolę zależności między operacjami, typową dla nowoczesnych technik renderowania wykorzystujących wiele render targets.
|
||||
|
||||
\paragraph{Ray tracing -- przygotowanie struktur akceleracji}
|
||||
|
||||
Interesującą obserwacją jest obecność wywołań związanych z ray tracingiem we wszystkich fazach:
|
||||
\begin{itemize}
|
||||
@ -792,7 +761,6 @@ Pomimo że testowana gra nie wykorzystuje widocznych efektów ray tracingu, Unre
|
||||
(Bounding Volume Hierarchy), prawdopodobnie do potencjalnego użycia w globalnym oświetleniu lub śledzeniu promieni. Nierówna liczba utworzeń
|
||||
i zniszczeń sugeruje akumulację struktur w pamięci GPU podczas rozgrywki.
|
||||
|
||||
\subsubsection{Analiza wywołań systemowych Unreal Engine}
|
||||
|
||||
Podobnie jak dla Unity, Nsight Systems przechwycił wywołania funkcji systemowych we wszystkich trzech fazach, umożliwiając analizę zachowania
|
||||
wielowątkowego Unreal Engine. Łącznie zarejestrowano ponad \textbf{9 milionów wywołań} funkcji synchronizacji.
|
||||
@ -816,7 +784,6 @@ wielowątkowego Unreal Engine. Łącznie zarejestrowano ponad \textbf{9 milionó
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{pthread\_cond\_wait -- architektura TaskGraph}
|
||||
|
||||
Funkcja \texttt{pthread\_cond\_wait} \\ pochłonęła \textbf{64,6\% czasu} przy
|
||||
\textbf{3\,095\,188 wywołaniach} we wszystkich trzech fazach.
|
||||
@ -856,7 +823,6 @@ Tabela~\ref{tab:unreal-osrt-phases} pokazuje konsystencję wzorców wywołań mi
|
||||
fazie 3 (zawierającej ekran zwycięstwa). Szczególnie interesująca jest wysoka liczba wywołań \texttt{backtrace} (ponad 5,5 miliona łącznie),
|
||||
co sugeruje intensywne wykorzystanie mechanizmów debugowania lub profilowania wbudowanych w Unreal Engine nawet w konfiguracji DebugGame.
|
||||
|
||||
\paragraph{synchronizacja z limitem czasowym pthread\_cond\_timedwait}
|
||||
(19,2\%, 163\,783 \\ wywołań) różni się od
|
||||
\texttt{pthread\_cond\_wait} możliwością określenia maksymalnego czasu
|
||||
oczekiwania. Użycie tej funkcji wskazuje na mechanizmy:
|
||||
@ -870,7 +836,6 @@ oczekiwania. Użycie tej funkcji wskazuje na mechanizmy:
|
||||
gdzie wątki oczekują na gotowość kolejnej klatki z timeout'em
|
||||
\\ zapobiegającym nieskończonemu oczekiwaniu w przypadku błędu.
|
||||
|
||||
\paragraph{usleep -- precyzyjne opóźnienia}
|
||||
|
||||
Funkcja \texttt{usleep} (4,7\%, 26\,062 wywołań, średnio 7,79 ms) wprowadza precyzyjne opóźnienia czasowe. Średni czas 7,79 ms jest zbliżony do
|
||||
czasu klatki przy ~128 FPS, co może sugerować mechanizm regulacji tempa renderowania lub oszczędzanie energii poprzez redukcję spin-waitingu.
|
||||
@ -893,7 +858,6 @@ Liczba próbek GPU (10 kHz) & -- & 1\,050\,555 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\paragraph{Porównanie modeli synchronizacji}
|
||||
|
||||
Tabela~\ref{tab:sync-comparison} ujawnia fundamentalną różnicę architektoniczną między silnikami:
|
||||
|
||||
@ -914,11 +878,9 @@ Różnica ta ma implikacje praktyczne:
|
||||
\item \textbf{Debugowanie}: Model Unity jest łatwiejszy do analizy ze względu na prostszą strukturę
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Charakterystyka architektury Unreal Engine na podstawie profilowania}
|
||||
|
||||
Zebrane dane z trzech faz profilowania pozwalają na charakterystykę architektonicznych aspektów silnika Unreal Engine:
|
||||
|
||||
\paragraph{Model wielowątkowości}
|
||||
|
||||
Unreal Engine 5 stosuje zaawansowaną architekturę wielowątkową złożoną z:
|
||||
\begin{itemize}
|
||||
@ -933,7 +895,6 @@ komunikację między tymi wątkami.
|
||||
\\ Wysokie wykorzystanie
|
||||
GPU (90,98\% w fazach aktywnej rozgrywki) przy jednoczesnej intensywnej synchronizacji CPU sugeruje efektywne wykorzystanie zasobów obu procesorów.
|
||||
|
||||
\paragraph{Profil obciążenia GPU}
|
||||
|
||||
Na podstawie zebranych metryk można \\ scharakteryzować profil obciążenia GPU:
|
||||
\begin{itemize}
|
||||
@ -944,7 +905,6 @@ Na podstawie zebranych metryk można \\ scharakteryzować profil obciążenia GP
|
||||
\item \textbf{Async Copy Engine}: Aktywny w 24--25\% czasu, wskazując na efektywne wykorzystanie asynchronicznych transferów
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Stabilność między fazami}
|
||||
|
||||
Porównanie faz 1 i 2 (tabela~\ref{tab:unreal-gpu-phases}) pokazuje niezwykłą stabilność metryk GPU:
|
||||
\begin{itemize}
|
||||
@ -956,7 +916,6 @@ Porównanie faz 1 i 2 (tabela~\ref{tab:unreal-gpu-phases}) pokazuje niezwykłą
|
||||
Ta konsystencja potwierdza poprawność metodologii fazowego profilowania i sugeruje deterministyczne zachowanie silnika renderującego niezależnie od
|
||||
poziomu trudności gry.
|
||||
|
||||
\paragraph{Podsumowanie architektury Unreal Engine}
|
||||
|
||||
Dzięki profilowaniu fazowemu uzyskano kompletne dane śledzenia Vulkan API i metryk GPU dla całej 90-sekundowej rozgrywki.
|
||||
Zebrane dane (ponad 32 miliony zdarzeń Vulkan API, ponad milion próbek GPU i ponad 9 milionów wywołań systemowych) dostarczają
|
||||
@ -965,7 +924,6 @@ kompleksowego wglądu w charakterystykę wydajnościową silnika, umożliwiając
|
||||
\subsection{Analiza porównawcza}
|
||||
\label{subsec:analiza-porownawcza}
|
||||
|
||||
\subsubsection{Porównanie czasu klatki}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
@ -993,7 +951,6 @@ Ten wynik sugeruje, że przy wysokim obciążeniu sceny (maksymalna liczba przec
|
||||
oba silniki osiągają porównywalną wydajność, natomiast Unreal Engine jest w stanie wykorzystać
|
||||
zapas mocy obliczeniowej GPU przy mniejszym obciążeniu.
|
||||
|
||||
\subsubsection{Porównanie wykorzystania GPU}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
@ -1014,12 +971,10 @@ vkCmdBindPipeline / klatkę & 2 & 218 \\
|
||||
|
||||
Analiza wywołań Vulkan API ujawnia fundamentalnie różne profile obciążenia (tabela~\ref{tab:gpu-comparison}):
|
||||
|
||||
\paragraph{Unity -- scenariusz GPU-bound}
|
||||
Dominacja \texttt{vkWaitForFences} (95,2\% czasu) \\ wskazuje, że CPU efektywnie przygotowuje pracę i oczekuje na GPU.
|
||||
Jest to pożądany wzorzec w aplikacjach graficznych, gdzie GPU wykonuje większość obliczeń. \\ Niski stosunek
|
||||
\texttt{vkQueueSubmit}/klatkę (2:1) świadczy o prostym, dwuetapowym potoku renderowania.
|
||||
|
||||
\paragraph{Unreal Engine -- kompilacja potoków jako wąskie gardło}
|
||||
W Unreal Engine dominującymi operacjami były \texttt{vkCreateComputePipelines} \\ oraz \texttt{vkCreateGraphicsPipelines},
|
||||
pochłaniające łącznie 57--72\% czasu Vulkan. Silnik tworzy około \textbf{1000 potoków w każdej 30-sekundowej fazie}
|
||||
(vs 3 potoki w całym teście Unity), co wskazuje na strategię dynamicznej kompilacji shaderów.
|
||||
@ -1027,7 +982,6 @@ pochłaniające łącznie 57--72\% czasu Vulkan. Silnik tworzy około \textbf{10
|
||||
Wysoki stosunek \texttt{vkCmdBindPipeline}/klatkę (218:1 vs 2:1) odzwierciedla złożony system materiałów Unreal
|
||||
z wieloma wariantami shaderów, co wprowadza znaczący narzut zmian stanu GPU.
|
||||
|
||||
\subsubsection{Porównanie architektury wielowątkowej}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
|
||||
@ -3,9 +3,7 @@
|
||||
|
||||
\subsection{Analiza możliwości renderingu}
|
||||
|
||||
\subsubsection{Wsparcie dla różnych technik renderingu}
|
||||
|
||||
\paragraph{Unity}
|
||||
Unity oferuje dwa główne pipeline'y renderowania: Built-in Render Pipeline (legacy), Universal Render Pipeline (URP) oraz High Definition Render Pipeline (HDRP). URP jest zoptymalizowany pod kątem wydajności i~kompatybilności między platformami, podczas gdy HDRP koncentruje się na~wysokiej jakości grafiki dla~platform o~dużej mocy obliczeniowej~\cite{gregory2018game}.
|
||||
|
||||
\begin{itemize}
|
||||
@ -14,7 +12,6 @@ Unity oferuje dwa główne pipeline'y renderowania: Built-in Render Pipeline (le
|
||||
\item \textbf{Ray tracing} -- wsparcie w~HDRP dla~kart graficznych NVIDIA RTX~\cite{parker2010optix}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
Unreal Engine wykorzystuje zaawansowany deferred rendering pipeline z~obsługą ray tracingu w~czasie rzeczywistym~\cite{unreal_docs}.
|
||||
|
||||
\begin{itemize}
|
||||
@ -24,9 +21,7 @@ Unreal Engine wykorzystuje zaawansowany deferred rendering pipeline z~obsługą
|
||||
\item \textbf{Nanite} -- zwirtualizowana geometria pozwalająca na~renderowanie miliardów poligonów
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Systemy materiałów i shaderów}
|
||||
|
||||
\paragraph{Unity}
|
||||
Unity oferuje Shader Graph -- wizualny edytor do~tworzenia shaderów \\ bez~pisania kodu. Dodatkowo wspiera shadery pisane w~HLSL oraz~Cg~\cite{farina2013shader}.
|
||||
|
||||
\begin{itemize}
|
||||
@ -35,7 +30,6 @@ Unity oferuje Shader Graph -- wizualny edytor do~tworzenia shaderów \\ bez~pisa
|
||||
\item \textbf{Shader variants} -- system wariantów dla~optymalizacji
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia materiałów~\cite{unreal_docs}.
|
||||
|
||||
\begin{itemize}
|
||||
@ -44,9 +38,7 @@ Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia mat
|
||||
\item \textbf{Custom HLSL} -- integracja własnego kodu HLSL~\cite{farina2013shader}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Systemy oświetlenia}
|
||||
|
||||
\paragraph{Unity}
|
||||
\begin{itemize}
|
||||
\item \textbf{Real-time lighting} -- dynamiczne oświetlenie w~czasie rzeczywistym
|
||||
\item \textbf{Baked lighting} -- przedkalkulowane mapy oświetlenia (lightmaps)
|
||||
@ -54,7 +46,6 @@ Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia mat
|
||||
\item \textbf{Global Illumination} -- Progressive Lightmapper dla~światła odbitego~\cite{gregory2018game}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
\begin{itemize}
|
||||
\item \textbf{Lumen} -- dynamiczne global illumination w~czasie rzeczywistym
|
||||
\item \textbf{Lightmass} -- high-quality baked lighting~\cite{gregory2018game}
|
||||
@ -64,9 +55,7 @@ Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia mat
|
||||
|
||||
\subsection{Systemy fizyki i symulacji}
|
||||
|
||||
\subsubsection{Rigid body physics}
|
||||
|
||||
\paragraph{Unity}
|
||||
Unity wykorzystuje NVIDIA PhysX jako~silnik fizyki~\cite{nvidia_physx}.
|
||||
|
||||
\begin{itemize}
|
||||
@ -76,7 +65,6 @@ Unity wykorzystuje NVIDIA PhysX jako~silnik fizyki~\cite{nvidia_physx}.
|
||||
\item \textbf{Wydajność} -- efektywne dla~setek obiektów fizycznych~\cite{messaoudi2017performance}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
Unreal przeszedł z~PhysX \\ na~Chaos Physics --
|
||||
własny silnik fizyki~\cite{unreal_docs}.
|
||||
|
||||
@ -87,15 +75,12 @@ własny silnik fizyki~\cite{unreal_docs}.
|
||||
\item \textbf{Vehicles} -- zaawansowany system pojazdów~\cite{gregory2018game}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Systemy cząstek}
|
||||
|
||||
\paragraph{Unity}
|
||||
\begin{itemize}
|
||||
\item \textbf{Shuriken Particle System} -- klasyczny system cząstek
|
||||
\item \textbf{Visual Effect Graph} -- system cząstek GPU-based dla~milionów cząstek
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
\begin{itemize}
|
||||
\item \textbf{Cascade} -- legacy system cząstek
|
||||
\item \textbf{Niagara} -- zaawansowany, skalowalny system efektów wizualnych
|
||||
@ -103,23 +88,19 @@ własny silnik fizyki~\cite{unreal_docs}.
|
||||
|
||||
\subsection{Systemy audio}
|
||||
|
||||
\subsubsection{Wsparcie formatów audio}
|
||||
|
||||
\paragraph{Unity}
|
||||
\begin{itemize}
|
||||
\item Obsługiwane formaty: WAV, MP3, OGG, AIFF
|
||||
\item Kompresja: Vorbis, MP3, ADPCM
|
||||
\item Audio middleware: integracja z~Wwise, FMOD~\cite{firat2022sound}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
\begin{itemize}
|
||||
\item Obsługiwane formaty: WAV, OGG, FLAC
|
||||
\item Natywna integracja z~MetaSounds
|
||||
\item Wsparcie dla~Wwise, FMOD~\cite{firat2022sound}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Przestrzenny dźwięk 3D}
|
||||
|
||||
Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsługą~\cite{firat2022sound}:
|
||||
\begin{itemize}
|
||||
@ -131,9 +112,7 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
|
||||
\subsection{Narzędzia deweloperskie}
|
||||
|
||||
\subsubsection{Edytory wizualne}
|
||||
|
||||
\paragraph{Unity Editor}
|
||||
\begin{itemize}
|
||||
\item \textbf{Scene View} -- intuicyjny edytor sceny 2D/3D
|
||||
\item \textbf{Inspector} -- edycja właściwości komponentów
|
||||
@ -141,7 +120,6 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
\item \textbf{UI Builder} -- wizualny edytor interfejsów użytkownika
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Editor}
|
||||
\begin{itemize}
|
||||
\item \textbf{Viewport} -- zaawansowany edytor poziomów
|
||||
\item \textbf{Details Panel} -- szczegółowa konfiguracja aktorów
|
||||
@ -149,9 +127,7 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
\item \textbf{UMG Designer} -- projektowanie UI
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Systemy debugowania}
|
||||
|
||||
\paragraph{Unity}
|
||||
\begin{itemize}
|
||||
\item Unity Profiler -- analiza wydajności CPU, GPU, pamięci
|
||||
\item Console -- logi i~błędy w~czasie rzeczywistym
|
||||
@ -159,7 +135,6 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
\item Memory Profiler -- szczegółowa analiza alokacji pamięci
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
\begin{itemize}
|
||||
\item Unreal Insights -- kompleksowe narzędzie profilowania
|
||||
\item Visual Logger -- wizualizacja logów w~kontekście gry
|
||||
@ -169,7 +144,6 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
|
||||
\subsection{Wsparcie dla platform docelowych}
|
||||
|
||||
\subsubsection{Platformy desktop}
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@ -188,7 +162,6 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Platformy mobilne}
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@ -207,11 +180,9 @@ Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsług
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Konsole}
|
||||
|
||||
Oba silniki oferują wsparcie dla~głównych konsol (PlayStation 5, Xbox Series X/S, Nintendo Switch), jednak~wymagają specjalnych licencji deweloperskich.
|
||||
|
||||
\subsubsection{Platformy VR/AR}
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@ -236,9 +207,7 @@ Oba silniki oferują wsparcie dla~głównych konsol (PlayStation 5, Xbox Series
|
||||
|
||||
\subsection{Ekosystem i rozszerzalność}
|
||||
|
||||
\subsubsection{Asset Store / Marketplace}
|
||||
|
||||
\paragraph{Unity Asset Store}
|
||||
\begin{itemize}
|
||||
\item Ponad 100\,000 zasobów dostępnych
|
||||
\item Modele 3D, tekstury, skrypty, narzędzia, kompletne projekty
|
||||
@ -246,7 +215,6 @@ Oba silniki oferują wsparcie dla~głównych konsol (PlayStation 5, Xbox Series
|
||||
\item System ocen i~recenzji
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Marketplace}
|
||||
\begin{itemize}
|
||||
\item Dziesiątki tysięcy zasobów wysokiej jakości
|
||||
\item Miesięczne darmowe zasoby dla~subskrybentów
|
||||
@ -254,7 +222,6 @@ Oba silniki oferują wsparcie dla~głównych konsol (PlayStation 5, Xbox Series
|
||||
\item Często wyższa jakość, ale~mniejszy wybór niż~Unity
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Wsparcie społeczności}
|
||||
|
||||
Wielkość i~aktywność społeczności deweloperskiej jest istotnym czynnikiem wyboru silnika gier~\cite{christopoulou2017overview}. W~celu obiektywnej oceny wykorzystano dane z~publicznych platform:
|
||||
|
||||
@ -279,16 +246,13 @@ Wielkość i~aktywność społeczności deweloperskiej jest istotnym czynnikiem
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Dokumentacja i materiały edukacyjne}
|
||||
|
||||
\paragraph{Unity}
|
||||
\begin{itemize}
|
||||
\item \textbf{Dokumentacja oficjalna} -- ponad 5000 stron dokumentacji API
|
||||
\item \textbf{Unity Learn} -- ponad 750 darmowych kursów i~tutoriali~\cite{christopoulou2017overview}
|
||||
\item \textbf{Certyfikacje} -- 4 poziomy certyfikacji \\ (User, Associate, Professional, Expert)~\cite{barczak2019comparative}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal Engine}
|
||||
\begin{itemize}
|
||||
\item \textbf{Dokumentacja oficjalna} -- obszerna dokumentacja z~ponad 3000 stron
|
||||
\item \textbf{Unreal Online Learning} -- ponad 200 darmowych kursów wideo~\cite{christopoulou2017overview}
|
||||
|
||||
@ -3,7 +3,6 @@
|
||||
|
||||
\subsection{Synteza wyników badań}
|
||||
|
||||
\subsubsection{Zestawienie wyników testów wydajności}
|
||||
|
||||
Na~podstawie przeprowadzonych testów wydajności (rozdział~\ref{sec:testy-wydajnosci}) można stwierdzić, że~oba silniki wykazują odmienne charakterystyki wydajnościowe w~zależności od~scenariusza testowego.
|
||||
|
||||
@ -30,13 +29,11 @@ Na~podstawie przeprowadzonych testów wydajności (rozdział~\ref{sec:testy-wyda
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Zestawienie analizy funkcjonalności}
|
||||
|
||||
Analiza możliwości (rozdział~6) wykazała, że~oba silniki oferują bogate zestawy funkcjonalności, jednak~skierowane do~nieco odmiennych grup docelowych.
|
||||
|
||||
\subsection{Analiza wielokryterialna}
|
||||
|
||||
\subsubsection{Macierz porównawcza}
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@ -71,7 +68,6 @@ Analiza możliwości (rozdział~6) wykazała, że~oba silniki oferują bogate ze
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Analiza wag kryteriów}
|
||||
|
||||
Znaczenie poszczególnych kryteriów różni się w~zależności od~typu projektu:
|
||||
|
||||
@ -84,11 +80,8 @@ Znaczenie poszczególnych kryteriów różni się w~zależności od~typu projekt
|
||||
|
||||
\subsection{Przypadki użycia}
|
||||
|
||||
\subsubsection{Gry indie}
|
||||
|
||||
\paragraph{Rekomendacja}: Unity
|
||||
|
||||
\paragraph{Uzasadnienie}:
|
||||
\begin{itemize}
|
||||
\item Niższy próg wejścia dla~początkujących deweloperów
|
||||
\item Bogaty Asset Store z~dostępnymi cenowo zasobami
|
||||
@ -97,14 +90,10 @@ Znaczenie poszczególnych kryteriów różni się w~zależności od~typu projekt
|
||||
\item Mniejsze wymagania sprzętowe dla~deweloperów
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Wyjątki}:
|
||||
Jeśli gra wymaga grafiki najwyższej jakości (photorealistic), rozważ Unreal Engine.
|
||||
|
||||
\subsubsection{Gry mobilne}
|
||||
|
||||
\paragraph{Rekomendacja}: Unity
|
||||
|
||||
\paragraph{Uzasadnienie}:
|
||||
\begin{itemize}
|
||||
\item Lepsza optymalizacja pod~platformy mobilne
|
||||
\item Mniejsze rozmiary buildu
|
||||
@ -113,14 +102,10 @@ Jeśli gra wymaga grafiki najwyższej jakości (photorealistic), rozważ Unreal
|
||||
\item Większość gier mobilnych używa Unity (udowodniona skuteczność)
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Statystyki}:
|
||||
Według danych z~2023 roku, około 70\% gier mobilnych na~iOS i~Android zostało stworzonych w~Unity~\cite{statista_unity_market, unity_gaming_report}.
|
||||
|
||||
\subsubsection{Gry AAA}
|
||||
|
||||
\paragraph{Rekomendacja}: Unreal Engine
|
||||
|
||||
\paragraph{Uzasadnienie}:
|
||||
\begin{itemize}
|
||||
\item Wyższa jakość grafiki out-of-the-box
|
||||
\item Nanite -- rendering miliardów poligonów
|
||||
@ -129,21 +114,16 @@ Według danych z~2023 roku, około 70\% gier mobilnych na~iOS i~Android zostało
|
||||
\item Sprawdzone w~produkcjach AAA (Fortnite, Gears of~War)
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Przykłady}:
|
||||
Unreal Engine wykorzystywano w~produkcjach takich jak: Final Fantasy VII Remake, Jedi: Fallen Order, Borderlands 3.
|
||||
|
||||
\subsubsection{Gry VR/AR}
|
||||
|
||||
\paragraph{Rekomendacja}: Zależnie od~wymagań
|
||||
|
||||
\paragraph{Unity dla}:
|
||||
\begin{itemize}
|
||||
\item Aplikacje edukacyjne VR/AR
|
||||
\item Mobilny AR (ARCore, ARKit)
|
||||
\item Projekty wymagające szybkiego rozwoju
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Unreal dla}:
|
||||
\begin{itemize}
|
||||
\item High-end VR experiences
|
||||
\item Architekturalna wizualizacja VR
|
||||
@ -154,7 +134,6 @@ Unreal Engine wykorzystywano w~produkcjach takich jak: Final Fantasy VII Remake,
|
||||
|
||||
Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy badawcze:
|
||||
|
||||
\subsubsection{Hipoteza 1: Wydajność renderowania 3D}
|
||||
|
||||
\textbf{Hipoteza}: Unreal Engine oferuje lepszą wydajność renderowania złożonych scen 3D niż~Unity.
|
||||
|
||||
@ -162,7 +141,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
|
||||
\textbf{Uzasadnienie}: Na~podstawie testów wydajności (Tabela~\ref{tab:results-high}) zaobserwowano, że...
|
||||
|
||||
\subsubsection{Hipoteza 2: Łatwość nauki}
|
||||
|
||||
\textbf{Hipoteza}: Unity charakteryzuje się niższym progiem wejścia dla~początkujących deweloperów niż~Unreal Engine.
|
||||
|
||||
@ -176,7 +154,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item Prostszy interfejs edytora
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Hipoteza 3: Wsparcie mobilne}
|
||||
|
||||
\textbf{Hipoteza}: Unity oferuje lepsze wsparcie i~optymalizację dla~platform mobilnych niż~Unreal Engine.
|
||||
|
||||
@ -190,7 +167,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item Dominacja na~rynku gier mobilnych (70\% udziału)
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Hipoteza 4: Jakość grafiki}
|
||||
|
||||
\textbf{Hipoteza}: Unreal Engine umożliwia osiągnięcie wyższej jakości grafiki niż~Unity przy~porównywalnym nakładzie pracy.
|
||||
|
||||
@ -206,7 +182,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
|
||||
\subsection{Ograniczenia badań}
|
||||
|
||||
\subsubsection{Ograniczenia metodologiczne}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Ograniczona liczba scenariuszy testowych} -- skupiono się na~grze typu bullet-hell, co~nie~pokrywa wszystkich możliwych zastosowań silników
|
||||
@ -214,7 +189,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item \textbf{Mała próba wywiadów} -- 8~respondentów może nie~reprezentować całej społeczności deweloperów
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Ograniczenia techniczne}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Wersje silników} -- wyniki dotyczą konkretnych wersji Unity i~Unreal; nowsze wersje mogą mieć odmienną wydajność
|
||||
@ -222,7 +196,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item \textbf{Profilowanie} -- NVIDIA Nsight może wprowadzać własny narzut wydajnościowy
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Ograniczenia czasowe}
|
||||
|
||||
\begin{itemize}
|
||||
\item Silniki gier rozwijają się dynamicznie -- wyniki mogą dezaktualizować się w~ciągu roku
|
||||
@ -231,7 +204,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
|
||||
\subsection{Implikacje praktyczne}
|
||||
|
||||
\subsubsection{Dla deweloperów indywidualnych}
|
||||
|
||||
\begin{itemize}
|
||||
\item Rozpoczynając naukę tworzenia gier, Unity stanowi bezpieczniejszy wybór
|
||||
@ -239,7 +211,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item Inwestycja w~naukę C++ może być wartościowa długoterminowo
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Dla małych zespołów (2-10 osób)}
|
||||
|
||||
\begin{itemize}
|
||||
\item Unity pozwala na~szybsze MVP i~iteracje
|
||||
@ -247,7 +218,6 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
|
||||
\item Asset Store Unity oferuje więcej ready-to-use rozwiązań
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Dla studiów AAA}
|
||||
|
||||
\begin{itemize}
|
||||
\item Unreal Engine jest standardem przemysłowym dla~gier 3D wysokiej jakości
|
||||
|
||||
@ -20,13 +20,10 @@ który jest zoptymalizowany \\ przede wszystkim pod~kątem aplikacji 3D.''}
|
||||
|
||||
Wyniki badań \textbf{częściowo potwierdzają} tę hipotezę, jednak obraz jest bardziej złożony niż początkowo zakładano:
|
||||
|
||||
\paragraph{Wydajność w~fazie maksymalnego obciążenia}
|
||||
W~fazie 3 testu (60--90 sekund), reprezentującej maksymalne obciążenie sceny, oba silniki osiągnęły zbliżoną wydajność: Unity z~wartością 1\% low na~poziomie 132~FPS oraz Unreal Engine ze~średnią 162~FPS. Różnica około 23\% na~korzyść Unreal wynika częściowo z~różnych konfiguracji synchronizacji pionowej.
|
||||
|
||||
\paragraph{Wykorzystanie zasobów GPU}
|
||||
Unity wykorzystywał jedynie 23\% mocy obliczeniowej GPU (ograniczony przez V-Sync), podczas gdy Unreal Engine osiągał 91\% wykorzystania w~fazach 1--2. Sugeruje to znaczny potencjał wydajnościowy Unity przy wyłączonej synchronizacji pionowej.
|
||||
|
||||
\paragraph{Architektura renderowania}
|
||||
Analiza wywołań Vulkan API ujawniła fundamentalne różnice architektoniczne:
|
||||
\begin{itemize}
|
||||
\item Unity: prosty, dwuetapowy potok renderowania \\ (2 wywołania \texttt{vkQueueSubmit} na~klatkę),
|
||||
@ -34,12 +31,10 @@ Analiza wywołań Vulkan API ujawniła fundamentalne różnice architektoniczne:
|
||||
\item Unreal Engine: złożony potok z~16 wywołaniami \texttt{vkQueueSubmit} na~klatkę, zdominowany przez dynamiczną kompilację potoków (47--72\% czasu)
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Stabilność wydajności}
|
||||
Unity wykazał większą stabilność czasów klatek (98,24\% klatek w~przedziale 5--10~ms), podczas gdy Unreal Engine doświadczył spadku wydajności o~ponad 50\% między fazami niskiego (332--339~FPS) a~wysokiego obciążenia (162~FPS).
|
||||
|
||||
\subsection{Główne wyniki badań}
|
||||
|
||||
\subsubsection{Wyniki testów wydajnościowych}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
@ -59,7 +54,6 @@ Potoki graficzne utworzone & 3 & $\sim$2\,400 \\
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Wyniki analizy implementacji}
|
||||
|
||||
Praktyczna implementacja gry bullet hell potwierdziła przewagę Unity \\ dla~tego typu projektów:
|
||||
|
||||
@ -74,7 +68,6 @@ Praktyczna implementacja gry bullet hell potwierdziła przewagę Unity \\ dla~te
|
||||
\item \textbf{Instalacja na~Linux}: Unity -- około 30 minut, Unreal -- 2--4 godziny
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Wyniki wywiadów z~deweloperami}
|
||||
|
||||
Badania jakościowe z~udziałem 8~deweloperów potwierdziły:
|
||||
|
||||
@ -90,7 +83,6 @@ Badania jakościowe z~udziałem 8~deweloperów potwierdziły:
|
||||
|
||||
Na~podstawie przeprowadzonych badań sformułowano następujące rekomendacje:
|
||||
|
||||
\subsubsection{Wybór Unity jest wskazany gdy}
|
||||
|
||||
\begin{itemize}
|
||||
\item Projekt dotyczy gry 2D lub mobilnej
|
||||
@ -101,7 +93,6 @@ Na~podstawie przeprowadzonych badań sformułowano następujące rekomendacje:
|
||||
\item Wymagana jest dobra integracja z~Git (tekstowa serializacja scen)
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Wybór Unreal Engine jest wskazany gdy}
|
||||
|
||||
\begin{itemize}
|
||||
\item Projekt wymaga fotorealistycznej grafiki 3D
|
||||
@ -178,25 +169,20 @@ Przeprowadzone badania posiadają następujące ograniczenia:
|
||||
|
||||
Na~podstawie zidentyfikowanych ograniczeń proponuje się następujące kierunki przyszłych badań:
|
||||
|
||||
\paragraph{Rozszerzenie zakresu gatunkowego}
|
||||
Przeprowadzenie analogicznych testów
|
||||
\\ dla~gier RPG (open world), strategii czasu rzeczywistego, gier puzzle oraz symulatorów
|
||||
pozwoliłoby na~bardziej kompleksową ocenę wydajności silników.
|
||||
|
||||
\paragraph{Testy wieloplatformowe}
|
||||
Porównanie wydajności na~różnych konfiguracjach \\ sprzętowych
|
||||
(PC low-end, mid-range, high-end; urządzenia mobilne; konsole) dostarczyłoby
|
||||
praktycznych informacji dla~deweloperów celujących w~różne platformy.
|
||||
|
||||
\paragraph{Analiza ekonomiczna}
|
||||
Badanie Total Cost of Ownership (TCO) uwzględniające \\ czas nauki zespołu,
|
||||
koszty licencji, assetów, czas rozwoju i~koszty utrzymania projektu mogłoby
|
||||
dostarczyć cennych informacji biznesowych.
|
||||
|
||||
\paragraph{Badania longitudinalne}
|
||||
Śledzenie wydajności obu silników przez~2--3 lata, dokumentując wpływ kolejnych aktualizacji, pozwoliłoby na~ocenę długoterminowej stabilności i~kierunków rozwoju.
|
||||
|
||||
\paragraph{Automatyzacja metodologii}
|
||||
Stworzenie frameworka \\ do~automatycznego uruchamiania i~profilowania scenariuszy testowych
|
||||
umożliwiłoby powtarzalne badania na~większą skalę.
|
||||
|
||||
|
||||
@ -22,16 +22,13 @@ zarządzanie wersjami edytora i~projektami.
|
||||
\label{fig:unity_hub_editor_view}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Architektura systemu}
|
||||
|
||||
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.
|
||||
|
||||
\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:
|
||||
|
||||
\begin{lstlisting}[language=C, caption={Fragment implementacji object poolingu w Unity}, label={lst:unity-pool}]
|
||||
@ -51,10 +48,8 @@ public Bullet Spawn(Vector2 position, Vector2 direction,
|
||||
|
||||
Pula jest wstępnie rozgrzewana (\textit{warm capacity}) podczas inicjalizacji, co eliminuje alokacje podczas rozgrywki.
|
||||
|
||||
\paragraph{Singleton Pattern}
|
||||
Klasy \texttt{GameDirector} i~\texttt{EnemySpawner} wykorzystują \\ wzorzec Singleton z~właściwością \texttt{Instance}, zapewniając \\ globalny punkt dostępu do kluczowych systemów gry.
|
||||
|
||||
\subsubsection{System spawnu przeciwników}
|
||||
|
||||
\texttt{EnemySpawner} implementuje system eskalującej trudności poprzez interpolację czasu między spawnami:
|
||||
|
||||
@ -65,7 +60,6 @@ float delay = Mathf.Lerp(spawnDelayStart, spawnDelayEnd, t);
|
||||
|
||||
Przeciwnicy są definiowani przez strukturę \texttt{EnemyBlueprint}, która zawiera parametry takie jak prędkość, zdrowie, wzorce strzelania i zachowania. To podejście data-driven pozwala na łatwe tworzenie różnorodnych typów wrogów.
|
||||
|
||||
\subsubsection{Wyzwania napotkane w Unity}
|
||||
|
||||
Podczas implementacji napotkano następujące wyzwania:
|
||||
|
||||
@ -76,7 +70,6 @@ Podczas implementacji napotkano następujące wyzwania:
|
||||
\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}
|
||||
|
||||
\subsubsection{Pozytywne aspekty Unity}
|
||||
|
||||
\begin{itemize}
|
||||
\item Natywne wsparcie dla 2D -- dedykowany tryb 2D z odpowiednimi komponentami fizyki (\texttt{Rigidbody2D}, \texttt{Collider2D})
|
||||
@ -112,7 +105,6 @@ Instalacja Unreal Engine na systemie Linux okazała się znacznie bardziej skomp
|
||||
\label{fig:unreal_editor_view}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Podejście do grafiki 2D}
|
||||
|
||||
Fundamentalna różnica między Unity a~Unreal w~kontekście gier 2D polega na tym, że Unreal traktuje 2D jako ,,fałszywe 2D'' --
|
||||
w~rzeczywistości jest to scena 3D z~zablokowaną trzecią osią i~kamerą ortograficzną. Unity natomiast oferuje dedykowany
|
||||
@ -125,11 +117,9 @@ Ta różnica ma praktyczne konsekwencje:
|
||||
\item Sprite'y w Unreal są renderowane jako płaskie meshe w przestrzeni 3D
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{System Blueprintów vs C++}
|
||||
|
||||
Unreal oferuje dwa podejścia do programowania logiki gry:
|
||||
|
||||
\paragraph{Blueprinty} -- wizualny system skryptowy, który w teorii pozwala na szybkie prototypowanie bez pisania kodu.
|
||||
|
||||
W praktyce korzystanie z nich dla osoby która zna tradycyjne programowanie okazazało się frustrujące ze względu na:
|
||||
\begin{itemize}
|
||||
@ -139,11 +129,9 @@ W praktyce korzystanie z nich dla osoby która zna tradycyjne programowanie okaz
|
||||
\item Ograniczenie w funkcjach z którycj można korzytsać
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{C++} -- dla bardziej wydajnościowo krytycznych elementów (jak system object poolingu) zalecane jest użycie C++.
|
||||
użycie go ostatecznie okazało się bardziej intujcywne i prostsze dla projektu z uwagi na doświadczenie w pisaniu programów w
|
||||
tradycyjny sposób
|
||||
|
||||
\subsubsection{Object Pooling w Unreal}
|
||||
|
||||
Implementacja object poolingu w~Unreal wymaga innego podejścia \\ niż w Unity.
|
||||
Zamiast prostego \texttt{SetActive(true/\allowbreak false)}, Unreal wykorzystuje:
|
||||
@ -156,7 +144,6 @@ Zamiast prostego \texttt{SetActive(true/\allowbreak false)}, Unreal wykorzystuje
|
||||
|
||||
Ta granularność daje większą kontrolę, ale wymaga więcej kodu do osiągnięcia tego samego efektu.
|
||||
|
||||
\subsubsection{Wyzwania napotkane w Unreal}
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Brak natywnego 2D} -- konieczność ``symulowania'' środowiska 2D w silniku 3D
|
||||
@ -166,7 +153,6 @@ Ta granularność daje większą kontrolę, ale wymaga więcej kodu do osiągni
|
||||
\item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co \\ utrudnia merge'owanie i code review
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{Pozytywne aspekty Unreal}
|
||||
|
||||
\begin{itemize}
|
||||
\item Potężny system materiałów i efektów wizualnych
|
||||
|
||||
@ -8,7 +8,6 @@
|
||||
|
||||
Zarówno Unity, jak i~Unreal Engine oferują własne, wbudowane narzędzia do analizy wydajności. Każde z~nich posiada unikalne cechy dostosowane do specyfiki danego silnika.
|
||||
|
||||
\subsubsection{Unity Profiler}
|
||||
|
||||
Unity dostarcza rozbudowany profiler dostępny bezpośrednio w~edytorze \\ (Window $\rightarrow$ Analysis $\rightarrow$ Profiler)~\cite{unity_profiler}. \\ Narzędzie to oferuje:
|
||||
|
||||
@ -31,7 +30,6 @@ docelowym (np.~smartfonie), co jest szczególnie przydatne przy optymalizacji gi
|
||||
\label{fig:unity-profiler}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Unreal Insights}
|
||||
|
||||
Unreal Engine oferuje narzędzie Unreal Insights, które zastąpiło starszy system
|
||||
Session Frontend~\cite{unreal_insights}. Kluczowe funkcjonalności obejmują:
|
||||
@ -55,7 +53,6 @@ podgląd podstawowych metryk wydajności podczas \\ rozgrywki~\cite{unreal_docs}
|
||||
\label{fig:unreal-profiler}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Ograniczenia narzędzi wbudowanych}
|
||||
|
||||
Pomimo rozbudowanych możliwości, wbudowane profilery silników posiadają istotne ograniczenia
|
||||
w~kontekście porównawczych badań wydajnościowych:
|
||||
@ -84,7 +81,6 @@ niezależnie od używanego silnika czy API graficznego~\cite{nvidia_nsight}.
|
||||
\label{fig:nvidia-nsight}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Uzasadnienie wyboru}
|
||||
|
||||
Wybór NVIDIA Nsight jako głównego narzędzia pomiarowego podyktowany
|
||||
był następującymi czynnikami:
|
||||
@ -97,11 +93,9 @@ był następującymi czynnikami:
|
||||
\item \textbf{Spójny format danych} -- wyniki z~obu silników mają identyczną strukturę, co ułatwia automatyzację analizy
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Możliwości narzędzia}
|
||||
|
||||
NVIDIA Nsight Graphics oferuje szereg funkcjonalności istotnych dla badań wydajnościowych:
|
||||
\newpage
|
||||
\paragraph{Frame Profiler}
|
||||
Główny moduł analizy wydajności, umożliwiający:
|
||||
\begin{itemize}
|
||||
\item Przechwycenie i~analizę pojedynczej klatki (frame capture)
|
||||
@ -111,7 +105,6 @@ Główny moduł analizy wydajności, umożliwiający:
|
||||
\item Analizę wykorzystania jednostek obliczeniowych GPU
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{GPU Trace}
|
||||
Moduł do długoterminowej analizy wydajności:
|
||||
\begin{itemize}
|
||||
\item Rejestrowanie metryk przez określony czas (nie tylko pojedyncza klatka)
|
||||
@ -120,7 +113,6 @@ Moduł do długoterminowej analizy wydajności:
|
||||
\item Korelacja obciążenia GPU z~wydarzeniami w~grze
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Shader Profiler}
|
||||
Narzędzie do optymalizacji shaderów:
|
||||
\begin{itemize}
|
||||
\item Analiza wydajności poszczególnych shaderów
|
||||
@ -133,7 +125,6 @@ Narzędzie do optymalizacji shaderów:
|
||||
|
||||
Dane zebrane przez NVIDIA Nsight wymagają odpowiedniego przetworzenia w~celu uzyskania porównywalnych metryk.
|
||||
|
||||
\subsubsection{Eksport danych}
|
||||
|
||||
Nsight umożliwia eksport danych w~kilku formatach:
|
||||
\begin{itemize}
|
||||
@ -144,7 +135,6 @@ Nsight umożliwia eksport danych w~kilku formatach:
|
||||
|
||||
W~niniejszej pracy wykorzystano format CSV ze względu na łatwość importu do narzędzi analizy statystycznej.
|
||||
|
||||
\subsubsection{Kluczowe metryki}
|
||||
|
||||
Z~danych eksportowanych przez Nsight wyodrębniono następujące metryki:
|
||||
|
||||
|
||||
@ -24,7 +24,6 @@ Respondenci zostali dobrani według kryterium posiadania co najmniej rocznego do
|
||||
\subsection{Motywy wyboru silnika}
|
||||
\label{subsec:motywy-wyboru}
|
||||
|
||||
\subsubsection{Przystępność i próg wejścia}
|
||||
|
||||
Dominującym motywem wyboru Unity jako pierwszego silnika była jego \textbf{przystępność dla początkujących}. Respondenci wskazywali, że Unity oferuje mniejszą liczbę gotowych mechanik widocznych na starcie -- silnik nie narzuca użytkownikowi wbudowanych rozwiązań, jeżeli ten nie wybierze specjalnego szablonu projektu. Było to postrzegane jako zaleta dydaktyczna, ponieważ nowicjusze nie byli przytłaczani złożonością interfejsu.
|
||||
|
||||
@ -32,20 +31,17 @@ Jednocześnie respondenci podkreślali, że Unreal Engine w przeszłości (okoł
|
||||
|
||||
Paradoksalnie, mniejsza liczba wbudowanych funkcjonalności w Unity była postrzegana jako zaleta dydaktyczna -- silnik nie przytłaczał nowicjuszy złożonością interfejsu i pozwalał na stopniowe poznawanie kolejnych mechanizmów.
|
||||
|
||||
\subsubsection{Język programowania}
|
||||
|
||||
Wybór C\# jako głównego języka skryptowania w Unity stanowił istotny czynnik decyzyjny dla osób z wcześniejszym doświadczeniem w tym języku. Respondenci z backgroundem w C\# określali przejście do Unity jako naturalne i intuicyjne. Język ten był opisywany jako wysokopoziomowy, niewymagający ręcznego zarządzania pamięcią, co znacząco obniża barierę wejścia dla początkujących programistów.
|
||||
|
||||
Niektórzy respondenci zwracali uwagę, że C++ używany w Unreal Engine różni się od standardowego C++ -- jest rozszerzony o makra i mechanizmy specyficzne dla silnika, co może być zaskakujące dla programistów przyzwyczajonych do klasycznego C++.
|
||||
|
||||
\subsubsection{Wymagania projektu}
|
||||
|
||||
Wybór Unreal Engine często był podyktowany specyfiką projektu lub wymaganiami rynku pracy. Respondenci wskazywali, że projekty wymagające wysokiej jakości grafiki naturalnie kierowały ich w stronę Unreal Engine. Dodatkowo, część osób rozpoczęła naukę Unreal ze względu na większą liczbę ofert pracy wymagających znajomości tego silnika, szczególnie w segmencie gier AAA i większych studiów deweloperskich.
|
||||
|
||||
\subsection{Dokumentacja i materiały edukacyjne}
|
||||
\label{subsec:dokumentacja}
|
||||
|
||||
\subsubsection{Oficjalna dokumentacja}
|
||||
|
||||
W zakresie dokumentacji oficjalnej respondenci wyraźnie faworyzowali Unity. Dokumentacja tego silnika była opisywana jako dogłębna i szczegółowa -- praktycznie wszystkie klasy, metody i właściwości są dokładnie opisane, a dodatkowo często zawierają działające przykłady kodu, które można bezpośrednio skopiować i uruchomić w projekcie.
|
||||
|
||||
@ -59,7 +55,6 @@ domyślać się, co dana funkcja robi.
|
||||
|
||||
Jako pozytywny aspekt ekosystemu Unreal wskazywano fora deweloperskie, gdzie profesjonalni użytkownicy dzielą się rozwiązaniami. Problemem jest jednak to, że część najbardziej wartościowych zasobów znajduje się w zamkniętych sekcjach forum, dostępnych tylko dla wybranych firm po uzyskaniu specjalnych uprawnień od Epic Games.
|
||||
|
||||
\subsubsection{Nieoficjalne poradniki}
|
||||
|
||||
W przypadku materiałów nieoficjalnych (YouTube, blogi, fora) Unity również dominowało ilościowo. Respondenci szczególnie wyróżniali kanał Brackeys jako kluczowe źródło wiedzy dla początkujących i średniozaawansowanych użytkowników Unity.
|
||||
|
||||
@ -70,7 +65,6 @@ Poradniki do Unreal Engine były oceniane jako:
|
||||
\item Zbyt skoncentrowane na systemie Blueprints kosztem programowania w C++
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Jakość dydaktyczna poradników}
|
||||
|
||||
Respondenci zwracali uwagę na wspólny problem poradników do obu silników -- koncentrację na implementacji konkretnych funkcji kosztem dobrych praktyk programistycznych. Większość dostępnych materiałów skupia się na pokazaniu, jak zaimplementować pojedynczą mechanikę, bez wyjaśniania szerszego kontekstu architektonicznego czy zasad rozszerzalności kodu.
|
||||
|
||||
@ -79,13 +73,11 @@ Ten brak holistycznego podejścia sprawia, że początkujący deweloperzy potraf
|
||||
\subsection{Architektura i wzorce projektowe}
|
||||
\label{subsec:architektura}
|
||||
|
||||
\subsubsection{System komponentowy Unity}
|
||||
|
||||
Architektura Unity oparta na komponentach była oceniana pozytywnie pod względem elastyczności. Respondenci doceniali możliwość dzielenia funkcjonalności na małe, niezależne moduły (komponenty), które następnie można łączyć w większe całości.
|
||||
|
||||
Jednocześnie wskazywano na problemy wynikające z długu technologicznego Unity. Silnik jest bardzo monolityczny, z głęboką hierarchią dziedziczenia podstawowych konceptów. Niektóre obiekty bazowe zajmują tak dużo pamięci, że nie mieszczą się w pojedynczej linii cache procesora, co na współczesny hardware stanowi istotny problem wydajnościowy.
|
||||
|
||||
\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,
|
||||
@ -93,21 +85,18 @@ 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.
|
||||
|
||||
\subsubsection{Specjalizacja silników}
|
||||
|
||||
Respondenci zauważyli, że Unreal Engine jest wyraźnie zoptymalizowany pod gry typu first-person shooter. Tworzenie gier FPS w Unreal jest niezwykle proste -- wystarczy zaznaczyć odpowiednie opcje. Natomiast projekty odbiegające od tego wzorca (np. gry z rozbudowanym interfejsem użytkownika, gry turowe) wymagają znacznie więcej pracy i często sprowadzają się do obchodzenia domyślnych mechanizmów silnika.
|
||||
|
||||
\subsection{Kompilacja i przepływ pracy}
|
||||
\label{subsec:kompilacja}
|
||||
|
||||
\subsubsection{Czas kompilacji}
|
||||
|
||||
Czas kompilacji w Unity był identyfikowany jako znaczący problem przy większych projektach. W miarę rozrastania się bazy kodu, czas potrzebny na rekompilację po każdej zmianie rośnie.
|
||||
|
||||
Unity oferuje mechanizm Assembly Definitions jako rozwiązanie tego \\
|
||||
problemu. Bez podziału projektu na osobne assemblies każda zmiana w~kodzie powoduje rekompilację całego projektu. Podział na mniejsze moduły pozwala kompilować tylko zmienione fragmenty, znacząco skracając czas iteracji.
|
||||
|
||||
\subsubsection{Stabilność środowiska}
|
||||
|
||||
Istotną różnicą między silnikami jest obsługa błędów krytycznych. W Unity gra uruchomiona w edytorze działa jako osobny proces -- gdy wystąpi błąd krytyczny, zamyka się tylko ten proces, a edytor pozostaje stabilny. W Unreal Engine silnik i gra działają jako jeden proces, więc crash w grze powoduje utratę całego edytora wraz z ewentualnymi niezapisanymi zmianami.
|
||||
|
||||
@ -115,14 +104,12 @@ Ta różnica architekturalna ma istotne konsekwencje dla produktywności, \\
|
||||
szczególnie przy debugowaniu. Przy dużych projektach, gdzie uruchomienie \\
|
||||
silnika może trwać kilkanaście minut, każdy crash oznacza znaczną stratę czasu.
|
||||
|
||||
\subsubsection{Kompatybilność wsteczna}
|
||||
|
||||
Unreal Engine był krytykowany za problemy z kompatybilnością między wersjami. Respondenci wskazywali, że rozpoczęcie projektu w określonej wersji silnika może skutkować problemami, jeśli ta wersja okaże się zawierać fundamentalne błędy. Epic Games nie backportuje poprawek do starszych wersji w takim stopniu jak Unity robi to dla wersji LTS.
|
||||
|
||||
\subsection{Kontrola wersji i współpraca zespołowa}
|
||||
\label{subsec:kontrola-wersji}
|
||||
|
||||
\subsubsection{Integracja z Git}
|
||||
|
||||
Współpraca z systemem Git była oceniana lepiej dla Unity ze względu na tekstową serializację assetów. Pliki scen i prefabów w Unity są zapisywane w formacie YAML, co teoretycznie umożliwia ich mergowanie. Nowoczesne narzędzia (np. merge w Rider) potrafią automatycznie rozwiązywać niektóre konflikty na scenach.
|
||||
|
||||
@ -130,7 +117,6 @@ Pliki binarne w Unreal Engine stanowią znaczące wyzwanie. Respondenci \\
|
||||
zwracali uwagę, że nawet pliki Blueprintów, które ewidentnie mają serializację \\
|
||||
tekstową, są zapisywane na dysku jako binaria. To znacznie utrudnia współpracę wielu programistów nad tym samym projektem.
|
||||
|
||||
\subsubsection{Mergowanie konfliktów}
|
||||
|
||||
Konflikty na scenach i prefabach stanowią problem w obu silnikach. Gdy dwie osoby edytują tę samą scenę, rozwiązanie konfliktu często sprowadza się do wybrania jednej wersji i ręcznego przeniesienia zmian z drugiej.
|
||||
|
||||
@ -139,13 +125,11 @@ Jako rozwiązanie wskazywano praktykę lockowania plików (preferowana przy uży
|
||||
\subsection{Współpraca z osobami nietechnicznymi}
|
||||
\label{subsec:wspolpraca-nietechniczna}
|
||||
|
||||
\subsubsection{System Blueprints}
|
||||
|
||||
Blueprinty w Unreal Engine były postrzegane jako skuteczne narzędzie ułatwiające współpracę z osobami nietechnicznymi. System wizualnego programowania pozwala designerom i artystom na tworzenie logiki gry bez pisania kodu tekstowego. Respondenci zauważali, że osoby niebędące programistami często nie zdają sobie sprawy, że faktycznie programują, korzystając z Blueprintów.
|
||||
|
||||
Jednocześnie integracja Blueprintów z kodem C++ nie jest idealna. Przejście między oboma systemami wymaga dodatkowej pracy, a wystawianie funkcji C++ do Blueprintów nie zawsze działa bezproblemowo.
|
||||
|
||||
\subsubsection{Narzędzia dla artystów}
|
||||
|
||||
Unity wymaga więcej pracy przy tworzeniu narzędzi dla osób \\
|
||||
nietechnicznych. Respondenci wskazywali, że w~Unreal Engine osoby \\
|
||||
@ -157,7 +141,6 @@ i~designerom samodzielną pracę.
|
||||
\subsection{Asset Store i zasoby zewnętrzne}
|
||||
\label{subsec:asset-store}
|
||||
|
||||
\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
|
||||
@ -171,14 +154,12 @@ 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.
|
||||
|
||||
\subsubsection{Zastosowanie assetów}
|
||||
|
||||
Assety były rekomendowane głównie do prototypowania, nie do produkcji komercyjnej. Respondenci podkreślali, że niespójny styl graficzny wynikający z łączenia assetów od różnych twórców jest gorszy niż jednolity, nawet jeśli prosty styl graficzny.
|
||||
|
||||
\subsection{Wykorzystanie sztucznej inteligencji}
|
||||
\label{subsec:ai}
|
||||
|
||||
\subsubsection{Doświadczenia z LLM}
|
||||
|
||||
Większość respondentów miała ograniczone doświadczenia
|
||||
\\ z~wykorzystaniem AI w~pracy z~silnikami gier. Główna obserwacja
|
||||
@ -190,40 +171,33 @@ Jednocześnie AI było wykorzystywane skuteczniej jako substytut dokumentacji dl
|
||||
Pomimo częstych konfabulacji, modele językowe potrafiły naprowadzić na właściwe słowa kluczowe
|
||||
lub nazwy funkcji, które następnie można było zweryfikować w kodzie źródłowym silnika.
|
||||
|
||||
\subsubsection{Generowanie grafik}
|
||||
|
||||
Pozytywne doświadczenia zgłoszono w zakresie generowania placeholderów graficznych podczas game jamów. AI pozwala szybko uzyskać przyzwoicie wyglądające grafiki do prototypów, choć do wersji finalnych produktów nadal preferowana jest praca profesjonalnych grafików.
|
||||
|
||||
\subsection{Optymalizacja i wydajność}
|
||||
\label{subsec:optymalizacja}
|
||||
|
||||
\subsubsection{Narzut silników}
|
||||
|
||||
Respondenci wskazywali, że Unity ma mniejszy narzut wydajnościowy niż \\
|
||||
Unreal dla prostych projektów. Czas ładowania projektów w~Unity jest znacznie krótszy, co respondenci przypisywali domyślnie niższym rozdzielczościom tekstur i~prostszym ustawieniom graficznym.
|
||||
|
||||
\subsubsection{Blueprinty vs C++}
|
||||
|
||||
Istotną różnicę wydajnościową w Unreal stanowi wybór między Blueprintami a kodem C++. Blueprinty są interpretowane w czasie wykonania jako dane, a nie kompilowane do kodu maszynowego. W praktyce oznacza to, że logika napisana w Blueprintach jest znacznie wolniejsza niż równoważny kod C++.
|
||||
|
||||
\subsubsection{Garbage Collector}
|
||||
|
||||
Problem garbage collectora w Unity był wielokrotnie wspominany jako znany problem, przed którym ostrzegają doświadczeni deweloperzy. Cykliczne uruchamianie garbage collectora może powodować zauważalne zacięcia w grze. Co ciekawe, wielu respondentów wspominało o tym problemie jako o teoretycznym zagrożeniu, nie mając bezpośrednich negatywnych doświadczeń -- prawdopodobnie dzięki stosowaniu praktyk takich jak object pooling.
|
||||
|
||||
\subsection{Przyszłość silników i oczekiwania deweloperów}
|
||||
\label{subsec:przyszlosc}
|
||||
|
||||
\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.
|
||||
|
||||
\subsubsection{UI Toolkit}
|
||||
|
||||
Nowy system UI w Unity (UI Toolkit) był wskazywany jako obszar wymagający poprawy. Respondenci wyrażali nadzieję na jego dalszy rozwój w kierunku zbliżonym do technologii frontendowych, co ułatwiłoby pracę osobom z doświadczeniem w tworzeniu aplikacji webowych.
|
||||
|
||||
\subsubsection{Konkurencja Godot}
|
||||
|
||||
Część respondentów wyraziła zainteresowanie silnikiem Godot jako alternatywą dla Unity i Unreal. Główne przyczyny to:
|
||||
\begin{itemize}
|
||||
@ -241,7 +215,6 @@ i~oferty, Godot może w~przyszłości stać się poważną konkurencją w~segmen
|
||||
|
||||
Na podstawie przeprowadzonych wywiadów można sformułować następujące wnioski:
|
||||
|
||||
\subsubsection{Silne strony Unity}
|
||||
\begin{itemize}
|
||||
\item Wysoka jakość oficjalnej dokumentacji
|
||||
\item Bogaty ekosystem materiałów edukacyjnych
|
||||
@ -252,7 +225,6 @@ Na podstawie przeprowadzonych wywiadów można sformułować następujące wnios
|
||||
\item Mniejszy narzut wydajnościowy dla prostych projektów
|
||||
\end{itemize}
|
||||
|
||||
\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
|
||||
@ -262,14 +234,12 @@ Na podstawie przeprowadzonych wywiadów można sformułować następujące wnios
|
||||
\item Lepsza integracja z zewnętrznymi narzędziami graficznymi (np. Blender)
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Obszary problemowe wspólne}
|
||||
\begin{itemize}
|
||||
\item Trudności z mergowaniem assetów graficznych w systemach kontroli wersji
|
||||
\item Poradniki koncentrujące się na implementacji kosztem dobrych praktyk
|
||||
\item Problemy z kompatybilnością między wersjami silników
|
||||
\end{itemize}
|
||||
\newpage
|
||||
\subsubsection{Rekomendacje z badań}
|
||||
|
||||
Na podstawie wywiadów można zasugerować następujące kryteria wyboru silnika:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user