diff --git a/.run/Final Report.run.xml b/.run/Final Report.run.xml index 54930489..70474f74 100644 --- a/.run/Final Report.run.xml +++ b/.run/Final Report.run.xml @@ -3,7 +3,7 @@ PDFLATEX - SumatraPDF + none true @@ -11,13 +11,14 @@ false $PROJECT_DIR$/papers/final_report/main.tex - {projectDir}/out - {projectDir}/auxil - false + $PROJECT_DIR$/papers/final_report + $PROJECT_DIR$/papers/final_report + {mainFileParent} + true PDF MIKTEX - false - [] + true + [BibTeX.Final Report Bibliography] [] diff --git a/.run/Proposal.run.xml b/.run/Proposal.run.xml index 0e6c85c3..07bc123f 100644 --- a/.run/Proposal.run.xml +++ b/.run/Proposal.run.xml @@ -3,7 +3,7 @@ PDFLATEX - SumatraPDF + none true @@ -12,10 +12,11 @@ $PROJECT_DIR$/papers/proposal/main.tex $PROJECT_DIR$/papers/proposal - $PROJECT_DIR$/auxil + $PROJECT_DIR$/papers/proposal + {mainFileParent} true PDF - TEXLIVE + MIKTEX true [BibTeX.Proposal Bibliography] [] diff --git a/papers/final_report/images/Turnitin.png b/papers/final_report/images/Turnitin.png new file mode 100644 index 00000000..9825a788 Binary files /dev/null and b/papers/final_report/images/Turnitin.png differ diff --git a/papers/final_report/images/designbullet.png b/papers/final_report/images/designbullet.png new file mode 100644 index 00000000..ec6b6121 Binary files /dev/null and b/papers/final_report/images/designbullet.png differ diff --git a/papers/final_report/images/designrhythm.png b/papers/final_report/images/designrhythm.png new file mode 100644 index 00000000..151e1147 Binary files /dev/null and b/papers/final_report/images/designrhythm.png differ diff --git a/papers/final_report/images/engine.png b/papers/final_report/images/engine.png new file mode 100644 index 00000000..aa798849 Binary files /dev/null and b/papers/final_report/images/engine.png differ diff --git a/papers/final_report/images/gameflow.jpg b/papers/final_report/images/gameflow.jpg new file mode 100644 index 00000000..8e68ef61 Binary files /dev/null and b/papers/final_report/images/gameflow.jpg differ diff --git a/papers/final_report/images/scenemanager.jpg b/papers/final_report/images/scenemanager.jpg new file mode 100644 index 00000000..f95b6058 Binary files /dev/null and b/papers/final_report/images/scenemanager.jpg differ diff --git a/papers/final_report/images/scenemanager2.jpg b/papers/final_report/images/scenemanager2.jpg new file mode 100644 index 00000000..08560171 Binary files /dev/null and b/papers/final_report/images/scenemanager2.jpg differ diff --git a/papers/final_report/images/taskmanager.jpg b/papers/final_report/images/taskmanager.jpg new file mode 100644 index 00000000..ff4ee2fa Binary files /dev/null and b/papers/final_report/images/taskmanager.jpg differ diff --git a/papers/final_report/images/title.png b/papers/final_report/images/title.png new file mode 100644 index 00000000..c09cfea6 Binary files /dev/null and b/papers/final_report/images/title.png differ diff --git a/papers/final_report/main.tex b/papers/final_report/main.tex index 30abe63b..38868c9f 100644 --- a/papers/final_report/main.tex +++ b/papers/final_report/main.tex @@ -1,39 +1,197 @@ -% == Preamble == -\documentclass[12pt]{article} +\documentclass[10pt]{article} -% == Packages == +% Packages \usepackage{graphicx} \usepackage{amsmath} \usepackage{hyperref} \usepackage{geometry} +\usepackage{changepage} +\usepackage{fancyhdr} +\usepackage{tocloft} +\usepackage{titlesec} +\usepackage{lastpage} +\usepackage{caption} +\usepackage{tabularx} +\usepackage{array} +\usepackage{multicol} +\usepackage{multirow} + +\captionsetup[figure]{ + font={it, small}, + labelfont=bf, + labelsep=period, + justification=centering, + singlelinecheck=false +} + +\captionsetup[table]{ + font={it, small}, + labelfont=bf, + labelsep=period, + justification=centering, + singlelinecheck=false +} + +\titleformat{\section} +{\normalsize\bfseries} +{\thesection \, \textbar} +{0.5em} +{} + +\titleformat{\subsection} +{\normalsize\bfseries} +{\thesubsection \, \textbar} +{0.5em} +{} \geometry{a4paper, margin=1in} -% == Project Config == -\title{Utilization of High Precision Software System for Development of Interactive Entertainment Media} -\author{Tapaneeya Odmung, Wachirawich Kanil, Pranesh Ingkanunt, Rangsiman Jearuksa} -\date{\today} +\fancyhf{} +\fancyfoot[L]{ + \scriptsize\bfseries + Department of Computer Engineering\\ + Chulalongkorn University +} + +\renewcommand{\headrulewidth}{0pt} +\renewcommand{\footrulewidth}{0.5pt} +\renewcommand{\cftsecaftersnum}{.} +\renewcommand{\arraystretch}{1.75} -% == Main stuff == +\newcolumntype{Y}{>{\centering\arraybackslash}X} +\newcolumntype{L}{>{\raggedright\arraybackslash}X} +\newcolumntype{R}{>{\raggedleft\arraybackslash}X} + +\sloppy \begin{document} - - \maketitle + \pagestyle{plain} + \begin{titlepage} + \input{sections/title} + \noindent + {\rule{\textwidth}{0.5px}\par} + \vspace{-0.4cm} + \input{sections/abstract} + \noindent + {\rule{\textwidth}{0.5px}\par} + \end{titlepage} + + \pagestyle{fancy} + \pagenumbering{roman} + \fancyfoot[R]{\thepage} + + \addcontentsline{toc}{section}{Contents} \tableofcontents + \thispagestyle{fancy} + \newpage + + \fancyfoot[R]{ + \thepage\ of \pageref{tag:end} + } + \pagenumbering{arabic} + \setcounter{page}{1} + + \begin{multicols}{2} + \raggedcolumns + \input{sections/introduction} + \input{sections/related_work} + \input{sections/design} + \input{sections/implementation} + \input{sections/testing} + \end{multicols} + \newpage + \begin{multicols}{1} + \input{sections/results_one_column} + \end{multicols} + \vspace{0.5em} + \begin{multicols}{1} + \input{sections/results_one_column_two} + \end{multicols} + \begin{multicols}{2} + \raggedcolumns + \input{sections/results_two_column} + \end{multicols} + \vspace{0.5em} + \begin{multicols}{1} + \input{sections/timeline_one_column} + \end{multicols} + \vspace{0.5em} + \newpage + \begin{multicols}{1} + \input{sections/team_one_column} + \end{multicols} + \vspace{0.5em} + \begin{multicols}{2} + \raggedcolumns + \input{sections/team_two_column} + \end{multicols} \newpage - - \input{sections/abstract.tex} - \input{sections/introduction.tex} - \input{sections/related_work.tex} - \input{sections/design.tex} - \input{sections/implementation.tex} - \input{sections/experimentation.tex} - \input{sections/result.tex} - \input{sections/project_management.tex} - \input{sections/ethics.tex} - \input{sections/risks.tex} - \input{sections/conclusion.tex} +% \begin{multicols}{2} +% \raggedcolumns +% \input{sections/timeline_two_column} +% \end{multicols} + \begin{multicols}{2} + \raggedcolumns +% \input{sections/planned_work_two_column} + \input{sections/ethics} + \input{sections/risk_and_resource} + \input{sections/conclusion} + \end{multicols} + \onecolumn + \fancyfoot[R]{\thepage} + \pagenumbering{alph} + + \addcontentsline{toc}{section}{References} \bibliographystyle{ieeetr} \bibliography{refs} + \newpage + + % -- Appendix if needed (which you will) -- % + \appendix + \renewcommand{\thesection}{\Alph{section}} + \titleformat{\section} + {\normalsize\bfseries} + {Appendix \thesection \, \textbar} + {0.5em} + {} + + \makeatletter + \renewcommand{\listoffigures}{ + \begingroup + \let\old@makecaption\@makecaption + \renewcommand{\@makecaption}[2]{##2\\} + \parindent\z@ + \refstepcounter{section} + \section*{Appendix \thesection \, \textbar \vspace{0.5em} List of Figures} + \label{sec:appendix-list-of-figures} + \addcontentsline{toc}{section}{Appendix \thesection. List of Figures} + \@starttoc{lof} + \let\old@makecaption\@makecaption + \endgroup + } + + \renewcommand{\listoftables}{ + \begingroup + \let\old@makecaption\@makecaption + \renewcommand{\@makecaption}[2]{##2\\} + \parindent\z@ + \refstepcounter{section} + \section*{Appendix \thesection \, \textbar \vspace{0.5em} List of Tables} + \label{sec:appendix-list-of-tables} + \addcontentsline{toc}{section}{Appendix \thesection. List of Tables} + \@starttoc{lot} + \let\old@makecaption\@makecaption + \endgroup + } + \makeatother + + \listoffigures + + \listoftables + % \input{sections/feasibility} + % \input{sections/document_standard} + % \input{sections/coding_standard} + % -- Skip for now -- % +% \input{sections/literature_review} \end{document} \ No newline at end of file diff --git a/papers/final_report/refs.bib b/papers/final_report/refs.bib index e69de29b..5783a2c6 100644 --- a/papers/final_report/refs.bib +++ b/papers/final_report/refs.bib @@ -0,0 +1,229 @@ +@misc{vittorio, + author = {Romeo, Vittorio}, + year = {2016}, + month = {July}, + howpublished = {Bachelor's thesis (University of Messina)}, + title = {Analysis of entity encoding techniques, design and implementation of a multithreaded compile-time {Entity-Component-System} {C++14} library}, + doi = {10.13140/RG.2.1.1307.4165} +} + +@article{Redmond_2025_CoreECS, + author = {Redmond, Patrick and Castello, Jonathan and Calderón Trilla, José Manuel and Kuper, Lindsey}, + title = {Exploring the Theory and Practice of Concurrency in the {Entity-Component-System} Pattern}, + journal = {arXiv preprint arXiv:2508.15264}, + year = {2025}, + note = {View at \url{https://arxiv.org/abs/2508.15264}} +} + +@inproceedings{Cox2025_SparseSet_vs_Archetype, + author = {Cox, Louis and Williams, Benjamin and Vickers, James and Ward, Davin and Headleand, Christopher}, + title = {Run-time Performance Comparison of Sparse-set and Archetype Entity-Component Systems}, + booktitle = {Eurographics Symposium on …}, + year = {2025}, + note = {Implementation in C++20; comparing iteration speed and entity modification costs} +} + +@misc{ValtoLibraries_EnTT, + author = {skypjack / ValtoLibraries}, + title = {{EnTT}: A header-only, modern {C++} entity-component-system library}, + howpublished = {Software library (GitHub)}, + year = {~2019}, + note = {Available at \url{https://github.com/skypjack/entt}} +} + +@misc{Bevy_Engine, + author = {Cart, Carter and the Bevy Contributors}, + title = {{Bevy}: A data-driven game engine built in {Rust}}, + howpublished = {GitHub repository}, + year = {2020}, + note = {Version 0.14. Available at \url{https://github.com/bevyengine/bevy}} +} + +@misc{bevy_minimalplugins, + author = {{Bevy Contributors}}, + title = {{bevy::MinimalPlugins}}, + year = {2026}, + howpublished = {\url{https://docs.rs/bevy/latest/bevy/struct.MinimalPlugins.html}}, + note = {Accessed: 2026-05-08} +} + +@misc{Unity_Engine, + author = {{Unity Technologies}}, + howpublished = {Software}, + title = {{Unity} Real-Time Development Platform | {3D}, {2D}, {VR} \& {AR} Engine}, + year = {2015}, + note = {Consider since Version 5.0 | Version 2022.1 (2022) used for reference | Available at \url{https://unity.com/}} +} + +@misc{Unity_DOTS, + author = {{Unity Technologies}}, + howpublished = {Documentation}, + title = {{DOTS} - {Unity}'s Data-Oriented Technology Stack}, + year = {2023}, + note = {View at \url{https://unity.com/dots}} +} + +@misc{Unreal_Engine, + author = {{Epic Games}}, + howpublished = {Software}, + title = {The most powerful real-time {3D} creation tool - {Unreal Engine}}, + year = {2014}, + note = {Consider since Version 4.27 | Version 5.0 used for reference | Available at \url{https://www.unrealengine.com/}} +} + +@misc{Unreal_MassEntity, + author = {{Epic Games}}, + howpublished = {Documentation}, + title = {Overview of {Mass Entity} in {Unreal Engine}}, + year = {2022}, + note = {View at \url{https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-mass-entity-in-unreal-engine?application_version=5.0}} +} + +@misc{GoogleTest, + author = {{Google}}, + howpublished = {\url{https://github.com/google/googletest/}}, + title = {{GoogleTest | Google C++ Testing Framework}}, + year = {2010} +} + +@article{Software_Performance_Evolution, + author = {Christian Kaltenecker and Stefan Mühlbauer and Alexander Grebhahn and Norbert Siegmund and Sven Apel}, + journal = {Empirical Software Engineering}, + title = {Performance evolution of configurable software systems: an empirical study}, + volume = {28}, + number = {152}, + year = {2023}, + doi = {10.1007/s10664-023-10338-3}, +} + +@inproceedings{Software_Bloat_Analysis, + author = {Guoqing Xu and Nick Mitchell and Matthew Arnold and Atanas Rountev and Gary Sevitsky}, + booktitle = {FoSER '10: Proceedings of the FSE/SDP workshop on Future of software engineering research}, + title = {Software Bloat Analysis: Finding, Removing, and Preventing Performance Problems in Modern Large-Scale Object-Oriented Applications}, + year = {2010}, + doi = {10.1145/1882362.1882448}, +} + +@misc{Game_Engine_Efficiency, + author = {Thomas Brogan}, + howpublished = {Master's thesis (Purdue University)}, + title = {Evaluating the efficiency of general purpose and specialized game engines for {2D} games}, + year = {2024}, + month = {May}, + pages = {37}, + doi = {10.25394/PGS.25674288}, +} + +@techreport{SIG_Benchmark_2023, + author = {{Software Improvement Group}}, + title = {2023 Benchmark Report | The State of Software Quality, {AI}, and Security}, + institution = {Software Improvement Group}, + year = {2023}, + note = {View at \url{https://www.softwareimprovementgroup.com/wp-content/uploads/2023-SIG-Benchmark-Report.pdf}} +} + +@misc{Godot_Engine, + author = {{Godot Foundation}}, + howpublished = {Software}, + title = {{Godot} Engine - Free and open source {2D} and {3D} game engine}, + year = {2014}, + note = {Available at \url{https://godotengine.org/}} +} + +@misc{CreativeCommonsLicense, + author = {{Creative Commons}}, + title = {{Creative Commons Attribution 4.0 International Public License (CC BY 4.0)}}, + year = {2013}, + note = {\url{https://creativecommons.org/}} +} + +@misc{MIT0License, + author = {{Open Source Initiative}}, + title = {{MIT No Attribution License (MIT-0)}}, + year = {2020}, + note = {\url{https://opensource.org/license/mit-0}} +} + +@misc{Gotta_Go_Fast, + author = {Taeho Kang and Christian Wallraven}, + title = {Gotta Go Fast: Measuring Input/Output Latencies of Virtual Reality {3D} Engines for Cognitive Experiments}, + year = {2023}, + note = {View at \url{https://arxiv.org/abs/2306.02637}} +} + +@inproceedings{Playing_With_Delay, + author = {Ragnhild Eg and Kjetil Raaen and Mark Claypool}, + booktitle = {2018 Tenth International Conference on Quality of Multimedia Experience (QoMEX)}, + title = {Playing with Delay: With Poor Timing Comes Poor Performance, and Experience Follows Suit}, + year = {2018}, + doi = {10.1109/QoMEX.2018.8463382}, +} + +@article{Latency_And_Perspective, + author = {David Halbhuber and Philipp Schauhuber and Valentin Schwind and Niels Henze}, + title = {The Effects of Latency and In-Game Perspective on Player Performance and Game Experience}, + journal = {Proceedings of the ACM on Human-Computer Interaction 7 (CHI PLAY)}, + year = {2023}, + pages = {1308-1329}, + note = {View at \url{https://dl.acm.org/doi/10.1145/3611070}} +} + +@inproceedings{Lower_Better, + author = {Shengmei Liu and Mark Claypool and Atsuo Kuwahara and Jamie Sherman and James Scovell}, + booktitle = {CHI '21: CHI Conference on Human Factors in Computing Systems}, + title = {Lower is Better? The Effects of Local Latencies on Competitive First-Person Shooter Game Players}, + year = {2021}, + doi = {10.1145/3411764.3445245}, +} + +@inproceedings{interactive_media_learning, + author = {Aulia, Hartika and Hafeez, Muhammad and Mashwani, Hazrat and Careemdeen, Jalal and Mirzapour, Maryam and Syaharuddin}, + booktitle = {International Seminar on Student Research in Education, Science, and Technology}, + year = {2024}, + title = {The Role of Interactive Learning Media in Enhancing Student Engagement and Academic Achievement} +} + +@article{interactive_media_medical, + author = {Masnah, Cek and Suharti, Atik and Daryono, Daryono}, + year = {2023}, + month = {January}, + pages = {359-366}, + title = {The Effectiveness of Interactive Media in Improving Compliance with Medication for Hypertension Patients}, + volume = {8}, + journal = {Jurnal Aisyah : Jurnal Ilmu Kesehatan}, + doi = {10.30604/jika.v8i1.1516} +} + +@article{VR_Rehab, + author = {Joon-Ho Shin, Hokyoung Ryu, Seong Ho Jang}, + year = {2014}, + month = {March}, + title = {A task-specific interactive game-based virtual reality rehabilitation system for patients with stroke: a usability test and two clinical experiments}, + volume = {11}, + number = {32}, + journal = {Journal of NeuroEngineering and Rehabilitation} +} + +@misc{miniaudio, + author = {David Reid}, + title = {{miniaudio} - A single file audio playback and capture library for {C} and {C++}}, + howpublished = {Software library (GitHub)}, + year = {2025}, + note = {Available at \url{https://github.com/mackron/miniaudio}} +} + +@misc{DOTS_Study, + author = {Ylikoski, Juuso}, + year = {2025}, + howpublished = {Master's thesis (Lappeenranta-Lahti University of Technology LUT)}, + title = {Transferring game mechanics to Unity {DOTS} and {ECS} after release}, + note = {View at \url{https://lutpub.lut.fi/handle/10024/169074}} +} + +@misc{MassSample, + author = {Karl Mavko, Alvaro Jover}, + howpublished = {GitHub repository}, + title = {{Community Mass Sample}}, + year = {2022}, + note = {\url{https://github.com/Megafunk/MassSample}} +} \ No newline at end of file diff --git a/papers/final_report/sections/abstract.tex b/papers/final_report/sections/abstract.tex new file mode 100644 index 00000000..bfb2538a --- /dev/null +++ b/papers/final_report/sections/abstract.tex @@ -0,0 +1,19 @@ +\begin{adjustwidth}{0.5cm}{0.5cm} + \section*{\normalsize Abstract} + \vspace{-0.3cm} + \normalsize + This project addresses the lack of a versatile and high-performance general purpose interactive media + creation framework, which is important due to the prevalence of interactive media in academic and medical contexts. + The objectives of this project are to analyze the limitations of existing game engine architectures, particularly + in their usage of creating general purpose interactive media, as well as to explore alternative paradigms and + finally develop a framework that can streamline its creation with minimal development costs and maintaining high + performance and usability across various domains. + To achieve these objectives, the proposed solution involves an operating-system-like game engine, integrating + the Entity-Component-Structure framework with operating systems concepts, while utilizing aggressive C++ compile-time + optimization to increase performance. + \\\\ + The analysis and design process involves C++20, DirectX 11, and Windows API. GoogleTest is used for evaluation. + The outcomes are a deliverable prototype and a system documentation, + which we hope to provide industrial benefits for future creations of high-performance interactive media. + +\end{adjustwidth} \ No newline at end of file diff --git a/papers/final_report/sections/coding_standard.tex b/papers/final_report/sections/coding_standard.tex new file mode 100644 index 00000000..58b3784c --- /dev/null +++ b/papers/final_report/sections/coding_standard.tex @@ -0,0 +1,94 @@ +\refstepcounter{section} +\section*{Appendix \thesection \, \textbar \vspace{0.5em} Coding Standard} +\label{sec:appendix-coding-standard} +\addcontentsline{toc}{section}{Appendix \thesection. Coding Standard} + +All source code in this project follows a consistent formatting style defined by a custom Clang-Format configuration. +The configuration is based on the LLVM coding style, with modifications for improved readability, clearer brace structure, and consistent indentation across the codebase. +\subsubsection*{1. Base Style} +\begin{itemize} +\item +The formatting standard is derived from the LLVM style guide, chosen for its balance between compactness and readability. +\item +The configuration file is provided as .clang-format in the project root directory and automatically enforced via build or commit hooks. +\end{itemize} +\subsubsection*{2. General Formatting} +\begin{itemize} + \item + Indentation: 4 spaces per level; tab width is also 4 spaces. Tabs are never used for indentation. + \item + Column limit: 120 characters per line to preserve readability on modern displays. + \item + Namespace indentation: All namespaces are indented to clearly scope internal structures. + \item + Access modifiers: public, protected, and private are indented for better visual separation from member declarations. +\end{itemize} +\subsubsection*{3. Brace and Block Rules} +\begin{itemize} + \item + Braces follow a custom “always break” style, placing braces on a new line for classes, structs, enums, functions, and control statements. + \item + Empty braces (e.g., {}) are never split across lines. + \item + if, else, catch, while, and lambda bodies always begin on a new line to emphasize logical structure and reduce ambiguity. +\end{itemize} +\subsubsection*{4. Alignment and Spacing} +\begin{itemize} + \item + Alignments: Operands, braces, and trailing comments are aligned to maintain vertical clarity. + \item + Assignments and declarations are not force-aligned to avoid inconsistent whitespace when editing. + \item + Spacing: + \begin{itemize} + \item + No extra spaces inside parentheses or template angle brackets. + \item + One space after C-style casts (e.g., (int) x). + \item + No spaces before range-based for loop colons or conditional parentheses. +\end{itemize} +\end{itemize} +\subsubsection*{5. Line Breaking} +\begin{itemize} + \item + Function and template declarations break long parameter lists and template definitions across lines for readability. + \item + Constructor initializers are aligned vertically and placed one per line when multiple exist. + \item + Arguments and parameters are never bin-packed — each remains on its own line when wrapping occurs. +\end{itemize} +\subsubsection*{6. Includes and Imports} +\begin{itemize} + \item + Include order is automatically sorted into three priority groups: + \begin{enumerate} + \item + System headers (\textless\ldots\textgreater) + \item + Local headers (\textquotedblleft\ldots\textquotedblright) + \item + Other includes (project-specific or third-party) + \end{enumerate} + \item + Include sorting ensures deterministic builds and improves merge conflict resolution. +\end{itemize} +\subsubsection*{7. Empty Lines and File End} +\begin{itemize} + \item + No more than two consecutive empty lines are kept. + \item + A newline is automatically inserted at the end of each file. + \item + Preprocessor directives are indented before the hash symbol to match surrounding indentation levels. + \end{itemize} + \subsubsection*{8. Code Style Philosophy} + This formatting standard prioritizes: + \begin{itemize} + \item + Readability — through consistent brace placement and indentation. + \item + Maintainability — by avoiding complex line packing and ensuring clear code structure. + \item + Cross-platform consistency — the same formatting rules apply to all C and C++ source files regardless of platform or compiler. +\end{itemize} \ No newline at end of file diff --git a/papers/final_report/sections/conclusion.tex b/papers/final_report/sections/conclusion.tex new file mode 100644 index 00000000..34041162 --- /dev/null +++ b/papers/final_report/sections/conclusion.tex @@ -0,0 +1,23 @@ +\section{Conclusion and Future Work} +\label{sec:conclusion-and-future-work} + +In this project, we addressed the limitations of existing game engines when used for general purpose interactive media +and established issues with performance, scalability, and maintainability in such use cases. +Upon analysis, we explored alternative approaches and developed a custom engine built upon the ECS framework with an +emphasis on reducing abstraction and overhead, while still providing a flexible and scalable foundation for interactive +media development. +As an evaluation of the engine's efficiency in real-world conditions, we developed a bullet hell game and rhythm game +hybrid system with real-time input handling, precise timing, and large numbers of objects. +We also benchmark the engine's core logic processing in comparison to existing ECS libraries to evaluate the difference +in performance with industry standards. +The results show potential in the use of this engine for effective and maintainable interactive media development, as well +as being sufficiently versatile across different domains of such media. + +Future work may involve expanding the engine's ECS logic to encompass more common ECS programming paradigms, such as +more powerful query support and query iteration across the ECS resources directly from the system. +The engine itself can also serve as the foundation for more extensive research towards ECS optimization techniques. +One such technique is the compile-time determination of multithreaded system execution order via the creation of +a system dependency graph, which will greatly increase performance when multiple systems are concerned. +The game developed as the case study will be continually improved upon and be launched as a full game in the future. + +\label{tag:end} \ No newline at end of file diff --git a/papers/final_report/sections/design.tex b/papers/final_report/sections/design.tex new file mode 100644 index 00000000..52a8461c --- /dev/null +++ b/papers/final_report/sections/design.tex @@ -0,0 +1,215 @@ +\section{System Design} +\label{sec:system-design} + +\subsection{System Architecture} +\label{subsec:system-architecture} + +\subsubsection*{Engine Design} + +The project's core engine design, as stated before, will use an ECS framework that registers and +determines components and system dependencies at compile-time. +The declaration of a single ECS instance that registers all components and systems would result in +wasteful usage of memory and projected performance decreases due to the large variety of components involved. +As such, we have opted to use multiple smaller ECS instances that each take control of a smaller part of the game. +We refer to these smaller ECS instances, alongside the data necessary to register related components and systems, +as well as compute and store initial data into those instances, as scenes. +Communications between scenes, such as the data transfer when creating a new scene, are facilitated through +a SceneManager, which will also execute the registered systems during the main game loop. + +\vspace{0.5cm} + +\noindent +\begin{minipage}{\columnwidth} + \centering + \includegraphics[width=\columnwidth, keepaspectratio]{images/engine} + \captionof{figure}{A diagram showing data flow of the engine prototype} + \label{fig:engine} +\end{minipage} + +\vspace{0.5cm} + +\noindent Figure~\ref{fig:engine} shows the outline of the engine. +The Scene Manager takes ownership and executes user-level systems during runtime by receiving inputs from the operating system, +passing logs, audio, and render-object references to different specialized components. +The components will then pass information to the operating system, and continues to the device outputs as appropriate. +For modularity, the communications are passed through the Windows/Lifetime Manager, which acts as an adapter for the operating system. +\\\\ +For the actual implementation of these compile-time optimizations, we take advantage of C++'s concept of templates. +By using component and system data types as template parameters, we can use template specialization to let +the compiler generate code specific to our use case. +Since each system is a function, this also means we get usage of functions without relying on indirect calls, +which is a common pain point in engine design. +\\\\ +The benefits of template specialization can be seen with a key part of the ECS instance, the resource manager. +The resource manager manages entities along with any components attached to those entities, together referred to as resources. +The resource manager takes a size integer and any number of structures as template parameters and treats those +structures as registered components in this instance. +It will create a resource pool of each registered component with the specified size when constructed, each of +which will reserve their own memory depending on the component's size and the pool size. +By accessing these components through template specialization, code is generated such that the abstraction layers +are removed from the code when compiled. +\\\\ +While systems are being run, entities with select component archetypes are iterated upon. +If components are added or removed during iteration, this may invalidate references or otherwise cause unpredictable behavior. +To avoid such hazards, a structure must be created with the purpose to defer all attempts to add or remove components +and to apply such changes after all systems complete execution. +Borrowing the term from operating systems, we refer to this structure with elevated permissions to modify resources +as the syscall. +The syscall must know the components registered to its coupled resource manager so that it can add the appropriate +components. +When systems want to add or remove components from an entity, they make the request to the ECS instance, which +will schedule the changes in its internal syscall. +\\\\ +Systems operate upon entities based on whether they fulfill certain component requirements. +For complex systems, the requirements can be rather complex, and entities may be retrieved multiple times +under different requirements. +Some implementations have the ECS instance be provided as a function argument to each system so that entities +can be retrieved directly from internal resources via templated retrieval functions. +We decided, instead, that systems define query data structures as function arguments, which describes the components +that entity references stored within are guaranteed to possess. +When the system is run, the ECS instance will internally fulfill each query requirement by fetching and filtering +from the resource manager before passing them to the system. +This way, the system's implementation does not concern itself with fetching data from the ECS instance. + +\subsubsection*{Game Design} + +The project's core game design will involve combining rhythm games and bullet hell games into a hybrid game +structured around distinct but smoothly transitioning phases. +This requires a seamless transition between the two to create a revolutionary take on hybrid games. +Considering that both of the games hugely relied on great optimization, a little disruption can cause a fatal mistake for +the player inciting frustration. +The design of the game must therefore be made cautiously. +\\\\ +\noindent The bullet hell section is mostly composed of large numbers of bullets and particles, +while great performance is still required to retain the player’s fluidity of movement. +ECS architecture is highly favored as opposed to object-oriented programming since the +large number of entities can be handled more efficiently. +Entities of the system are composed of player, bullets, boss, enemies, background, and effects +using shared components such as position, velocity, sprite, and shader. +Each system must be executed every frame to handle entity movement, +collision check, and player input, allowing it to handle every bullet in a frame efficiently. + +\vspace{0.5cm} + +\noindent +\begin{minipage}{\columnwidth} + \centering + \includegraphics[width=\columnwidth, keepaspectratio]{images/designbullet} + \captionof{figure}{Preliminary system design for the bullet hell gameplay section} + \label{fig:designbullet} +\end{minipage} + +\vspace{0.5cm} + +\noindent Figure~\ref{fig:designbullet} shows the current system design for bullet hell gameplay. +A bullet loader entity is initialized during the initiation process of the scene alongside all bullet data used within the scene. +The bullet loader system then spawn bullets from the data stored in its component at the configured frame timing. +Each spawned bullet data entry contains a stage bullet ID used to retrieve additional information from the stage bullet registry. +This registry also references a graphic ID to query even more data from the bullet graphic registry. +After all required data is gathered, the bullet entity is spawned with its components configured from the gathered data. +\\\\ +The core mechanics are that, for each frame, the input was processed to control the player system. +Meanwhile, the collision system will check each ongoing colliding entity by computing if each entity with a collider component +is colliding with another entity. +Then, the corresponding function will be triggered to apply change to the state such as the player taking damage. +Moreover, the movement system computes the next frame position to render, and the animation system will update the animation frame of the sprite to be rendered. +\\\\ +On the other hand, rhythm games require precise timing to catch the notes at the right time, +so very few optimization issues can be tolerated as a result. +However, ECS architecture is powerful enough to handle all the requirements +such as a large quantity of notes and an accurate time tracking device centralized by the clock system. + +\vspace{0.5cm} + +\noindent +\begin{minipage}{\columnwidth} + \centering + \includegraphics[width=\columnwidth, keepaspectratio]{images/designrhythm} + \captionof{figure}{Preliminary system design of the rhythm game gameplay section} + \label{fig:designrhythm} +\end{minipage} + +\vspace{0.5cm} + +\noindent Figure~\ref{fig:designrhythm} shows the current system design for rhythm game section. +When the game scene is initiated, a chart entity containing the note data is retrieved. +Each note data entry contains a note type, timing, and lane information. +Then, the note loading system will create note entities with each one being in one of the four lanes. +Unlike the bullet hell section, the notes can be loaded all at once since its initial position is determined by the lane. +After all the notes are created, the scene will be running and the systems will be executed every frame to update the note position and check for player input. +\\\\ +The core mechanic revolves around spawning the notes at the right time and calculating the position of the sprite as it moves. +However, the real logic of the note is being computed by its own system depending on its type, such as tap note and hold note. +Once the note reaches its timing range, the system will check the timing of the player's input and +display the corresponding accuracy known as judgment. +\\\\ +Transitioning between both types of gameplay proves to be a great challenge design-wise, as it has to be +smooth and seamless enough to not disrupt the precision-hungry gameplay of both games. +To ensure a smooth gameplay experience, only one game scene is rendered to minimize time to transition +as the whole scene will be loaded and initiated only once from the start. +If the transition is happening, the gameplay should be frozen and any progress should not be considered during the process, +allowing the player to get ready to adjust their gameplay smoothly. +Also, the transition's animation has to telegraph the player clearly to make them aware that the gameplay is going to be changed +by including a countdown to inform the duration of the transition. +% Lastly, the screen changing the gameplay rendered has to be creative and visually appealing to not make the transition jarring or out of place. +% % To achieve this, a line animation system is used to express animation of the transition, and the game transition system +% % will be triggered if the state has been changed. +% One of the proposed transitions is a line animation that starts from the center of the screen and expands until it covers the whole screen. +% Following this, the new gameplay is rendered for a section of the screen expanding until full. +\\\\ +The biggest concern of the game logic is the control of the rhythm game's charts and bullet hell's patterns +needing to not be exhaustingly difficult to control, as both games require vast amounts of complicated pattern and timing design. +A solution proposed was to create our own scripting language and a corresponding compiler. +This allows game developers to create levels in a file format that is easy to read and write, +while the compiler can convert it into a format that can be processed by the game engine. +Practicing these techniques makes designing and implementing charts and patterns easier, +allowing more complex and challenging designs and features. +\\\\ +% To complete a game, a narrative device should be implemented to make the game more immersive and enjoyable; +% the proposed gameplay would be a 2D side-scrolling style that allows players to choose a level and progress the story of the game. +% Additionally, explorations are added to the game such as interacting with interactable entities such as NPC, or objects, +% getting new in-game items, and accessing new areas. +% Such requirements must be implemented with an entirely separate game logic. +% Interactable and solid collision components are needed to be implemented along with the new system, +% for example, a new movement system, interact system, and area load system. +% \\\\ +Lastly, using ECS, UI entities are being rendered concurrently in a higher priority by default. +The entities will have a position, text, sprite, and animation components and are created orderly using functions for each set of UIs. +For audios in the game, including sound effects and music, each is assigned to its own entity with a tag or trigger to be played on an instance sound system. +\\\\ +In the future, we plan to add a narrative device to make the game more immersive and enjoyable; +the proposed gameplay would be a 2D side-scrolling style that allows players to choose a level and progress the story, +with the ability to interact with NPCs and objects, and access new areas. + +\subsection{Components} +\label{subsec:components} + +The system is a self-contained application, but interfacing with a keyboard and mouse is required for its operation. +DirectX 11 is used for the rendering of the game with the use of a custom rendering pipeline implementation. +User input is collected through the Windows API\@. + +\subsection{Design Considerations} +\label{subsec:design-considerations} + +% Performance, scalability, usability, sustainability, environment +We formed the design with considerations of usability at the forefront. +The interface was to allow user-level system design to be as close to natural C++ functional design as possible, +while still retaining the power of ECS systems. +We also ensured the design allowed for aggressive compiler optimization and inlining by avoiding virtual function calls, +abstractions with hidden costs or overhead, and pointer arithmetic whose behaviors are challenging to predict. +The architecture was highly modular with little coupling to allow for incremental additions to the engine during the +implementation process and in future works. + +\subsection{Proposed vs. Final Design} +\label{subsec:proposed-vs-final} + +The proposed engine design did not undergo major changes in the implementation process. +As the design is modular, as the engine's execution is optimized, modules that serve the same purpose were being swapped out +with more efficient ones that serve the same function. +\\\\ +Meanwhile, some gameplay systems were adjusted to increase the maintainability of the code in future development. +The bullet hell system architecture was mostly restructured using bullet registry to handle the large variety of bullet +patterns and graphics, allowing the bullet loader system to be more generalized. +The rhythm game system was also refactored to accommodate different note types and hit detection logic, allowing for more flexible +and implementable features. + diff --git a/papers/final_report/sections/document_standard.tex b/papers/final_report/sections/document_standard.tex new file mode 100644 index 00000000..ae5d3dcd --- /dev/null +++ b/papers/final_report/sections/document_standard.tex @@ -0,0 +1,55 @@ +\refstepcounter{section} +\section*{Appendix \thesection \, \textbar \vspace{0.5em} Document Standard} +\label{sec:appendix-document-standard} +\addcontentsline{toc}{section}{Appendix \thesection. Document Standard} + +This document is typeset in LaTeX using a custom standard designed for clarity, consistency, and professional presentation. The format emphasizes readability in both digital and printed form while supporting structured technical writing. The main standards are as follows: +\subsection*{1. Document Class and Layout} +The proposal is based on the article class with a 10-point font size on A4 paper. Page margins are set to 1 inch on all sides for balanced spacing and printing compatibility. +\subsection*{2. Typography and Sectioning} +The document uses normal-sized body text with bold section and subsection titles. Each section title is prefixed by its number and separated by a vertical bar for clear visual hierarchy (e.g., “2 | System Design”). +The layout alternates between single-column and two-column formats depending on content density — technical sections such as \textit{Design} and \textit{Ethics} are two-column for compactness, while detailed tables and timelines are presented in single-column layout for readability. +\subsection*{3. Headers and Footers} +All pages include a footer containing the department name and university on the left and the page number on the right. A thin horizontal rule separates the footer from the main text. Page numbering is shown in the format “\textit{current of total}” after the table of contents. +\subsection*{4. Captions and Figures} +Figure and table captions use small italic text with bold labels, followed by a period separator (e.g., “Figure 3. System Architecture”). Captions are centered and consistently formatted to maintain visual balance across columns. +\subection*{5. Tables and Column Types} +The tabularx package is used to create flexible tables that automatically adjust to the page width. Three custom column types are defined: +\begin{itemize} + \item + L for left-aligned text + \item + R for right-aligned text + \item + Y for centered text + The line spacing inside tables is slightly increased (1.75×) for better readability in printed form. + \end{itemize} +\subsection*{6. Page Style and Numbering} +Preliminary pages (title, abstract, and table of contents) use Roman numerals, while the main content uses Arabic numerals. Appendix pages are labeled alphabetically (A, B, C, etc.). Headers are omitted to maintain a clean layout. +\subsection*{7. Table of Contents and Structure} +The table of contents lists all major sections, references, and appendices. Each section and subsection is clearly numbered for easy navigation. +\subsection*{8. References} +References are formatted using the IEEE Transactions style (ieeetr), which is standard for engineering and computer science research. The bibliography section is automatically generated and included in the table of contents. +\subsection*{9. Appendices} +Appendices are styled consistently with the main document but relabeled alphabetically (e.g., “Appendix A | List of Figures”). Lists of figures and tables are customized to display caption titles only for compactness. Additional appendices may include feasibility analysis, code of conduct, and other supplementary materials. +\item +\subsection*{10. Compilation and Packages} +The document uses standard LaTeX packages for layout and styling, including: +\begin{itemize} + \item + geometry for margin control + \item + fancyhdr for footer customization + \item + titlesec for section formatting + \item + multicol for multi-column layout + \item + graphicx for image inclusion + \item + tabularx and array for table management + \item + hyperref for internal linking and references + \end{itemize} + +This formatting standard is chosen to ensure that the proposal is visually organized, technically clear, and easily extensible for later reports such as the progress and final project documentation. \ No newline at end of file diff --git a/papers/final_report/sections/ethics.tex b/papers/final_report/sections/ethics.tex new file mode 100644 index 00000000..1a6c6a12 --- /dev/null +++ b/papers/final_report/sections/ethics.tex @@ -0,0 +1,47 @@ +\section{Ethic, Privacy, and Professional Consideration} +\label{sec:ethic-privacy-and-professional-consideration} + +\subsection{Ethical Issues} +\label{subsec:ethical-issues} + +The project's system was developed from the ground up with lightweight and open-source libraries such as DDS and miniaudio for asset processing. +Due to its minimal model, data privacy for users is secured and well encapsulated within the application. +Additionally, this project utilizes aggressive compile-time optimizations to maintain high-performance on par with +the industry standard. +Thus, allowing the framework to run efficiently across varying hardware specifications, eliminating most hardware entry barriers. +System safety and reliability are ensured through a well-customized memory management system and modular architecture +along with system testing to reduce unexpected behavior. + + +\subsection{Standards \& Laws} +\label{subsec:standards-&-laws} + +The project mostly references the verified official documentation, including DirectX and Microsoft C++ documentation, +as well as credible research and articles on engine architecture and game design theory. +All development and design are supported by reliable and recognized sources in software engineering +and game development literature, ensuring grounded and reliable information. +Additionally, the project complies with the licensing agreements for all other third-party open-source libraries +used for audio and rendering to ensure legal reliability. + +\subsection{Environmental Impact} +\label{subsec:environmental-impact} +The project provides lightweight architecture and performance-oriented system design +to reduce unnecessary computational overhead and resource consumption. +Furthermore, the framework runs efficiently across varying hardware specifications, which may potentially +reduce hardware upgrade requirements, expending the lifespan of the user's existing hardware. + + +\subsection{Intellectual Property} +\label{subsec:intellectual-property} + +All codes, tools and assets created during the project are original works owned by the team. +DirectX and Microsoft's Windows APIs used in this project are free to use without any attribution so long as there is +no binary tampering or falsely acclaimed trademark usage. +The project uses miniaudio~\cite{miniaudio} for audio processing, which is licensed under Public Domain and MIT No Attribution, +allowing for free use, modification, and distribution without attribution or licensing fees~\cite{MIT0License}. +All visual and audio assets are self-produced. +The project complies with software licensing terms and university policies regarding intellectual property and academic integrity. +This project is licensed under the MIT License, protected under Thai Copyright Act B.E.2537. +The project's engine is licensed under CC BY-NC 4.0 as the team allows users to distribute, remix, adapt, and build upon +the material in any medium or format for research or noncommercial purposes only, +and only so long as attribution is given to the creator~\cite{CreativeCommonsLicense}. \ No newline at end of file diff --git a/papers/final_report/sections/feasibility.tex b/papers/final_report/sections/feasibility.tex new file mode 100644 index 00000000..9b904980 --- /dev/null +++ b/papers/final_report/sections/feasibility.tex @@ -0,0 +1,36 @@ +\refstepcounter{section} +\section*{Appendix \thesection \, \textbar \vspace{0.5em} Feasibility Analysis} +\label{sec:appendix-feasibility} +\addcontentsline{toc}{section}{Appendix \thesection. Feasibility Analysis}% + +\subsection*{1. Technical Feasibility} +Each member of our team has skills and knowledge that are required in different areas of the project. +This includes C++ programming, system architecture design, game design, graphics programming, and team management. +This team structure ensures that all aspects of the project are covered by knowledgeable individuals. +The project utilizes C++20, DirectX 11, and Windows API, which are well-documented and widely used technologies, with no other third-party libraries required. +Using official libraries ensures compatibility and stability for our target platform, Windows. +Additionally, using GoogleTest for unit testing allows us to maintain system reliability and detect unexpected bugs throughout the development process. + +\subsection*{2. Schedule Feasibility} +Our development process will follow an agile development methodology. +The project is broken down into manageable tasks assigned to team members based on their expertise. +Our team also plans to hold weekly meetings to discuss progress, address problems, and adjust plans as necessary. +In addition, following the agile methodology, each member is not locked to a single duty and can take multiple responsibilities depending on the current needs of the project. +This flexibility ensures that the project can adapt to changing requirements and challenges with no significant delays. +Upon consideration of estimated workloads, the timeline appears achievable and is expected to be met within the second semester. + +\subsection*{3. Organizational Feasibility} +The project aims to provide tools and resources to help users create interactive media efficiently. +This aligns with the goals of our academic institution, which emphasizes practical and beneficial applications of technology in the industry. +Moreover, ECS architecture is not only limited to game development but can be adapted in other fields of interactive media and more. +Here are some examples: +\begin{itemize} + \item Animation\\ + ECS can easily manage media elements such as characters, props, and effects, allowing a convenient process of animating and modifying elements. + \item Dynamic UI\\ + ECS can support dynamic user interface in applications with various buttons, sliders, panels, and other elements that can have multiple properties. + \item Simulation\\ + Due to its performance and modularity, ECS is beneficial to accurate and realistic behaviors in media simulations. + \item Real-Time Data Visualization\\ + Apart from managing data visuals, ECS can also be used for handling live data with constant updates. +\end{itemize} \ No newline at end of file diff --git a/papers/final_report/sections/implementation.tex b/papers/final_report/sections/implementation.tex new file mode 100644 index 00000000..1bc58e3a --- /dev/null +++ b/papers/final_report/sections/implementation.tex @@ -0,0 +1,101 @@ +\section{Implementation} +\label{sec:implementation} + +\subsection{Development Process} +\label{subsec:development-process} + +% Engine side +\subsubsection*{Engine Development} + +For the first stages of development, the core functionality of the ECS framework was to be implemented fully. +While the engine's implementation is being worked on, the main game loop and scene change system was established. +After the ECS framework performed to an acceptable level, the focus shifted to providing utilities +needed for game development. +Among these were a way to integrate assets, a way to output draw commands, and a way to inject inputs and timestamps for +time-sensitive functions. +\\\\ +One important feature was the ability to switch between ECS registries, which resulted in the development of the Scene Manager. +Finally, while the game is in development fully, the system designers helped support the game developers and address +issues and performance degradation by continuously iterating upon the engine implementation and optimizing for performance. + +\subsubsection*{Game Development} + +In the first stage of development, the game developers were tasked with creating a concept and design of the game +while waiting for the core functionality of the engine and ECS system. +The game combines bullet hell gameplay with rhythm gameplay to demonstrate the engine's high performance. +Due to the multi-genre gameplay design, mechanics and systems must be designed for the ECS framework and able to +blend both gameplay styles while preserving the player's experience. +Furthermore, art, music, and story design were planned during this phase. +\\\\ +After the ECS framework was completed, gameplay systems were implemented and tested in parallel to the integration +of the renderer. +Scenes were split into a bullet-hell scene and a rhythm game scene to separate into their own environment before +merging into one scene. +Meanwhile, assets were being designed and created for the game, including characters, background art, and music. +\\\\ +After the rendering system was implemented, visuals were added to the gameplay systems, allowing them to be polished and +tested for performance. +Finished assets such as character sprites and background art were integrated into the game. +Lastly, a game demo was created for the project demonstration, including a main menu scene, gameplay transition, and a playable level. + + +\subsection{Implementation Detail} +\label{subsec:implementation-detail} + +% Implementation Detail + Tools + Challenge + +\subsubsection*{ECS Engine} +The custom engine was implemented with the C++20 standard and tested for correctness with GoogleTest~\cite{GoogleTest}. +\\\\ +As the designers were not familiar with the ECS architecture, it took many months to finalize the design. +In the beginning, the engine built the ECS architecture upon an object-oriented C++ class structure, but this was deemed +antithesis to the reason ECS was chosen for the engine in the first place. +The system designers then iterated upon this by replacing inheritance-based classes and functions with templates +and concept metaprogramming. +The compiler handled the template specialization, resulting in performance close to programming with no framework. +\\\\ +A challenge that later arose was the providing of entities matching querying components to registered functions. +For every registered function, heavy metaprogramming had to be used to match the function's arguments to component types, +then to filter existing entities based on those types, and after that to provide them as reference lists to the functions. +To expedite the process, a special query class was provided for use in transferring entity references to systems. +The class contained C++ reference wrappers and convenience functions to iterate upon entities as if upon simple vectors, +reducing mental overhead when implementing game logic. + +\subsubsection*{Scene Manager} +The Scene Manager is an extension of the ECS engine for use with multi-world ECS logic. +Each scene was a class implemented with functions to initialize and cleanup their own ECS manager object, each with +differently registered components and systems. +The Scene Manager used these scenes through template functions to seamlessly switch between different parts of the game, +allowing for easy logic separation and data passing. +\\\\ +One challenge encountered when implementing the Scene Manager was the shape of the data between scenes. +While the data emitted from each scene could vary based on their registered components, a scene could only +accept data that's compatible with their own registered component. +This challenge was partially alleviated by implementing a templated function that converts data in-transit, but +care must still be given to prevent loss of important data and invalid states of gameplay. + +\subsubsection*{Game System} +The gameplay development was implemented using the custom ECS framework provided by the engine team utilizing +C++20, the custom engine APIs, and GoogleTest. +\\\\ +At first, the gameplay systems for both genres were implemented according to the initial design with ECS paradigm. +Entities such as bullets and notes were defined with components that contained data relevant to their purpose, +and systems were defined as functions that operated on a query of entities with specific components. +Utilizing the new and unfamiliar custom engine was a major challenge for the game developers, as they had to understand +the engine's architecture and APIs while implementing the gameplay systems. +Because the rendering system was not implemented at the time, debugging tools such as logging and test cases were used +to verify the correctness of their systems. +As the game development progressed, the game developers had to be aware of the engine's performance and optimize their +systems to ensure smooth gameplay. +This lead to some systems being restructured to be more efficient, such as using a bullet registry to manage bullet patterns +and graphics. +\\\\ +Another challenge involved integrating two different gameplay genres while maintaining responsive player controls and gameplay +readability. +To mitigate the issue, the game development process spent a considerable amount of time refining methods to smoothly transition +the gameplay. +This included designing visual cues to signal the transition and transitioning the gameplay without interrupting the player's flow. +After the transition was implemented, it was tested to ensure the smoothness of the transition and the player's experience +was not disrupted. + + diff --git a/papers/final_report/sections/introduction.tex b/papers/final_report/sections/introduction.tex new file mode 100644 index 00000000..5eb16d3c --- /dev/null +++ b/papers/final_report/sections/introduction.tex @@ -0,0 +1,73 @@ +\section{Introduction} +\label{sec:introduction} + +\subsection{Background \& Motivation} +\label{subsec:background-and-motivation} + +In recent years, interactive media has become increasingly more integrated into modern society. +It has appeared within games, applications, and Virtual Reality (VR) with usage covering +many fields, including within academic~\cite{interactive_media_learning} and medical contexts~\cite{interactive_media_medical}~\cite{VR_Rehab}. +As such media continues to develop in scale and complexity, its performance demands have intensified. +The growth in hardware performance is not enough to keep up with this demand, creating a challenge for +creators and system designers alike. +\\\\ +Current interactive media is usually created by relying on game engines, such as Unity, Godot, and Unreal Engine, +as a software framework. +However, these game engines were originally designed for game development and were not built for the more +general applications. +This mismatch motivates the need to create such a system that is built optimally for these new demands, +while remaining highly optimized in terms of performance for various tasks. + +\subsection{Problem Statement} +\label{subsec:problem-statement} + +Existing game engines are not suitable for the creation of general-purpose interactive media. +Their architecture uses the traditional object-oriented programming (OOP) paradigm, which introduces +certain constraints and limitations on flexibility, scalability, and performance outside game contexts. +\\\\ +In response, many companies have resorted to developing proprietary systems from scratch to meet their specific requirements. +This practice, however, leads to delays in development while accruing unnecessary costs. +The problem, therefore, is that there lacks a sufficiently versatile and high-performance framework that can +efficiently support the development of general-purpose interactive media. + +\subsection{Objectives} +\label{subsec:objectives} + +\begin{enumerate} + \item To analyze the limitations of existing game engine architectures, particularly in relation to general-purpose interactive applications. + \item To explore alternative architectural paradigms that could offer improved performance and flexibility over conventional OOP-based designs. + \item To propose and develop a framework that can streamline the creation of interactive media while reducing development costs and maintaining high performance. + \item To evaluate the proposed framework through game development as a case study to demonstrate its effectiveness in real-world scenarios. +\end{enumerate} + +\subsection{Scope \& Limitations} +\label{subsec:scope-and-limitation} +This project is intended to develop high-precision software for creation of interactive media, which can receive user inputs and respond accordingly. +In order to achieve this goal, we need to have control on our system as much as possible. +That means everything on this system will rely on the Operating System's library and +C++ standard library (STL) function that is proven to be zero-cost abstractions, according to the +International Organization for Standardization (ISO). If specified to be up to the implementation, +we will refer to Microsoft Visual C++ implementation of STL\@. +\\\\ +As a case study, we will implement a rhythm game with bullet hell systems and +compete in Game Talent Showcase competition hosted by Thai Game Software Industry Association (TGA) +using as few libraries as possible. + +\subsection{Stakeholders} +\label{subsec:stakeholders} + +The stakeholders of this project include the student developers, the faculty advisor and reviewer, the academic department, +and the intended users of the product. +The student developers benefit from applying software architecture and performance optimization concepts in practice, while +the faculty advisor, reviewer, and academic department gain insight into the project's technical contribution and academic value. +The intended users benefit from a responsive and efficient interactive media framework that can support engaging real-time experiences. + +\subsection{Expected Benefits} +\label{subsec:expected-benefits} + +\begin{enumerate} + \item A clearer understanding of current game design architectures and its limitations on the development of general-purpose interactive media. + \item A structured analysis of alternative design paradigms that may overcome these limitations. + \item A practical framework that simplifies the development of interactive systems across multiple application domains. + \item Enhanced adaptability and performance in future interactive media platforms. +\end{enumerate} \ No newline at end of file diff --git a/papers/final_report/sections/related_work.tex b/papers/final_report/sections/related_work.tex new file mode 100644 index 00000000..ac930007 --- /dev/null +++ b/papers/final_report/sections/related_work.tex @@ -0,0 +1,169 @@ +\section{Problem Solving \& Related Work} +\label{sec:problem-solving-related-work} + +\subsection{Review of Existing Knowledge} +\label{subsec:review-of-existing-knowledge} + +\subsubsection*{Software Bloat Analysis} + +As hardware has been improving with microprocessors since the 1980s, software engineering practices have +also evolved to match the higher performance provided by the runtime system and architecture. +However, the growth of software requirements proves to be higher in terms of functionality and size. +As the software complexity rapidly increases, the performance improvement from hardware has not been +able to grow fast enough to satisfy the demands. +Hence, performance optimization is necessary in modern software despite the advancement of CPUs and +memory systems. +\\\\ +A study on software bloat~\cite{Software_Bloat_Analysis} claimed that the main cause of performance +problems in software systems was not from hardware limitations, but from lack of optimization in software design. +Modern object-oriented applications often suffer from inefficient use of memory, such as memory leaks +which accumulate unused objects and exhaust the heap space, and algorithms that are not suitable for +large data sets. +Though multicore processors have been widely adapted to improve performance via parallelism, the root +causes of performance bottlenecks are left unsolved. +\\\\ +Solving performance issues in software systems requires effort, time, and knowledge to analyze and +pinpoint the causes of bottlenecks. +Though there are studies on bloat detection and analysis to identify the sources of inefficiencies +in software systems, there are still challenges in the process of bloat removal. +Because the definition of bloat is subjective and varies across different applications, it is challenging +to create a universal solution for bloat removal. +Therefore, the process of removing performance bottlenecks requires careful consideration and specification +to precisely resolve the issues without affecting the intended functionality of the software. + +\subsubsection*{Latency in Video Games} + +When any system has to process inputs and produce outputs, there is always a delay between the input event and the output response. +This delay is known as latency, the time taken for data to travel from the source to the destination. +A study on latency in game engines, including Unity and Unreal Engine~\cite{Gotta_Go_Fast}, measured the input-to-display latency in a 3D scene. +The results showed both engines had small latencies of around 40 to 50 milliseconds. +\\\\ +Though removing latency entirely is impossible, reducing latency is crucial in interactive media, especially ones that require continuous user inputs. +High latency can lead to poor user experience, as users may feel disconnected from the system. +There have been studies and experiments on the effects of latency on user performance in games, from simple point-and-click to intense +first-person shooter game~\cite{Playing_With_Delay}~\cite{Latency_And_Perspective}~\cite{Lower_Better}. +The results showed an identical trend that higher latency, usually at over 100 milliseconds, leads to an evident decline in performance, +with users taking longer time to complete tasks and feeling less satisfied with the experience. +This emphasizes the importance of low latency in interactive media to ensure a smooth and responsive experience for users. + +\subsubsection*{Entity-Component-System Architecture} + +Entity-component-system (ECS) is a software architectural pattern mostly used in game development. +Its mechanisms are characterized by the entities, composed of components of data, +and the systems which operate upon those components. +The behaviors of these entities are modified at runtime by systems modifying, adding, or removing the components +attached to said entities. +\\\\ +Implementations of ECS already exist, even in production contexts. +One of the more popular implementations is EnTT~\cite{ValtoLibraries_EnTT}, a header-only C++ library for game programming. +This library has been used to develop many game titles, the most major of which is Minecraft. +Another popular implementation is Bevy ECS~\cite{Bevy_Engine}, a data-driven game engine built in Rust. +\\\\ +However, most existing ECS libraries use runtime component registration, perform type-erased iteration, or resolve +system dependencies at runtime, or some combination of the above. +While they often optimize queries via template views or code specialization, they cannot fully eliminate +runtime overhead associated with registration, lookup, or caching. +Experimental systems like Vittorio's ECST~\cite{vittorio} achieve deep compile-time specialization +but are not production-ready due to ambiguity in naming, sparse documentation, and hidden dependencies. + +\subsection{Comparison with Existing Systems} +\label{subsec:comparison-with-existing-systems} + +We have reviewed existing well-known free software systems that are designed for interactive media +development to understand their strengths and weaknesses in their architectures and design. + +\subsubsection*{Game Engines} + +When comparing current popular game engines, such as Unity~\cite{Unity_Engine} and Unreal Engine~\cite{Unreal_Engine}, +there are some notable differences in their architecture and performance. +\\\\ +Unity uses a component-based architecture, where game objects can contain various components which +determine their behaviors. +This architecture allows for flexibility and modularity, as components can be added or removed dynamically +from objects. +Unity also provides a data-oriented technology stack (DOTS)~\cite{Unity_DOTS} that utilizes +ECS architecture to improve performance by optimizing memory layout and enabling multithreading on +multiple packages. +The system is built on a native C / C++ engine core, reducing runtime overhead and allowing +cross-platform compatibility. +However, the system uses C\# on .NET Framework for the scripting layer, which introduces memory management +overhead from frequent garbage collection cycles. +Additionally, Unity's architecture relies on object-oriented programming (OOP), which can lead to performance +bottlenecks when managing large numbers of game objects due to deep inheritance hierarchies. +This, along with tight coupling between game objects and their behaviors, leads to challenges in scalability and maintainability. +\\\\ +Unreal Engine also uses a similar component-based architecture, with objects composed of various components +to define their behaviors, but the engine is built entirely in C++, allowing for high +performance and low-level control over system resources. +The engine is also built with modular subsystems (rendering, physics, audio, etc.) that utilize multithreading +to improve performance. +Unreal Engine 5 introduces a new framework similar to ECS called MassEntity~\cite{Unreal_MassEntity}, which aims to +improve performance by optimizing memory layout for large-scale simulations. +However, the engine uses a visual scripting system called Blueprints, which can introduce additional +performance overhead. +Moreover, Unreal Engine contains advanced features such as real-time ray tracing and high-fidelity graphics, +which can be resource-intensive and may require high-end hardware to run smoothly. +\\\\ +Upon comparison, both engines have their strengths and weaknesses in terms of architecture and performance, +which can impact their suitability for different types of projects. +Unity's flexibility and modularity make it a good choice for smaller projects or those requiring rapid +developing cycles, but could suffer from performance issues in larger-scale applications. +An academic study~\cite{DOTS_Study} on Unity's DOTS system showed that while it can provide significant +performance improvements compared to traditional OOP-based designs, the results were worse when a system had to +access objects outside of its own archetype due to difference in data and logic structure. +Additionally, the DOTS system is not as widely adopted in the industry, and there is a lack of documentation +and resources available for developers. +Meanwhile, Unreal Engine's high performance and advanced features aim for high-quality +3D projects, but the system is not built to support the general media applications due to its massive +performance costs. +Currently, in 2026, the MassEntity system is still in development and not fully integrated into the engine as +other features, tools, and documentation are still being worked on. +There is a community project~\cite{MassSample} that experiments with the MassEntity system. +However, the project is not affiliated with the official developers, and the provided documentation may not be +accurate or up-to-date with the latest changes in the engine. + +\subsection{Gap Analysis} +\label{subsec:gap-analysis} + +Upon reviewing existing systems and related work, it is clear that each system has its own strengths depending +on the intended use cases. +However, there are still gaps and limitations that can be addressed to improve performance and flexibility. +\\\\ +Game engines in the past often relied on object-oriented programming (OOP) principles, which make the system easy to +understand due to its similar concepts to real-world objects. +However, OOP is often denounced in modern software engineering for its complexity and inefficiency in managing +large-scale applications with numerous data structures. +While concepts like inheritance and polymorphism provide flexibility in development, they can also be overwhelmed +when managing complex relationships between objects, leading to tight coupling and deep inheritance hierarchies. +Hence, game engines like Unity and Unreal Engine have been shifting towards data-oriented designs like ECS to improve +performance and scalability. +\\\\ +As software demands continue to surpass the current hardware capabilities, system optimization is crucial to ensure +efficient resource utilization and performance. +A recent study on game engine efficiency~\cite{Game_Engine_Efficiency} experimented with Unity, Unreal Engine, +Godot~\cite{Godot_Engine}, and a custom-built engine using ECS architecture and scripting system in C syntax. +When using the engines to buid a simple 2D game, the study showed that as the number of objects increased, the custom +ECS engine outperformed every other engine in terms of CPU usage, power consumption, and memory usage. +This indicates that further optimization is still possible with efficient architecture. + +% \subsection{Linkage to Project} +% \label{subsec:linkage-to-project} + +% Upon analyzing existing systems in the market, it is evident that there are still gaps and limitations +% that can be addressed to improve performance and flexibility. +% We aim to create a framework that combines the strengths of existing architectures while addressing +% their weaknesses. +% By utilizing the ECS architecture, we can achieve better performance and scalability compared to +% traditional OOP-based designs. +% We want to combine the best of both worlds \textemdash to create an ECS framework that registers and determines component types +% and system dependencies at compile-time, while ensuring code flexibility and production-ready performance, complete +% with rigorous documentation. +% \\\\ +% In order to showcase the capabilities of our proposed framework, we plan to develop a game prototype that utilizes +% the system performance to its fullest potential. +% We have designed a game that combines two performance-intensive genres: rhythm games and bullet hell shooters. +% Rhythm games require players to interact with the game in sync with the music, demanding precise timing and +% responsiveness as much as in millisecond accuracy. +% Bullet hell shooters, on the other hand, involve navigating through a screen filled with numerous projectiles, +% requiring efficient handling of a large number of entities and collision detection. +% By merging these two genres, we can create a game that demonstrates our framework's performance and responsiveness. \ No newline at end of file diff --git a/papers/final_report/sections/results_one_column.tex b/papers/final_report/sections/results_one_column.tex new file mode 100644 index 00000000..88d36dd0 --- /dev/null +++ b/papers/final_report/sections/results_one_column.tex @@ -0,0 +1,29 @@ +\section{Results and Analysis} +\label{sec:results-and-analysis} + +\subsection{Test Results} +\label{subsec:test-results} +\vspace{1em} +\centering +\small +\begin{minipage}{\textwidth} + \captionof{table}{System frame duration for each ECS framework} + \begin{tabularx}{\textwidth}{|Y|Y|Y|Y|} + \hline + \multirow{2}{*}{\textbf{Entity Count}} & + \multicolumn{3}{c|}{\textbf{System Frame Duration (in microseconds)}} \\ + \cline{2-4} + & \textbf{Bevy ECS} & \textbf{EnTT} & \textbf{Custom Engine} \\ + \hline + 2000 & 6.439 & 3.014 & 1.127 \\ + 4000 & 9.024 & 6.121 & 3.213 \\ + 8000 & 11.95 & 13.07 & 7.879 \\ + 16000 & 19.36 & 27.97 & 14.95 \\ + 32000 & 32.62 & 57.78 & 38.59 \\ + 64000 & 58.64 & 110.0 & 85.68 \\ + 128000 & 113.4 & 214.4 & 162.9 \\ + \hline + \end{tabularx} + \label{tab:system-frame-duration-benchmark} +\end{minipage} + diff --git a/papers/final_report/sections/results_one_column_two.tex b/papers/final_report/sections/results_one_column_two.tex new file mode 100644 index 00000000..885aa7e4 --- /dev/null +++ b/papers/final_report/sections/results_one_column_two.tex @@ -0,0 +1,24 @@ +\vspace{1em} +\centering +\small +\begin{minipage}{\textwidth} + \captionof{table}{System iteration time per entity in each ECS framework} + \begin{tabularx}{\textwidth}{|Y|Y|Y|Y|} + \hline + \multirow{2}{*}{\textbf{Entity Count}} & + \multicolumn{3}{c|}{\textbf{Entity iteration time (in nanoseconds)}} \\ + \cline{2-4} + & \textbf{Bevy ECS} & \textbf{EnTT} & \textbf{Custom Engine} \\ + \hline + 2000 & 3.219 & 1.507 & 0.564 \\ + 4000 & 2.256 & 1.530 & 0.803 \\ + 8000 & 1.493 & 1.633 & 0.985 \\ + 16000 & 1.210 & 1.748 & 0.934 \\ + 32000 & 1.019 & 1.805 & 1.206 \\ + 64000 & 0.916 & 1.718 & 1.339 \\ + 128000 & 0.886 & 1.675 & 1.273 \\ + \hline + \end{tabularx} + \label{tab:system-iter-benchmark} +\end{minipage} + diff --git a/papers/final_report/sections/results_two_column.tex b/papers/final_report/sections/results_two_column.tex new file mode 100644 index 00000000..5c099dbc --- /dev/null +++ b/papers/final_report/sections/results_two_column.tex @@ -0,0 +1,32 @@ +\subsection{Analysis} +\label{subsec:analysis} + +Table~\ref{tab:system-frame-duration-benchmark} shows the measured system frame duration for each ECS implementation +across increasing entity counts. +In all cases, frame duration increases approximately linearly with respect to the number of entities. +This indicates that each framework scales proportionally with workload size and does not exhibit +significant nonlinear overhead within the tested range. + +We find that our custom engine consistently outperforms EnTT in terms of iteration performance. +The custom engine exhibits 2.7× speedup at 2000 entities, which decreases to 1.3× speedup at 64,000 entities. +When comparing with Bevy, however, while the custom engine begins at 5.7× speedup at 2000 entities, +its performance degrades to a 0.7× slowdown at 128,000 entities. + +When we analyze the entity iteration time in Table~\ref{tab:system-iter-benchmark}, we can see that the iteration cost for +both EnTT and our custom engine generally increases as entity count increases. +For Bevy, however, the iteration cost reduces as entity count increases, alluding to its optimization for batch processing, +something not used in the implementation of the other two options. + +Overall, the results indicate that the custom engine provides competitive performance for the evaluated +workload among the tested ECS frameworks for the 2000 to 16000 entity range. +For use cases asking for more than 32000 entities, Bevy remains a superior option compared to our custom engine. + +\subsection{Limitations} +\label{subsec:limitations-and-lessons} + +The evaluated workload is a simple process that depends only on iteration and data modification. +It does not factor in the other aspects of an ECS architecture, such as the querying of entity archetypes and +the adding and removing of components and entities. +This means that we cannot properly measure the performance of the custom engine in those aspects in comparison to +general-purpose architectures. +We plan to benchmark these aspects of our custom engine in the future\@. \ No newline at end of file diff --git a/papers/final_report/sections/risk_and_resource.tex b/papers/final_report/sections/risk_and_resource.tex new file mode 100644 index 00000000..d963cc03 --- /dev/null +++ b/papers/final_report/sections/risk_and_resource.tex @@ -0,0 +1,45 @@ +\section{Risk and Resource Management} +\label{sec:risk-and-resource-management} + +\subsection{Risks} +\label{subsec:risk} + +The major risk of this project was its scope compared to the development timeframe. +The complexity and workload of developing both the custom game engine and game development were considerably high. +Additionally, work distribution was challenging to manage due to higher-level development depending on the progress of +engine systems development; thus, creating a development bottleneck, especially at the early phase of development. +To mitigate, the lower-end development provided early features or APIs for higher-level developers to test and develop +some game systems in parallel. +\\\\ +As the project was developed from the ground up, errors from the lowest level could cause sequential instability in higher-level systems. +Therefore, testing was required at every stage of the development to ensure system stability. + + +\subsection{Adaptations} +\label{subsec:adaptations} + +Because of the project's large scope compared to the development timeframe, many planned functionalities were postponed for +future works to prioritize optimizing the core systems. +Additionally, gameplay development workloads were frequently adjusted to utilize parallel development +while waiting for features from the engine-level systems. + + +\subsection{Resources} +\label{subsec:resources} + +The project utilizes personal computer systems with standard CPUs and GPUs that are compatible with DirectX 11 +for development, testing, and performance evaluation. +C++20, DirectX 11, Windows API, and GoogleTest are used for development, rendering, debugging and testing. +Additional lightweight open-source libraries such as DirectDraw Surface and miniaudio are utilized for asset and audio processing. +Developers may use any preferred text editor, mostly CLion and neoVim. +GitHub and Discord were used for collaboration purpose. +This project require no additional financial expenses as general hardware resources were already available to the development team. + + +\subsection{Cost Considerations} +\label{subsec:cost-considerations} + +The project required no additional development cost since the project were made entirely from the ground up +using C++, Windows APIs, DirectX and free open-source libraries. +The hardware resources used for development and testing were already available to the development team since the project started. + diff --git a/papers/final_report/sections/team_one_column.tex b/papers/final_report/sections/team_one_column.tex new file mode 100644 index 00000000..f2f78a44 --- /dev/null +++ b/papers/final_report/sections/team_one_column.tex @@ -0,0 +1,35 @@ + +\subsection{Roles and Responsibilities} +\label{subsec:roles-and-responsibilities} + +\vspace{1em} + +\centering +% \begin{tabularx}{\columnwidth}{X X} +% Name & Roles\\ +% \hline +% Tapaneeya Odmung & Project Lead \newline System Software Architecture \newline Operating System Level Software Engineer\\ +% Wachirawich Kanil & System Software Architecture \newline User Level Software Engineer\\ +% Pranesh Ingkanunt & Gameplay Design \newline Game Programming \newline Gameplay Software Architecture\\ +% Rangsiman Jearuksa & Gameplay Design \newline Game Programming \newline Graphic Software Engineer\\ +% \hline +% \end{tabularx} +\small +\begin{minipage}{\textwidth} + \captionof{table}{Roles and Responsibility} + \begin{tabularx}{\textwidth}{|L|L|L|} + \hline + \textbf{Role} & \textbf{Name} & \textbf{Responsibilities} \\ + \hline + Project Lead & - Tapaneeya Odmung & Project Planning, Define System Scope, Communication \\ + System Software Architect & {- Tapaneeya Odmung \newline - Wachirawich Kanil} & Design Engine \\ + Gameplay Design & {- Pranesh Ingkanunt \newline - Rangsiman Jearuksa} & Design Gameplay \\ + Gameplay Software Engineer & {- Pranesh Ingkanunt \newline - Rangsiman Jearuksa} & Program Game \\ + Graphic Software Engineer & {- Tapaneeya Odmung \newline - Rangsiman Jearuksa} & Program Graphic \\ + Operating System Software Engineer & - Tapaneeya Odmung & Program Operating System Level Communication \\ + User Level Software Engineer & - Wachirawich Kanil & Program User Communication Level \\ + Gameplay Software Architect & - Pranesh Ingkanunt & Design Gameplay Architecture \\ + \hline + \end{tabularx} +\end{minipage} +\label{tab:role-name-responsibilities} \ No newline at end of file diff --git a/papers/final_report/sections/team_two_column.tex b/papers/final_report/sections/team_two_column.tex new file mode 100644 index 00000000..de5ff610 --- /dev/null +++ b/papers/final_report/sections/team_two_column.tex @@ -0,0 +1,89 @@ + +% /_\ Nack should check: combine two sections into one "Project management and teamwork" + +\subsection{Work Division} +\label{subsec:work-division} + +Since this project is large and requires highly specialized personnel, each task was assigned +to each person with the intent for them to be the master pertaining to that aspect of the system. +Each of the tasks has their own set of challenges and requires very deep understanding. +This means each person would have their own hard and easy tasks where, on higher-level management, +it can be inferred that the workload is already balanced because of the need of specialty. + +\subsection*{Project Lead} +The person with this role will manage and plan the project. +The main task of this person is to create a systematic plan for the project which is tangible and able to lead to the finished product. +Not only that, this person also needs to communicate and also contact insiders and outsiders as needed. +Also, this person must be able to communicate with other team members, come to an understanding, and be able to find a +suitable solution to make the work go smoothly as much as possible. +\\\\ +Since this team is a small team, the project lead must be able to direct the project direction and understand the image +of the final product so that they can achieve the most beneficial outcome for the team. + +\subsection*{System Software Architect} +The person with this role is responsible for system design. +They have the responsibility to design an architecture which is +suitable for the needs of the software. +They must also create a good work environment for the team to work +with using this system. + +\subsection*{Gameplay Designer} +The person with this role is responsible for designing a game which can test whether +the system is working as intended or not. + +\subsection*{Game Software Engineer} +The person with this role has the task to implement the game according to gameplay design +using the structure planned by the Gameplay Software Architect. + +\subsection*{Graphic Software Engineer} +The person with this role works on creating graphics with high fidelity and also works +on optimization for the graphic section of the software, such as GPU Memory Management. + +\subsection*{Operating System Software Engineer} +The person with this role works on implementing the Application Programming Interface (API) to communicate with +the operating system safely and optimally. +Also, this person must ensure the software security and memory safety. + +\subsection*{User Level Software Engineer} +The person with this role works on implementing the API for users to write software on this system. +The person in charge must be able to create an API that is easy to implement and use. + +\subsection*{Gameplay Software Architect} +This person with this role designs the system flow of a game to ensure good user experience +and also optimal data flow within the game system. + +\subsection{Communication} +\label{subsec:collaborative-plan} +We have a group meeting for updating progress and planning on Friday of every week. +We also have a meeting with the advisor on Thursday of every week. +If there is a need to be absent, every person needs to clearly state so beforehand. +Each system planning will be planned as sprints with durations of two weeks per each iteration. +After every iteration, we will have a reflection on the first Friday after the end of iteration. +For meeting, everyone on the team has selected to have meetings in online format on Discord. +\\\\ +For project source code management, we use Git Version Control System and GitHub as +a remote repository. +The project source code will contain only system source code, game source code, document, report and report image only. +Game resources will need to be downloaded outside the repository. +\\\\ +We use Cmake as a build system to allow team members to work easily with any text editor. +We also use clangd as a formatter to have a consistent coding style. +MSVC is used as a main system compiler such that we target Windows Operating System specifically. +Although we allow any text editor to use within this project, Clion by JetBrains is preferred. + +\subsection{Reflection} +\label{subsec:reflection} + +% Assess strengths, weaknesses, and improvements in teamwork. +Due to the work being split based on the strengths of each team member, each person found their tasks to be challenging +but not overly difficult. +As such, the implementation of each system in detail was fast and performant. +For sections of the task where the person responsible was not overly familiar, they could source information from related fields +in their expertise to help with the issue. +They were also able to correctly query and verify search engines and large language models for accurate information. + +However, since much of the work was done in isolation, communication between modules suffered minor issues. +Each person was hesitant to contribute to the other's works to ensure the connections between modules were smooth and efficient. +Some might have found it easier to accept the work of the expert rather than discuss corrections to their work. +This was mitigated by the team leader facilitating meetings and reviews of each person's work, and the project was +completed within the predicted duration in the end. \ No newline at end of file diff --git a/papers/final_report/sections/testing.tex b/papers/final_report/sections/testing.tex new file mode 100644 index 00000000..c33093b2 --- /dev/null +++ b/papers/final_report/sections/testing.tex @@ -0,0 +1,85 @@ +\section{Testing and Experimentation} +\label{sec:testing} + +\subsection{Methodology} +\label{subsec:methodology} + +The purpose of the testing is to evaluate the performance characteristics of our custom engine in comparison with industry-standard +ECS frameworks under comparable workloads. +We assess performance through measuring system frame duration, the time required to run the user system, +as this duration is a direct indicator of runtime responsiveness and execution efficiency. + +For each framework, system frame duration is measured by recording a timestamp immediately before the execution of +the user system and another immediately after the user system finished processing. +We repeat this process for different entity counts to observe underlying performance degradation. +To evaluate the framework performance, we assume an instantaneous, highly optimized renderer. +To this end, we exclude the rendering systems from Bevy and our custom engine, opting to compare only the logical systems. +This lets us take the system frame duration to be representative of the response time from input to output, +making it an effective metric for overall system performance. + +All ECS frameworks were tested using the language’s release build profile. +Systems for each framework were implemented according to official tutorials and documentation +to ensure that implementations were idiomatic and representative of recommended usage patterns. +We average the system frame time across 1000 repetitions to remove noise from the result. +The output is logged only after all time-sensitive work is done to not impact performance. + +All tests were executed on local hardware using the same machine and operating environment to ensure consistency across measurements. +The hardware specifications are as follows: + +\begin{itemize} + \item CPU: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30 GHz + \item GPU: Intel(R) UHD Graphics + \item Memory: 3200 MHz 16.0 GB RAM + \item Operating System: Windows 10 Version 22H2 (OS Build 19045.6466) +\end{itemize} + +When testing ECS frameworks, it is important that the user system implementation itself does not have a massive time cost relative to +the framework. +With consideration of this, we opted for a relatively simple process, instead of the logic used for complex simulations. +The user system used for the benchmark is a process that adds an entity's velocity to its position. +This system measures the framework's efficiency in iteration and data modification, which constitutes a large part of ECS usage. + +\subsubsection*{Bevy ECS} + +For the Bevy ECS implementation, timing measurements are performed using the Rust standard library's \texttt{std::time::Instant}. +A benchmarking resource is defined to store frame timing information and maintain a handle to a log file for persistent output. + +Two benchmark systems are inserted into the Bevy update schedule: one system records the start timestamp immediately +before execution of the user-defined systems, while another records the end timestamp immediately afterward. +Bevy’s system chaining mechanism is used to guarantee deterministic execution order between the +benchmark systems and the systems under test. +Each user system is allowed to be parallelized by Bevy's ECS scheduler. +To idiomatically measure only user systems and minimize additional overhead, we use Bevy's \texttt{MinimalPlugins} plugin group. +According to related documentation~\cite{bevy_minimalplugins}, this plugin group represents the absolute minimum bare-bones application. + +The elapsed duration between the two timestamps was written both to standard output and to a log file after the system +has run to the specified number of repetitions. +We use \texttt{std::fs::File} guarded by a mutex for safe access. + +\subsubsection*{EnTT} + +For the EnTT implementation, timing measurements were performed using C++’s \texttt{} library. +The benchmark instrumentation was placed directly within the main \texttt{update()} function responsible for +executing all ECS systems. +We let this function return the duration measured by the benchmark to store and use for the time difference. +We use a for-loop to repeat this function for the specified number of repetitions. +For the user system, we use a range-for implementation as documented in the framework's given code example~\cite{ValtoLibraries_EnTT}. + +A timestamp was recorded immediately before system execution using \texttt{std::chrono::steady\_clock::now()}, +and a second timestamp was recorded immediately after all systems completed execution. +The elapsed duration was converted to microseconds using \texttt{std::chrono::duration\_cast}. + +Test parameters and measured frame times were appended to a persistent log file using \texttt{std::ofstream}, +as well as the final average. + +\subsubsection*{Our Custom Engine} + +For our custom engine, we use the ECS header files to construct the benchmarking program. +In the main function, we construct a \texttt{TaskManager} which registers the user system to run. +We then create a helper function that applies the benchmark instrumentation before and after +a call to the \texttt{TaskManager::update()}, returning the duration elapsed to store and use for the time difference. +We use a for-loop to repeat this function for the specified number of repetitions. + +Test parameters and measured frame times were appended to a persistent log file using \texttt{std::ofstream}, +as well as the final average. +The general mechanisms, outside of framework implementations, are kept identical to the EnTT case for parity. \ No newline at end of file diff --git a/papers/final_report/sections/timeline_one_column.tex b/papers/final_report/sections/timeline_one_column.tex new file mode 100644 index 00000000..1ec28617 --- /dev/null +++ b/papers/final_report/sections/timeline_one_column.tex @@ -0,0 +1,26 @@ +\section{Project Management and Teamwork} +\label{sec:project-management-and-teamwork} + +\subsection{Timeline \& milestones} +\label{subsec:timeline-and-milestones} + +\vspace{1em} +\centering +\small +\begin{minipage}{\textwidth} + \captionof{table}{Planned Work} + \begin{tabularx}{\textwidth}{|L|L|L|} + \hline + \textbf{Week} & \textbf{Task / Milestone} & \textbf{Deliverable} \\ + \hline + Week 1\, \textendash \, 7 & Rendering pipeline & Screen rendering with fixed arbitrary triangles \\ + Week 8\, \textendash \, 9 & Progress report presentation & Progress report \& slides\\ + Week 10\, \textendash \, 11 & Bullet hell demo, Entity polygon rendering \& Scene Manager optimization & CLI bullet hell log, Screen rendering with dynamic polygons \\ + Week 12\, \textendash \, 14 & Entity sprite rendering \& text rendering & Screen rendering with images \& FPS counter \\ + Week 15\, \textendash \, 16 & Audio \& Scene change API & Screen rendering with audio \\ + Week 17 & Bullet hell and rhythm game visual demo & Video of bullet hell and rhythm game logic \\ + Week 18 & Demo game \& Final report presentation & Final report and slides \& Game executable \\ + \hline + \end{tabularx} +\end{minipage} +\label{tab:planned-work} \ No newline at end of file diff --git a/papers/final_report/sections/title.tex b/papers/final_report/sections/title.tex new file mode 100644 index 00000000..63dbc14a --- /dev/null +++ b/papers/final_report/sections/title.tex @@ -0,0 +1,69 @@ +\noindent +{\footnotesize +Computer Engineering Capstone Project Final Report +\par} + +\vspace{0.3cm} + +\noindent +{\Large\bfseries +Utilization of High Precision Software System +\par} + +\noindent +{\Large\bfseries +for Development of Interactive Entertainment Media +\par} + +\vspace{0.4cm} + +\noindent +{\small +Tapaneeya Odmung \, \textbar \, +Wachirawich Kanil \, \textbar \, +Pranesh Ingkanunt \, \textbar \, +Rangsiman Jearuksa +\par} + +\vspace{0.3cm} + +\noindent +{\scriptsize +Department of Computer Engineering, Chulalongkorn University, Bangkok, Thailand +\par} + +\vspace{0.3cm} + +\noindent +{\scriptsize +\textbf{Advisor:} +Assoc. Prof. Vishnu Kotrajaras (vishnu@cp.eng.chula.ac.th), +Kamin Kolyutsakul %(something@somewhere.com) +\par} + +\vspace{0.3cm} + +\noindent +{\scriptsize +\textbf{Keywords:} +high-performance computing, +computer graphics, +real-time rendering, +parallel processing, +software architecture, +game engine +\par} + +\vspace{0.3cm} + +\noindent +{\normalsize \today \par} + +\vspace{0.5cm} + +\begin{center} + \includegraphics[width=\textwidth, keepaspectratio]{images/title} +\end{center} + +%{\rule{\textwidth}{0.5px}\par} +%\vspace{-0.4cm} \ No newline at end of file