interactables

This commit is contained in:
Oleg Petruny 2025-05-20 07:50:33 +02:00
parent 870dfa9a2d
commit 7fde56bcb8
2 changed files with 21 additions and 7 deletions

28
ch2.tex
View File

@ -13,6 +13,8 @@ Přenos byl~odůvodněn převážně malou velikostí starého projektu a~taky l
\end{itemize} \end{itemize}
Samozřejmě je~toho daleko víc, ale~většina ostatních vylepšení jako~například nový systémy animací postav Motion Matching\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/motion-matching-in-unreal-engine} nebo~nový fyzikální engine Chaos\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/destruction-overview} neměli vliv na~rozhodnutí. Samozřejmě je~toho daleko víc, ale~většina ostatních vylepšení jako~například nový systémy animací postav Motion Matching\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/motion-matching-in-unreal-engine} nebo~nový fyzikální engine Chaos\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/destruction-overview} neměli vliv na~rozhodnutí.
Podrobné informace jak každá implementace funguje a jak vývojaři s ní pracovat jsou popsané v programatorské dokumentaci.
\section{Herní logika a systémy} \section{Herní logika a systémy}
\subsection{Architektura} \subsection{Architektura}
Protože Unreal Engine byl na začátku vývíjen primárně pro online multiplayer hru Unreal Tournament a dnes stejně tak vyvíjen spolu s extremně velkou online multiplayer hrou Fortnite, je backend enginu dost abstraktní. Protože Unreal Engine byl na začátku vývíjen primárně pro online multiplayer hru Unreal Tournament a dnes stejně tak vyvíjen spolu s extremně velkou online multiplayer hrou Fortnite, je backend enginu dost abstraktní.
@ -26,26 +28,38 @@ Jen pro představu co obnaší klasické ziskání reference na instanci vlastn
\subsection{Scény a ukládání hry} \subsection{Scény a ukládání hry}
Scény resp. levely (třídy UWorld a ALevelScriptActor)\footnote{UWorld instance je přímo celý svět, který funguje jako balík metadat a kontejner pro veškeré instancované objekty v něm. ALevelScriptActor je objekt instancovaný v UWorld automaticky a obsahuje uživatelskou logiku světa.} taktéž lze získat v podobě singletonu. Základní implementace byla rozšířená pro high level mechanismus volání událostí ve scéně. Ten je za potřebí například, když hráč aktivuje spínací plošinu ve hře a ta následně otevře dveře. Narozdíl od jiných enginů, v UE objekty ve světě nemůžou referencovat jiné nezávislé objekty. Jednoduše referenci nejde přiřadít z důvodu abstrakce popsané v předchozí podsekci, protože každý objekt může mít vlastní herní svět (a nejen to). Proto pokud plošina z našeho príkladu chce otevřít dveře, musí zkusit poslat požádavek správcí herního světa, ten požadavek se nějak zpracuje a jen potom správce buď provede akci otevírání dveří samostatně nebo zavolá odpovidající funkci v instanci objektu. Pokud by byla potřeba zbavit se použití singleton architektury pro podporu paralelní existenci světů, stači předělat member funkci instance světa na statický multicast delegate\footnote{Delegate jsou obaly na C++ funkce, lambdy, funkce s reflexi a funkce z Blueprintu. Delegate může být typu single, pro uložení reference na jednou funkci, nebo multicast pro uložení dynamického seznamu funkcí. Podrobněji jsou popsané v programatorské dokumentaci.}, ke kterému se každý svět při konstrukci bude vázat. Scény resp. levely (třídy UWorld a ALevelScriptActor)\footnote{UWorld instance je přímo celý svět, který funguje jako balík metadat a kontejner pro veškeré instancované objekty v něm. ALevelScriptActor je objekt instancovaný v UWorld automaticky a obsahuje uživatelskou logiku světa.} taktéž lze získat v podobě singletonu. Základní implementace byla rozšířená pro high level mechanismus volání událostí ve scéně. Ten je za potřebí například, když hráč aktivuje spínací plošinu ve hře a ta následně otevře dveře. Narozdíl od jiných enginů, v UE objekty ve světě nemůžou referencovat jiné nezávislé objekty. Jednoduše referenci nejde přiřadít z důvodu abstrakce popsané v předchozí podsekci, protože každý objekt může mít vlastní herní svět (a nejen to). Proto pokud plošina z našeho príkladu chce otevřít dveře, musí zkusit poslat požádavek správcí herního světa, ten požadavek se nějak zpracuje a jen potom správce buď provede akci otevírání dveří samostatně nebo zavolá odpovidající funkci v instanci objektu. Pokud by byla potřeba zbavit se použití singleton architektury pro podporu paralelní existenci světů, stači předělat member funkci instance světa na statický multicast delegate\footnote{Delegate jsou obaly na C++ funkce, lambdy, funkce s reflexi a funkce z Blueprintu. Delegate může být typu single, pro uložení reference na jednou funkci, nebo multicast pro uložení dynamického seznamu funkcí. Podrobněji jsou popsané v programatorské dokumentaci.}, ke kterému se každý svět při konstrukci bude vázat.
Navíc hra byla rozšířena o implementaci obnovení hry z úložených dat. Při návrhu byla snaha udělat postup nejvíc triviální. Hru ukládá globální herní instance (třída GameInstance)\footnote{GameInstance je první objekt vytvořený enginem hned po úvodním načtení základu enginu a taky poslední objekt na destrukci při vypínání hry.} při vypínání hry a načíta taktéž při spouštění. Využit byl existující v UE systém serializace, který ukládá inventař postavy, jmeno levlu a checkpoint na něm spolu s posledním stavem levlu. Podrobný proces obnovení uložené hry a práce se serializací je popsan v programatorské dokumentaci. Navíc hra byla rozšířena o implementaci obnovení hry z úložených dat. Při návrhu byla snaha udělat postup nejvíc triviální. Hru ukládá globální herní instance (třída GameInstance)\footnote{GameInstance je první objekt vytvořený enginem hned po úvodním načtení základu enginu a taky poslední objekt na destrukci při vypínání hry.} při vypínání hry a načíta taktéž při spouštění. Využit byl existující v UE systém serializace, který ukládá inventař postavy, jmeno levlu a checkpoint na něm spolu s posledním stavem levlu.
\subsection{Interakce} \subsection{Interakce}
Interakce jsou často řešeny pomoci architektury interface tříd\footnote{Interface třídy jsou konkurenčním přístupem komponentní architektuře. Interface je běžná praktika v OOP, která funguje jako domluva, že objekt bude obsahovat určité member funkce. Komponentny jsou samostatné určité podinstance objektu. Komponentní přístup se osvědčuje jako intuitivnější a více flexibilní zatímco Interface přístup při vývoji her je spíše nepřijemné vynucení ze světu OOP.} především kvůli populárním návodům vyzdvihující tuto metodu jako nejlepší ještě z doby, kdy jen vzníkal Unreal Engine 4. Nevýhodou je potřeba v obsáhlem a repetetivním nastavení každeho objektu, který chceme zapojit do mechaniky interakce. Interakce jsou často řešeny pomoci architektury interface tříd\footnote{Interface třídy jsou konkurenčním přístupem komponentní architektuře. Interface je běžná praktika v OOP, která funguje jako domluva, že objekt bude obsahovat určité member funkce. Komponentny jsou samostatné určité podinstance objektu. Komponentní přístup se osvědčuje jako intuitivnější a více flexibilní zatímco Interface přístup při vývoji her je spíše nepřijemné vynucení ze světu OOP.} především kvůli populárním návodům vyzdvihující tuto metodu jako nejlepší ještě z doby, kdy jen vzníkal Unreal Engine 4. Nevýhodou je potřeba v obsáhlem a repetetivním nastavení každeho objektu, který chceme zapojit do mechaniky interakce.
Byla navržena celá třída pro kompletní spravu každého intekačního objektu a komponent. Objekt dědicí třídu AInteractable při instancování samostatně nastaví a následně přepína potřebné kolize. Navíc spravuje interakční komponenty a reaguje na požadavky k ním. Komponenty se dělí na aktivatory a modifikatory. Byl navržen kompletní systém pro spravu každého interačního objektu a komponent (viz.\Cref{fig:InteractableSystemDiagram}). Objekt dědicí třídu AInteractable při instancování samostatně nastaví a následně přepína potřebné kolize. Navíc spravuje interakční komponenty a reaguje na požadavky k ním. Komponenty se dělí na aktivatory a modifikatory.
\paragraph{AInteractableActivator} Aktivatory jsou komponenty s úrčitými mechanismy detekce objektů. Instance hráče automaticky vytváří pro sebe jednu podinstanci každého aktivatoru zaregistrovaného v enginu. Libovolný objekt taky může obsahovat libovolný aktivator. Podrobně o aktivatorech je popsano v dokumentaci. Práce obsahuje klasický způsob detekce objektů pomoci raytracingu a castu objektu v případě nárazu paprsku.
Navíc je k dispozici detekce objektů v zornem poli hráče. Ta funguje na zpomaleném snímání určité stencil vrstvy s vynecháním většiny render pipliny a v malém rozlišení. Zachycený snímek obsahuje pouze viditelné hráčem interakční objekty v podobě masky. Nasledně maska v grafickém vlakně je zpracovaná pomocí algoritmu vyhledávání komponent z počítačového vidění, kterou poskytuje kníhovna OpenCV. Nakonec na nalezené komponenty se promítné paprsek a zachytí objekt (viz. výsledek \Cref{fig:InteractableScreenCapture}). Původně
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=1\linewidth]{img/InteractableScreenCapture.pdf} \includegraphics[width=1\linewidth]{img/InteractableScreenCapture.pdf}
\caption{.} \caption{Debug náhled aktivace interakčních objektů v zornem poli hráče.}
\label{fig:InteractableScreenCapture} \label{fig:InteractableScreenCapture}
\end{figure} \end{figure}
\paragraph{AInteractableActivator} Aktivátory jsou komponenty s úrčitými mechanismy detekce objektů. Instance hráče automaticky vytváří pro sebe jednu podinstanci každého aktivatoru zaregistrovaného v enginu. Libovolný objekt taky může obsahovat libovolný aktivator. Práce obsahuje klasický způsob detekce objektů pomoci raytracingu a castu objektu v případě nárazu paprsku.
Navíc je k dispozici detekce objektů v zornem poli hráče. Ta funguje na zpomaleném snímání určité stencil vrstvy s vynecháním většiny render pipliny a v malém rozlišení. Zachycený snímek obsahuje pouze viditelné hráčem interakční objekty v podobě masky. Nasledně maska v grafickém vlakně je zpracovaná pomocí algoritmu vyhledávání komponent z počítačového vidění, kterou poskytuje kníhovna OpenCV. Nakonec do středu nalezených komponent se promítné paprsek a zachytí objekty (viz. \Cref{fig:InteractableScreenCapture}). Původně bylo předpokládáno využití HLSL compute shaderu pro vyhledání komponent v textuře, ale z časových důvodu jsem nedodělal přenos dat mezi CPU a GPU, jelikož dohledat dokumentaci o použití shaderu je dost náročné. Proto aktuální vyhledávání komponent je spouštěno na procesoru a v renderovacím vlakně na moderních zařízeních trvá pět až deset milisekund.
\begin{figure}
\centering
\includegraphics[width=1\linewidth]{img/InteractableScreenCapture.pdf}
\caption{Debug náhled aktivace interakčních objektů v zornem poli hráče.}
\label{fig:InteractableScreenCapture}
\end{figure}
\paragraph{AInteractableModificator} Modifikátory jsou komponenty s úrčitou logikou libovolné modifikace objektu, ve kterém jsou instancovány. Tyto komponenty mohou obsahovat pouze objekty označené jako interakční (dědí třídu interákčního objektu). Aktuální implementace nabízí modifikátory pro aktivaci nějaké události pomoci dosahu ,,ruky'' nebo zahlednutím ,,očí'' hráče, pohyb a rotace předmětu v prostoru, ukládání předmětu do inventáře hráče. Z časových důvodu byla zamítnuta implementace modifikace meshe objektu, která by využivala nového rozhraní Chaos.
Právě u modifikátorů nejvíc přispěl nový system vstupu pro Unreal Engine 5. Modifikatory využívájí možnosti přidávání resp. odstranění kontextů vstupu za běhu.
\subsection{Cutscény} \subsection{Cutscény}
\subsection{Quick Time Eventy} \subsection{Quick Time Eventy}
\subsection{Dialogy} \subsection{Dialogy}
\subsection{Minihry} \subsection{Minihry}

Binary file not shown.