From 963430c931a85c3985a99c5bebd3fc6e9ae3b43b Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 10 Sep 2024 08:53:39 +0200 Subject: added sources --- sources.bib | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'sources.bib') diff --git a/sources.bib b/sources.bib index b088784..5848f86 100644 --- a/sources.bib +++ b/sources.bib @@ -12,3 +12,39 @@ institution = {RFC Editor}, } +@misc{miro:scrum-board, + author = {Jaro Rutjes}, + title = {Scrum Board on Miro}, + url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, + date = {2024-09-10}, +} + +@misc{crepe:code-repo, + author = {lonkaars}, + title = {Crepe Code Repository}, + url = {https://github.com/lonkaars/crepe}, + date = {2024-09-10}, +} + +@misc{crepe:docs-repo, + author = {lonkaars}, + title = {Crepe Documentation Repository}, + url = {https://github.com/lonkaars}, + date = {2024-09-10}, +} + +@misc{crepe:docs-standard, + author = {lonkaars}, + title = {Crepe Documentation Standard}, + url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, + date = {2024-09-10}, +} + +@misc{crepe:code-standard, + author = {lonkaars}, + title = {Crepe Code Standard}, + url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, + date = {2024-09-10}, +} + + -- cgit v1.2.3 From 454b9e222473c67d0b3bb6935bf3bfb8d2e2043d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 13 Sep 2024 16:40:50 +0200 Subject: merge #10 --- plan.tex | 276 ++++++++++++++++++++++++++++++++++++++++-------------------- projdoc.cls | 18 +++- sources.bib | 10 +-- 3 files changed, 205 insertions(+), 99 deletions(-) (limited to 'sources.bib') diff --git a/plan.tex b/plan.tex index 2274c87..076ce11 100644 --- a/plan.tex +++ b/plan.tex @@ -5,132 +5,200 @@ % Version 0.0 seems not right % I'm also missing a 'version table' % Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers before the comma indicate versions ready for publication +% Version numbers after the comma indicate an interim version and version numbers +% before the comma indicate versions ready for publication \title{Project Plan} \version{0.1} \begin{document} - \tablestables \newpage +\section{Background} -\section {Background} -This project is part of the fourth-year minor `Systems Programming in C++'. The minor consists of several courses troughout 20 weeks, which create the basis for this project. The project is focussed on building a game engine using the programming language C++. This document describes our plan of attack for the project. +This project is part of the fourth-year minor `Systems Programming in C++'. The minor +consists of several courses troughout 20 weeks, which create the basis for this +project. The project is focussed on building a game engine using the programming +language C++. This document describes our plan of attack for the project. \section{Problem Definition} -% The assignments will be discussed with the project supervisor on specifics for this project. This will give the team the ability to direct the project. -% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu even uit gehaald en een nieuw kopje background toegevoegd. + +% The assignments will be discussed with the project supervisor on specifics for this +% project. This will give the team the ability to direct the project. + +% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van +% background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu +% even uit gehaald en een nieuw kopje background toegevoegd. \subsection{Problem Analysis} -CodedFun Games is a small, single-person game company looking to scale up. The owner, who is also a game programmer, and graphical artist, has received government funding, which he wants to invest in a custom-built game engine. The owner has no interest in developing or maintaining a game engine himself, so he has hired a part-time engine programmer. This programmer does not have time to create an entire engine but is willing to maintain or expand an existing engine one day per week. -The client seeks a custom game engine that is easy to maintain, easy to extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. +CodedFun Games is a small, single-person game company looking to scale up. The owner, +who is also a game programmer, and graphical artist, has received government funding, +which he wants to invest in a custom-built game engine. The owner has no interest in +developing or maintaining a game engine himself, so he has hired a part-time engine +programmer. This programmer does not have time to create an entire engine but is +willing to maintain or expand an existing engine one day per week. -So far, the client has made all his games in Unity and is very fond of the structure. Therefore, he wants the new engine to adhere to a similar structure. A simple requirements document is defined to specify how strictly this structure should be followed. +The client seeks a custom game engine that is easy to maintain, easy to extend, and +user-friendly. Additionally, the engine should be well-documented, which is +considered an essential aspect of being user-friendly. -Finally, because the client does not want to dive deeply into the engine himself, he wants a secondary application (preferably a game) that can be used to test the engine's features. This is referred to as the `validation application.' +So far, the client has made all his games in Unity and is very fond of the structure. +Therefore, he wants the new engine to adhere to a similar structure. A simple +requirements document is defined to specify how strictly this structure should be +followed. + +Finally, because the client does not want to dive deeply into the engine himself, he +wants a secondary application (preferably a game) that can be used to test the +engine's features. This is referred to as the \emph{validation application}. \subsection{Goal} -The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. In addition, a validation application should be created to show and test the engine's features. + +The goal is to develop a custom game engine that meets the client's requirements for +maintainability, extensibility, user-friendliness, and adherence to a Unity-like +structure. In addition, a validation application should be created to show and test +the engine's features. \subsection{Result} -The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities. +The expected result is a well-documented, custom game engine that follows a structure +similar to Unity. Additionally, a validation application should be provided to test +and showcase the engine's capabilities. \section{Planning} -The customer specified multiple deliverables troughout the 20 weeks of this project. Despite the fact that 20 weeks have been reserved for this project, the intention is that the game will be delivered in week 17. Any delay/resit will take place between weeks 17 and 20. A rough planning can be found in \cref{tab:planning}. + +The customer specified multiple deliverables troughout the 20 weeks of this project. +Despite the fact that 20 weeks have been reserved for this project, the intention is +that the game will be delivered in week 17. Any delay/resit will take place between +weeks 17 and 20. A rough planning can be found in \cref{tab:planning}. + \begin{table} - \begin{tabularx}{\linewidth}{lXr} + \begin{tabularx}{\linewidth}{lX} \toprule - Week & Deliverable & \\ + \textbf{Week\#} & \textbf{Deliverable}\\ \midrule - 4 & Project Plan & \\ - 7 & Requirements document & \\ - 10 & POCs and Design document & \\ - 17 & Game engine, Validation application, Research document, and Qualification document & \\ + 4 & Project Plan\\ + 7 & Requirements document\\ + 10 & POCs and Design document\\ + 17 & Game engine, Validation application, Research document, and Qualification + document\\ \bottomrule \end{tabularx} \caption{Planning} \label{tab:planning} \end{table} - \section{Risks} + \subsection{Techincal Risks} -Multiplatform: The team works in both linux and windows, which poses a risk for the development if there is a platform dependency. -Integration: Users can make a wrong integration causing for delay or risk of losing code. + +\begin{description} + \item[Multiplatform] The team works in both linux and windows, which poses a risk + for the development if there is a platform dependency. + \item[Integration] Users can make a wrong integration causing for delay or risk of + losing code. +\end{description} \subsection{Project Management Risks} -Scope Expansion: There is a risk of creating a scope that is bigger than the requirements. -Lack of Team Collaboration: Insufficient collaboration among team members -may hinder progress. + +\begin{description} + \item[Scope Expansion] There is a risk of creating a scope that is bigger than the + requirements. Lack of Team Collaboration: Insufficient collaboration among team + members may hinder progress. +\end{description} \subsection{Measures} -Multiplatform: The team can switch any time to a single platform, so this risk is metigated. -Integration: By following standards and having an integrator, which checks every pull request, this risk is minimilised. -Scope Expansion: By writing detailed requirements and having weekly team meetings, to check if the progress is within the scope, should be sufficient to decrease the risk. -Lack of Team Collaboration: Weekly team meetings will result in collaboration among team members and discussing what each other tasks is, will decease this risk. +\begin{description} + \item[Multiplatform] The team can switch any time to a single platform, so this + risk is metigated. + \item[Integration] By following standards and having an integrator, which checks + every pull request, this risk is minimilised. + \item[Scope Expansion] By writing detailed requirements and having weekly team + meetings, to check if the progress is within the scope, should be sufficient to + decrease the risk. + \item[Lack of Team Collaboration] Weekly team meetings will result in collaboration + among team members and discussing what each other tasks is, will decease this + risk. +\end{description} -% Documentation Standard is described here \section{Documentation} -This section describes the required documentation for the project, including the types of documents to be created and the standards they must adhere to. + +This section describes the required documentation for the project, including the +types of documents to be created and the standards they must adhere to. \subsection{Documents} + This project consists of seven main documents:\noparbreak \begin{description} - \item[Project Plan] Contains all elements related to the organization of the project, including timelines, milestones, roles, and responsibilities. - \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. + \item[Project Plan] Contains all elements related to the organization of the + project, including timelines, milestones, roles, and responsibilities. + \item[Requirements] Details the requirements and user stories, including both + functional and non-functional requirements. \item[Research] Consists of all research related to this project. - \item[Design] Describes the design choices, including architecture, - user interface, and system components. - \item[Qualification] Includes test cases, test plans, and quality - measures to ensure the project meets its requirements and standards. + \item[Design] Describes the design choices, including architecture, user interface, + and system components. + \item[Qualification] Includes test cases, test plans, and quality measures to + ensure the project meets its requirements and standards. \item[Working hours] A table which includes all working hours of each team member. - \item[API Reference] Details the available endpoints, request and response formats, authentication methods, error codes, and examples for interacting with the project's API. + \item[API Reference] Details the available endpoints, request and response formats, + authentication methods, error codes, and examples for interacting with the + project's API. \end{description} \subsection{Documentation Standard} -The documentation standard can be found in the contributing.md \autocite{crepe:docs-standard}. +The documentation standard can be found in the contributing.md +\autocite{crepe:docs-standard}. \section{Work Agreements} -Work agreements are the expectations and commitments made by the team members. -This section includes details on roles and responsibilities, documentation of -work hours, protocols for handling absences or delays, guidelines for addressing inconsistent participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project Roles} -\begin{itemize} - \item \textbf{Loek Le Blansch}: Integrator - \item \textbf{Wouter Boerenkamps}: Project Member - \item \textbf{Jaro Rutjes}: Team Leader / Scrum Master - \item \textbf{Max Smits}: Project Member - \item \textbf{Niels Stunnebrink}: Project Member -\end{itemize} +Work agreements are the expectations and commitments made by the team members. This +section includes details on roles and responsibilities, documentation of work hours, +protocols for handling absences or delays, guidelines for addressing inconsistent +participation, and procedures for weekly updates and meetings. All team members +reviewed and agreed to these terms. -\subsection{Work Hours} -Each project member will keep track of their own working hours and add them to the `file'. +\subsection{Project roles} + +\begin{description} + \item[Loek Le Blansch] Integrator + \item[Wouter Boerenkamps] Project Member + \item[Jaro Rutjes] Team Leader / Scrum Master + \item[Max Smits] Project Member + \item[Niels Stunnebrink] Project Member +\end{description} + +\subsection{Work hours} + +Each project member will keep track of their own working hours and add them to the +`file'. + +\subsection{Absence or delay} -\subsection{Absence Or Delay} If a project member is going to be absent or delayed, they are required to notify the team through either WhatsApp or Outlook. Additionally, the teacher should be informed of the absence as well. \subsection{Inconsistent participation} + Inconsistent participation will be addressed in a structured manner: + \begin{description} - \item[Initial Discussion]: The team leader will first discuss the - issue of inconsistent participation with the individual team member. - \item [Team Discussion]: If no improvement is observed, the issue - will be brought up with the entire team to seek a collective solution. - \item [Project Supervisor Involvement]: Should the problem persist, despite these efforts, it will be escalated to the project supervisor (Bob van der Putten) for further action. + \item[Initial Discussion] The team leader will first discuss the issue of + inconsistent participation with the individual team member. + \item [Team Discussion] If no improvement is observed, the issue will be brought up + with the entire team to seek a collective solution. + \item [Project Supervisor Involvement] Should the problem persist, despite these + efforts, it will be escalated to the project supervisor (Bob van der Putten) for + further action. \end{description} -Valid reasons for absence or inconsistency will be considered, and no -repercussions will be necessary in such cases. However, if the inconsistency is -due to other factors, potential repercussions may include additional assignments or actions as determined by the project supervisor. +Valid reasons for absence or inconsistency will be considered, and no repercussions +will be necessary in such cases. However, if the inconsistency is due to other +factors, potential repercussions may include additional assignments or actions as +determined by the project supervisor. A team member is considered to have inconsistent participation if their hours are significantly behind the team’s average or if tasks are not completed @@ -138,8 +206,11 @@ without valid reasons. It is essential that any concerns regarding a team member's performance, should be resolved through unanimous agreement within the team. \subsection{Weekly Update} -Each team member is required to send their technical weekly update to Jaro -Rutjes before 12:00 on Friday. Personal updates may also be included and will be confidential between the team member, the Team Leader, and/or the teacher, if requested. + +Each team member is required to send their technical weekly update to Jaro Rutjes +before 12:00 on Friday. Personal updates may also be included and will be +confidential between the team member, the Team Leader, and/or the teacher, if +requested. Jaro Rutjes will compile and send a team update to the project supervisor, Bob van der Putten, also by Friday. This update will include technical information @@ -147,63 +218,82 @@ on what has been accomplished, plans for upcoming work, and an overview of the team's overall progress. \subsection{Weekly Meetings} -The project team will hold at least two meetings each week, with each meeting -lasting a maximum of 30 minutes. Following these meetings, an additional one -hour will be scheduled for discussions on the topics covered. -Meetings will be planned and discussed one week in advance, with invitations -sent via Outlook. Additional meetings may be scheduled if necessary to address -issues or project needs. +The project team will hold at least two meetings each week, with each meeting lasting +a maximum of 30 minutes. Following these meetings, an additional one hour will be +scheduled for discussions on the topics covered. +Meetings will be planned and discussed one week in advance, with invitations sent via +Outlook. Additional meetings may be scheduled if necessary to address issues or +project needs. % Information about how and when Scrum will be used in this project (using Miro). \section{Scrum (Miro)} -The team will start using scrum after the initial phase, of structering the project, is finished. This phase is over when proof of concepts are being made. + +The team will start using scrum after the initial phase, of structering the project, +is finished. This phase is over when proof of concepts are being made. \subsection{Scrum Board} + The Scrum board \autocite{miro:scrum-board} will consist of the following tabs: + \begin{description} - \item[Backlog]: This tab contains a list of all tasks and user stories that are planned for future sprints. - \item[Next Sprint]: This tab includes tasks and user stories that have been selected for the upcoming sprint. - \item[Current Sprint]: This tab displays the tasks and user stories that are actively being worked on in the current sprint. - \item[In Progress]: Tasks that are actively being worked on are moved to this tab. - \item[Review]: Completed tasks that are awaiting review or testing will be placed in this tab. - \item[Done]: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. - \item [Blocked]: This tab is used for tasks that cannot proceed due to obstacles or dependencies. + \item[Backlog] This tab contains a list of all tasks and user stories that are + planned for future sprints. + \item[Next Sprint] This tab includes tasks and user stories that have been selected + for the upcoming sprint. + \item[Current Sprint] This tab displays the tasks and user stories that are + actively being worked on in the current sprint. + \item[In Progress] Tasks that are actively being worked on are moved to this tab. + \item[Review] Completed tasks that are awaiting review or testing will be placed in + this tab. + \item[Done] Once tasks have been reviewed and are considered complete, they are + moved to the Done tab. + \item [Blocked] This tab is used for tasks that cannot proceed due to obstacles or + dependencies. \end{description} -\noindent To manage tasks effectively: + \begin{itemize} - \item A task from the \emph{Current Sprint} tab should be selected and moved to the \emph{In Progress} tab when work begins. - \item The status of the task should be updated to \emph{In Progress} as soon as work starts. - \item Once the task is completed and reviewed, it should be moved to the \emph{Done} tab, and its status should be updated to \emph{Done}. + \item A task from the \emph{Current Sprint} tab should be selected and moved to the + \emph{In Progress} tab when work begins. + \item The status of the task should be updated to \emph{In Progress} as soon as + work starts. + \item Once the task is completed and reviewed, it should be moved to the + \emph{Done} tab, and its status should be updated to \emph{Done}. \end{itemize} -\noindent -Each task or user story will be assigned user points, which indicate the relative size or complexity of the task compared to these examples. +Each task or user story will be assigned user points, which indicate the relative +size or complexity of the task compared to these examples. % TODO: add examples \subsection{Burn Down Chart} -The Burn Down Chart will be generated using Excel from the Scrum board data every week. -Each user story or task marked as done, will burn the chart downwards. -This Burn Down Chart is shared in the weekly updates with the team and the project supervisor. +The Burn Down Chart will be generated using Excel from the Scrum board data every +week. Each user story or task marked as done, will burn the chart downwards. This +Burn Down Chart is shared in the weekly updates with the team and the project +supervisor. -% Information regarding the git workflow of this project. Diagram explaining the workflow +% Information regarding the git workflow of this project. +% TODO: Diagram explaining the workflow \section{Git Workflow} -GitHub is used for version management of both code and documentation, each in its own respective repository. -This keeps the documentation and code seperate, resulting in ordened and manageable repositories. -\begin{itemize} - \item Code Repository: crepe \autocite{crepe:code-repo} - \item Documentation Repository: crepe-docs \autocite{crepe:docs-repo} -\end{itemize} + +GitHub is used for version management of both code \autocite{crepe:code-repo} and +documentation \autocite{crepe:docs-repo}, each in its own respective repository. This +keeps the documentation and code seperate, resulting in ordened and manageable +repositories. \subsection{Git New Branch} + % TODO: add here details from contributing.md? + \subsection{Git Merge To Master} + % TODO: add here diagram on what actions are taken before merge. + \subsection{Code Standard} + The code standard can be found in the contributing.md \autocite{crepe:code-standard}. \end{document} diff --git a/projdoc.cls b/projdoc.cls index cc25e67..c0257ca 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -119,6 +119,16 @@ itemsep=\dimexpr\style@itemsep-\style@parsep\relax, parsep=\style@parsep, } +\def\projdoc@setdescriptionstyle{% + \renewcommand\makelabel[1]{% + {\bfseries ##1}:% + }% +} +\setdescription{ + before={\projdoc@setdescriptionstyle}, + leftmargin=3em, + labelindent=3ex, +} \makeatother % create a label using \customlabel[]{}{} that displays @@ -213,10 +223,16 @@ \def\projdoc@trailer{ % bibliography (if citations used) \ifbool{projdoc@used@cite}{% + \hfuzz=50pt% reduce overfull hbox warnings for bibliography (mostly URLs) \printbibliography% }{}% % glossary - \ifbool{projdoc@used@cite}{% + \ifbool{projdoc@used@gls}{% + \setdescription{ + before={\projdoc@setdescriptionstyle}, + leftmargin=2ex, + labelindent=0pt, + }% \section*{Glossary}% \begin{multicols}{2}% \renewcommand{\glossarysection}[2][]{}% diff --git a/sources.bib b/sources.bib index 5848f86..50f5ead 100644 --- a/sources.bib +++ b/sources.bib @@ -13,35 +13,35 @@ } @misc{miro:scrum-board, - author = {Jaro Rutjes}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Scrum Board on Miro}, url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, date = {2024-09-10}, } @misc{crepe:code-repo, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Code Repository}, url = {https://github.com/lonkaars/crepe}, date = {2024-09-10}, } @misc{crepe:docs-repo, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Documentation Repository}, url = {https://github.com/lonkaars}, date = {2024-09-10}, } @misc{crepe:docs-standard, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Documentation Standard}, url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, date = {2024-09-10}, } @misc{crepe:code-standard, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Code Standard}, url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, date = {2024-09-10}, -- cgit v1.2.3 From f89ee3feb7e514ec7fbb469a16d34569a57bd0dc Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 18 Sep 2024 15:03:23 +0200 Subject: Added sources to text --- research.tex | 28 ++++++++++++++-------------- sources.bib | 12 ++++++++++++ 2 files changed, 26 insertions(+), 14 deletions(-) (limited to 'sources.bib') diff --git a/research.tex b/research.tex index 3e2e103..d453df5 100644 --- a/research.tex +++ b/research.tex @@ -72,23 +72,23 @@ entity. To assign properties and functions to entities, components are used. There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based on the amount of stars on GitHub. -\begin{table} - \begin{tabularx}{\linewidth}{lXr} - \toprule - \textbf{Name} & \textbf{Short Description} & \textbf{GitHub Stars} \\ - \midrule - EnTT & Fast and reliable entity-component system & 10k \\ - Flecs & A Multithreaded Entity Component System written for C89 and C99 & 6.3k \\ - EntityX & Fast, type-safe C++ entity component system & 2.2k \\ - \bottomrule - \end{tabularx} - \caption{Popular \gls{ecs} libraries} - \label{tab:popularECSLibraries} +\begin{table}[ht] + \centering + \begin{tabular}{ll@{\qquad}lr} + \toprule + \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License} \\ + \midrule + EnTT & Fast and reliable entity-component system & 10k & MIT \\ + Flecs & A Multithreaded Entity Component System & 6.3k & MIT \\ + EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT \\ + \bottomrule + \end{tabular} + \caption{Popular \gls{ecs} libraries \autocite{github:001}} + \label{tab:popularECSLibraries} \end{table} -https://github.com/abeimler/ecs_benchmark It is, of course, not necessary to use a library to implement an \gls{ecs} architecture. -However, it seems very hard to achieve the same performance as a library. https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs +However, it seems very hard to achieve the same performance as a library. \autocite{github:002} \subsection{Conclusion} diff --git a/sources.bib b/sources.bib index 50f5ead..9b08c96 100644 --- a/sources.bib +++ b/sources.bib @@ -47,4 +47,16 @@ date = {2024-09-10}, } +@misc{github:001, + author = {Sangjun Lee}, + title = {Awesome Entity Component System}, + url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file}, + date = {2023} +} +@misc{github:002, + author = {Sander Mertens}, + title = {ECS FAQ}, + url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs}, + date = {2023} +} -- cgit v1.2.3 From 105cab5fc6f88f7e71e71910c5f598d39fba3262 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 18 Sep 2024 16:25:37 +0200 Subject: Rectified gameObject/components section, added references to gameObject/components section and created new subsubsection for the game engine's structure --- research.tex | 34 ++++++++++++++++++---------------- sources.bib | 16 ++++++++++++++++ 2 files changed, 34 insertions(+), 16 deletions(-) (limited to 'sources.bib') diff --git a/research.tex b/research.tex index d453df5..f62f736 100644 --- a/research.tex +++ b/research.tex @@ -44,13 +44,17 @@ layers are divided into the following categories:\noparbreak performance profiling. \item[Scripting layer] Runs scripts, such as Lua or Python. \item[Memory systems] Handles and monitors memory usage. - \item[\gls{ecs}] Provides a modular way to create game objects, add physics, and - define how the engine interacts with objects. \item[Physics] Adds specific physics to objects. \item[Audio] Processes audio. \item[AI] Provides artificial inteligent behavior. \end{description} +\subsubsection{Structure} + +The above mentioned layers should be structured, somehow. One of the requirements is +that the game engine's API uses a so-called gameObject (with one or more component(s)). +The gameObject is described in more detail at \cref{sec:Gameobjects/components}. ... + \subsubsection{ECS} A game engine must have the ability to keep track and update several game objects. To @@ -286,6 +290,7 @@ Not considered further: \subsection{Conclusion} \section{Gameobjects/components} +\label{sec:Gameobjects/components} \subsection{Introduction} @@ -302,16 +307,7 @@ A gameObject is the most important concept in Unity. Every object in a game is a GameObject, from characters and collectible items to the lights, cameras and special effects. However, a gameObject itself can't do anything on its own. A gameObject needs to be given properties before it can become a character, an envirnment, or a -special effect. -% TODO: cite https://docs.unity3d.com/Manual/GameObjects.html - -\subsection{Conclusion} - -\section{AI} - -\subsection{Introduction} - -\subsection{Findings} +special effect. \autocite{man:unityGameobjects} A gameObject can be seen as a container for components. Components are the properties of the gameObject. A few examples of components are sprites, animators, audioSources, @@ -326,14 +322,20 @@ gameObject. Each gameObject always has one transform class. The transform class describes the position, rotation, and scale within the scene. Some component use this information to e.g. scale a sprite. Other components eddit this information to e.g.~model -gravity. -% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html +gravity. \autocite{man:unityTransformClass} A gameObject can have one (or multiple) children gameObject(s). All children gameObjects, of course, also have one transform class. However, the position, rotation, and scale of this class, is always the same as the child's parent. A child -can not have more than one parent. -% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html +can not have more than one parent. \autocite{man:unityTransformClass} + +\subsection{Conclusion} + +\section{AI} + +\subsection{Introduction} + +\subsection{Findings} \subsection{Conclusion} diff --git a/sources.bib b/sources.bib index 9b08c96..d6b960b 100644 --- a/sources.bib +++ b/sources.bib @@ -60,3 +60,19 @@ url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs}, date = {2023} } + +@manual{man:unityGameobjects, + title = {GameObject}, + author = {Unity Technologies}, + organization = {Unity}, + url = {https://docs.unity3d.com/Manual/GameObjects.html}, + date = {2024} +} + +@manual{man:unityTransformClass, + title = {Transform Class}, + author = {Unity Technologies}, + organization = {Unity}, + url = {https://docs.unity3d.com/Manual/class-Transform.html}, + date = {2024} +} -- cgit v1.2.3 From c37f21e48f17abe9fb6bf1549f680e6f730aed8c Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 18 Sep 2024 16:52:40 +0200 Subject: WIP research --- projdoc.cls | 3 +++ reqs.toml | 16 ++++++++++- research.tex | 34 ++++++++++------------- scripts/reqs2tex.py | 3 +++ sources.bib | 77 +++++++++++++++++++++++++++++++++++++++-------------- 5 files changed, 92 insertions(+), 41 deletions(-) (limited to 'sources.bib') diff --git a/projdoc.cls b/projdoc.cls index fccf8c1..05e401c 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -389,3 +389,6 @@ } \makeatother +% missing reference marker +\def\mref{\textsuperscript{\textit{\,ref?}}} + diff --git a/reqs.toml b/reqs.toml index 6645ea4..2da91ac 100644 --- a/reqs.toml +++ b/reqs.toml @@ -67,7 +67,9 @@ The public audio \gls{api} allows the game programmer to control the volume of audio samples. ''' -[aux.license] +# TODO: audio encoding support? + +[lib.license] type = 'system' priority = 'must' description = ''' @@ -75,3 +77,15 @@ External libraries must have a license that is MIT-compatible, or one that allows linking against MIT code. ''' +[lib.platform] +type = 'system' +priority = 'must' +description = ''' +External libraries must have cross-platform support for at least Linux and +Windows. +''' + +# TODO: library popularity as quality factor? +# TODO: library documentation as quality factor? +# TODO: modularity over less libraries? (i.e. why don't we just SDL2 everything?) + diff --git a/research.tex b/research.tex index ad33d10..abfde3b 100644 --- a/research.tex +++ b/research.tex @@ -201,44 +201,38 @@ for audio some options could be: FMOD, Wwise, or iirKlang \subsection{Conclusion} -% TODO: this entire section \section{Audio} -% should audio research be scoped down to SDL2 (if that's what we're going with) or -% standalone libraries only (for modularity?). - -The game engine is required to have an audio system with support for playing multiple -audio streams (i.e.~tracks or samples) simultaniously. Since writing a custom live -audio mixing engine is outside the scope of this project, this section compares +The game engine is required to have an audio system +\autocite[\ref{req:audio}]{crepe:requirements}. Since writing a custom real-time +audio mixing engine is outside the scope of this project\mref, this section compares various standalone audio engines that could be used in the engine. -% TODO: requirements first! +\subsection{Libraries} + +\Cref{tab:audio-engines} compares several standalone audio engine libraries that fit +\cref{req:audio,req:lib:license}. -% REQ ~ is cross-platform -% REQ ~ supports multiple audio formats (TODO: which) -% REQ ~ supports simultanious playback / mixing -% REQ ~ has an open-source license \begin{table} \centering \begin{tabular}{llc} \toprule \textbf{Library} & \textbf{License} & \textbf{API}\\ \midrule - miniaudio & MIT-0 & C\\ - YSE & EPL & C++\\ - SoLoud & Zlip/LibPng & C++\\ + miniaudio \autocite{lib:miniaudio} & MIT-0 & C\\ + YSE \autocite{lib:yse} & EPL & C++\\ + SoLoud \autocite{lib:soloud} & Zlip/LibPng & C++\\ \bottomrule \end{tabular} \caption{Audio engine library comparison} \label{tab:audio-engines} \end{table} -% TODO: ref https://miniaud.io/ -% TODO: ref https://www.attr-x.net/yse/ -Not considered further: +Other popular libraries that were researched but are unsuitable for this project +include:\noparbreak \begin{description} - \item[FMOD] is proprietary - \item[PortAudio] requires manual mixing + \item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license}) + \item[PortAudio \autocite{lib:portaudio}] Does not handle mixing \end{description} \section{Physics} diff --git a/scripts/reqs2tex.py b/scripts/reqs2tex.py index e5f063d..6984466 100755 --- a/scripts/reqs2tex.py +++ b/scripts/reqs2tex.py @@ -94,6 +94,9 @@ def convert(data): # skip deleted requirements (but process for make_id) reqs = [item for item in reqs if item[KEY.DELETED] == False] + # sort by label + reqs = sorted(reqs, key=lambda item: item[KEY.LABEL]) + return reqs def fmt_aux(data): diff --git a/sources.bib b/sources.bib index 50f5ead..6f5ce0c 100644 --- a/sources.bib +++ b/sources.bib @@ -13,38 +13,75 @@ } @misc{miro:scrum-board, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Scrum Board on Miro}, - url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Scrum Board on Miro}, + url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, + date = {2024-09-10}, } @misc{crepe:code-repo, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Code Repository}, - url = {https://github.com/lonkaars/crepe}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Code Repository}, + url = {https://github.com/lonkaars/crepe}, + date = {2024-09-10}, } @misc{crepe:docs-repo, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Documentation Repository}, - url = {https://github.com/lonkaars}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Documentation Repository}, + url = {https://github.com/lonkaars}, + date = {2024-09-10}, } @misc{crepe:docs-standard, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Documentation Standard}, - url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Documentation Standard}, + url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, + date = {2024-09-10}, } @misc{crepe:code-standard, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Code Standard}, - url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Code Standard}, + url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, + date = {2024-09-10}, } +@report{crepe:requirements, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Requirements}, + date = {2024-09-18}, +} + +@online{lib:miniaudio, + title = {miniaudio - A single file audio playback and capture library.}, + % author = {David Reid}, + url = {https://miniaud.io}, + urldate = {2024-09-18}, +} + +@online{lib:yse, + title = {YSE - cross-platform sound engine}, + url = {https://www.attr-x.net/yse}, + urldate = {2024-09-18}, +} + +@online{lib:soloud, + title = {SoLoud}, + % author = {Jari Komppa}, + url = {https://solhsa.com/soloud}, + urldate = {2024-09-18}, +} + +@online{lib:fmod, + title = {FMOD}, + url = {https://www.fmod.com}, + urldate = {2024-09-18}, +} + +@online{lib:portaudio, + title = {PortAudio - an Open-Source Cross-Platform Audio API}, + url = {https://www.portaudio.com}, + urldate = {2024-09-18}, +} -- cgit v1.2.3 From 395ef912d0b5d398874cc37021ea0e6c0e94f38a Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 18 Sep 2024 17:39:53 +0200 Subject: WIP research --- research.tex | 49 ++++++++++++++++++++++++++++++++++++++++++++++--- sources.bib | 6 ++++++ 2 files changed, 52 insertions(+), 3 deletions(-) (limited to 'sources.bib') diff --git a/research.tex b/research.tex index abfde3b..175c92b 100644 --- a/research.tex +++ b/research.tex @@ -206,11 +206,17 @@ for audio some options could be: FMOD, Wwise, or iirKlang The game engine is required to have an audio system \autocite[\ref{req:audio}]{crepe:requirements}. Since writing a custom real-time audio mixing engine is outside the scope of this project\mref, this section compares -various standalone audio engines that could be used in the engine. +various standalone audio libraries for suitability in the engine. + +\Cref{sec:audio:libs} details which libraries were considered, +\cref{sec:audio:benchmark} compares their performance, and +\cref{sec:audio:conclusion} concludes with a recommendation for most performant audio +library. \subsection{Libraries} +\label{sec:audio:libs} -\Cref{tab:audio-engines} compares several standalone audio engine libraries that fit +\Cref{tab:audio:libs} lists the standalone audio engine libraries that fit \cref{req:audio,req:lib:license}. \begin{table} @@ -225,7 +231,7 @@ various standalone audio engines that could be used in the engine. \bottomrule \end{tabular} \caption{Audio engine library comparison} - \label{tab:audio-engines} + \label{tab:audio:libs} \end{table} Other popular libraries that were researched but are unsuitable for this project @@ -235,6 +241,43 @@ include:\noparbreak \item[PortAudio \autocite{lib:portaudio}] Does not handle mixing \end{description} +\subsection{Benchmarks} +\label{sec:audio:benchmark} + +The same benchmark application was written for each of the libraries listed in +\cref{tab:audio:libs}. The application does the following:\noparbreak +\begin{enumerate} + \item Load a background track (Ogg Vorbis) + \item Load three short samples (WAV) + \item Start the background track + \item Play each sample sequentially while pausing and resuming the background track + \item Play all samples simultaniously + \item Stop all audio and exit +\end{enumerate} + +Each benchmark was profiled using \emph{perf} \autocite{tool:perf} and compared based +on total CPU and memory utilization. The results of these benchmarks are listed in +\cref{tab:audio:benchmark}. + +\begin{table} + \centering + \begin{tabular}{lr} + \toprule + \textbf{Library} & \textbf{???}\\ + \midrule + miniaudio &\\ + YSE &\\ + SoLoud &\\ + \bottomrule + \end{tabular} + \caption{Audio engine library benchmark results} + \label{tab:audio:benchmark} +\end{table} + +\subsection{Conclusion} +\label{sec:audio:conclusion} + + \section{Physics} \subsection{Introduction} diff --git a/sources.bib b/sources.bib index 6f5ce0c..33f3a2e 100644 --- a/sources.bib +++ b/sources.bib @@ -85,3 +85,9 @@ urldate = {2024-09-18}, } +@online{tool:perf, + title = {\texttt{perf:} Linux profiling with performance counters}, + url = {https://perf.wiki.kernel.org/index.php/Main_Page}, + urldate = {2024-09-18}, +} + -- cgit v1.2.3 From d8d57711c340ae58bf14946372fdffd9642532b5 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 18 Sep 2024 17:51:58 +0200 Subject: Described possible game engine structures --- img/DecoratorDesignPattern.png | Bin 0 -> 13528 bytes research.tex | 30 +++++++++++++++++++++++++++--- sources.bib | 23 +++++++++++++++++++++++ 3 files changed, 50 insertions(+), 3 deletions(-) create mode 100644 img/DecoratorDesignPattern.png (limited to 'sources.bib') diff --git a/img/DecoratorDesignPattern.png b/img/DecoratorDesignPattern.png new file mode 100644 index 0000000..8830a3d Binary files /dev/null and b/img/DecoratorDesignPattern.png differ diff --git a/research.tex b/research.tex index f62f736..052a5b2 100644 --- a/research.tex +++ b/research.tex @@ -53,9 +53,34 @@ layers are divided into the following categories:\noparbreak The above mentioned layers should be structured, somehow. One of the requirements is that the game engine's API uses a so-called gameObject (with one or more component(s)). -The gameObject is described in more detail at \cref{sec:Gameobjects/components}. ... +The gameObject is described in more detail at \cref{sec:Gameobjects/components}. + +There are multiple structures that could be used to structure a game engine. It's of +course possible to use inheritance. A major disadvantages of inheritance is that it's +not flexible. However, the provided class diagram of the game engine's API already +specifies that composition should be used (in stead of inheritance). So, let's take a +look at structures that use composition. + +The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to structure +the game engine. A gameObject's propperties/behavior is determined by one (or more) +components. The Decorator design pattern allows to modify an object's propperties/behavior +by adding one (or more) Decorators. The object that is modified, could be the gameObject and +the components could be the Decorators. This is not exactly the same as the required API, +but it's very close. A major disadvantage of such Decorator design pattern, is that the +interface of all components should be the same (they should share the same methods), because +the client (which is the scene in our case) can only call/reach the components through the +interface. This would require very general methods (at the interface), which might make the +programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorator} +\begin{figure}[H] + \centering + \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png} + \caption{Decorator design pattern \autocite{img:Decorator}} + \label{fig:decorator} +\end{figure} + +Another very popular design pattern, is the Entity Component System (\gls{ecs}). ... -\subsubsection{ECS} +\paragraph{ECS} A game engine must have the ability to keep track and update several game objects. To do this most game engines employ an \gls{ecs} model which uses modulair components to @@ -71,7 +96,6 @@ such as audio, position, or physics. To create diverse entities with specific functions: A scene can contain many different kinds of entities, each with different properties and functions. But no matter how different each entity is, it remains an entity. To assign properties and functions to entities, components are used. -% TODO: ref?entt There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based diff --git a/sources.bib b/sources.bib index d6b960b..e754959 100644 --- a/sources.bib +++ b/sources.bib @@ -76,3 +76,26 @@ url = {https://docs.unity3d.com/Manual/class-Transform.html}, date = {2024} } + +@misc{img:Decorator, + title = {Decorator Pattern Structure Diagram}, + author = {Refactoring Guru}, + url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png}, + date = {2024} +} + +@manual{man:DecoratorDesignPattern, + title = {Extension Object Design Pattern}, + author = {James Fawcett}, + organization = {Syracuse University}, + url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf}, + date = {2024} +} + +@manual{man:Decorator, + title = {Decorator Design Pattern}, + author = {Refactoring Guru}, + organization = {Refactoring Guru}, + url = {https://refactoring.guru/design-patterns/decorator}, + date = {2024} +} -- cgit v1.2.3 From 28d0733146aa3a8ba720bda20ff66ffa4cf4e64d Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 18 Sep 2024 19:30:48 +0200 Subject: added feedback to project plan --- plan.tex | 5 ++++- sources.bib | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) (limited to 'sources.bib') diff --git a/plan.tex b/plan.tex index 2f9cc94..147e49c 100644 --- a/plan.tex +++ b/plan.tex @@ -53,7 +53,10 @@ Finally, because the client does not want to dive deeply into the engine himself \subsection{Goal} -The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. In addition, a validation application is created to show and test the engine's features. +The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a validation application is created to show and test the engine's features. + +\subsection{Scope} +The requirements document \autocite{crepe:requirements} has several requirements with a MoSCoW `must', `should', `could' or `won't' priority to indicate the project's scope. \subsection{Result} diff --git a/sources.bib b/sources.bib index 50f5ead..8d96ce1 100644 --- a/sources.bib +++ b/sources.bib @@ -47,4 +47,11 @@ date = {2024-09-10}, } +@misc{crepe:requirements, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Requirements}, + url = {https://github.com/lonkaars/crepe/blob/master/requirements.pdf}, + date = {2024-09-10}, +} + -- cgit v1.2.3 From 7dc00a616e186bb8b02902e06b7cb38164acbbbd Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 18 Sep 2024 20:51:55 +0200 Subject: merge #15 --- img/decorator-design-pattern.puml | 62 +++++++++++++++++++++++++ img/theme.ipuml | 9 +++- research.tex | 93 ++++++++++++++++++++----------------- sources.bib | 97 ++++++++++++++++++++------------------- 4 files changed, 169 insertions(+), 92 deletions(-) create mode 100644 img/decorator-design-pattern.puml (limited to 'sources.bib') diff --git a/img/decorator-design-pattern.puml b/img/decorator-design-pattern.puml new file mode 100644 index 0000000..2bc406b --- /dev/null +++ b/img/decorator-design-pattern.puml @@ -0,0 +1,62 @@ +@startuml +!include theme.ipuml +skinparam style strictuml +skinparam Linetype ortho + +class Client +class Component <> { + + execute() + -- +} +class ConcComponent as "Concrete\nComponent" { + ... + -- + + execute() +} +class BaseDecorator as "Base Decorator" { + - wrappee: Component + + BaseDecorator(c: Component) + + execute() +} +class ConcDecorator as "Concrete\nDecorators" { + ... + -- + + execute() + + extra() +} + +hide Client members +hide circle + +Client --> Component +Component <|.. ConcComponent +Component <|.. BaseDecorator +Component <--o BaseDecorator +BaseDecorator <|-- ConcDecorator + +ConcComponent -right[hidden] BaseDecorator + +note right of Client + a = new ConcComponent() + b = new ConcDecorator1(a) + c = new ConcDecorator1(b) + c.execute() + // Decorator -> Decorator -> Component +end note + +note right of BaseDecorator::BaseDecorator + wrappee = c +end note + +note right of BaseDecorator::execute + wrappee.execute() +end note + +note right of ConcDecorator::execute + super::execute() + extra() +end note + +@enduml + +" referenced from diff --git a/img/theme.ipuml b/img/theme.ipuml index 88d183a..4e3613e 100644 --- a/img/theme.ipuml +++ b/img/theme.ipuml @@ -1,5 +1,10 @@ !theme plain -skinparam DefaultFontSize 14 +skinparam ClassAttributeIconSize 0 +skinparam ClassFontStyle bold skinparam DefaultFontName Inter +skinparam DefaultFontSize 14 +skinparam MaxMessageSize 200 +skinparam Nodesep 25 +skinparam Padding 2 +skinparam Ranksep 50 skinparam RoundCorner 0 -skinparam maxMessageSize 200 diff --git a/research.tex b/research.tex index 1ca5a2e..e07a428 100644 --- a/research.tex +++ b/research.tex @@ -52,8 +52,9 @@ layers are divided into the following categories:\noparbreak \subsubsection{Structures} The above mentioned layers should be structured, somehow. One of the requirements is -that the game engine's API uses a so-called gameObject (with one or more component(s)). -The gameObject is described in more detail at \cref{sec:Gameobjects/components}. +that the game engine's API uses a so-called gameObject (with one or more +component(s)). The gameObject is described in more detail at +\cref{sec:Gameobjects/components}. There are multiple structures that could be used to structure a game engine. It's of course possible to use inheritance. A major disadvantages of inheritance is that it's @@ -61,54 +62,62 @@ not flexible. However, the provided class diagram of the game engine's API alrea specifies that composition should be used (in stead of inheritance). So, let's take a look at structures that use composition. -The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to structure -the game engine. A gameObject's propperties/behavior is determined by one (or more) -components. The Decorator design pattern allows to modify an object's propperties/behavior -by adding one (or more) Decorators. The object that is modified, could be the gameObject and -the components could be the Decorators. This is not exactly the same as the required API, -but it's very close. A major disadvantage of such Decorator design pattern, is that the -interface of all components should be the same (they should share the same methods), because -the client (which is the scene in our case) can only call/reach the components through the -interface. This would require very general methods (at the interface), which might make the -programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorator} -\begin{figure}[H] - \centering - \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png} - \caption{Decorator design pattern \autocite{img:Decorator}} - \label{fig:decorator} +The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to +structure the game engine. A gameObject's propperties/behavior is determined by one +(or more) components. The Decorator design pattern allows to modify an object's +propperties/behavior by adding one (or more) Decorators. The object that is modified, +could be the gameObject and the components could be the Decorators. This is not +exactly the same as the required API, but it's very close. A major disadvantage of +such Decorator design pattern, is that the interface of all components should be the +same (they should share the same methods), because the client (which is the scene in +our case) can only call/reach the components through the interface. This would +require very general methods (at the interface), which might make the programming +harder \autocite{man:DecoratorDesignPattern,man:Decorator}. + +\begin{figure} + \centering + \includepumldiag{img/decorator-design-pattern.puml} + \caption{Decorator design pattern} + Source: \autocite{img:Decorator} + \label{fig:decorator} \end{figure} TODO: Add Extension Objects design pattern (if this is applicable)! -Another (very popular) design pattern to structure the game engine, is the Entity Component -System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, namely entities, -components and systems. Entities are just IDs. An entity is made out of a gameObject and one -(or more) components. Components are the classes that hold the data. The components determine -what kind of entity it is (e.g. a sprite, audio, and so on). Systems take care of the behavior -of the entities. Systems mainly read and write the enity's components data. The \gls{ecs} -clearly distinguishes the data (components) from the functionality (systems). -TODO: Continue this explanation (also add some diagrams to make the ECS more clear)! +Another (very popular) design pattern to structure the game engine, is the Entity +Component System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, +namely entities, components and systems. Entities are just IDs. An entity is made out +of a gameObject and one (or more) components. Components are the classes that hold +the data. The components determine what kind of entity it is (e.g. a sprite, audio, +and so on). Systems take care of the behavior of the entities. Systems mainly read +and write the enity's components data. The \gls{ecs} clearly distinguishes the data +(components) from the functionality (systems). + +% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)! There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most -popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based -on the amount of stars on GitHub. -\begin{table}[ht] - \centering - \begin{tabular}{ll@{\qquad}lr} - \toprule - \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License} \\ - \midrule - EnTT & Fast and reliable entity-component system & 10k & MIT \\ - Flecs & A Multithreaded Entity Component System & 6.3k & MIT \\ - EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT \\ - \bottomrule - \end{tabular} - \caption{Popular \gls{ecs} libraries \autocite{github:001}} - \label{tab:popularECSLibraries} +popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is +based on the amount of stars on GitHub. + +\begin{table} + \centering + \begin{tabular}{ll@{\qquad}lr} + \toprule + \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License}\\ + \midrule + EnTT & Fast and reliable entity-component system & 10k & MIT\\ + Flecs & A Multithreaded Entity Component System & 6.3k & MIT\\ + EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT\\ + \bottomrule + \end{tabular} + \caption{Popular \gls{ecs} libraries} + Source: \autocite{github:awesome-ecs} + \label{tab:popularECSLibraries} \end{table} -It is, of course, not necessary to use a library to implement an \gls{ecs} architecture. -However, it seems very hard to achieve the same performance as a library. \autocite{github:002} +It is, of course, not necessary to use a library to implement an \gls{ecs} +architecture. However, it seems very hard to achieve the same performance as a +library \autocite{github:ecsfaq}. \subsection{Conclusion} diff --git a/sources.bib b/sources.bib index e754959..bf04165 100644 --- a/sources.bib +++ b/sources.bib @@ -13,89 +13,90 @@ } @misc{miro:scrum-board, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Scrum Board on Miro}, - url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Scrum Board on Miro}, + url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, + date = {2024-09-10}, } @misc{crepe:code-repo, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Code Repository}, - url = {https://github.com/lonkaars/crepe}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Code Repository}, + url = {https://github.com/lonkaars/crepe}, + date = {2024-09-10}, } @misc{crepe:docs-repo, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Documentation Repository}, - url = {https://github.com/lonkaars}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Documentation Repository}, + url = {https://github.com/lonkaars}, + date = {2024-09-10}, } @misc{crepe:docs-standard, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Documentation Standard}, - url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Documentation Standard}, + url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, + date = {2024-09-10}, } @misc{crepe:code-standard, - author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, - title = {Crepe Code Standard}, - url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, - date = {2024-09-10}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Crepe Code Standard}, + url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, + date = {2024-09-10}, } -@misc{github:001, - author = {Sangjun Lee}, - title = {Awesome Entity Component System}, - url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file}, +@misc{github:awesome-ecs, + author = {Sangjun Lee}, + title = {Awesome Entity Component System}, + url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file}, date = {2023} } -@misc{github:002, - author = {Sander Mertens}, - title = {ECS FAQ}, - url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs}, +@misc{github:ecsfaq, + author = {Sander Mertens}, + title = {ECS FAQ}, + url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs}, date = {2023} } @manual{man:unityGameobjects, title = {GameObject}, author = {Unity Technologies}, - organization = {Unity}, - url = {https://docs.unity3d.com/Manual/GameObjects.html}, + organization = {Unity}, + url = {https://docs.unity3d.com/Manual/GameObjects.html}, date = {2024} } @manual{man:unityTransformClass, - title = {Transform Class}, - author = {Unity Technologies}, - organization = {Unity}, - url = {https://docs.unity3d.com/Manual/class-Transform.html}, - date = {2024} + title = {Transform Class}, + author = {Unity Technologies}, + organization = {Unity}, + url = {https://docs.unity3d.com/Manual/class-Transform.html}, + date = {2024} } @misc{img:Decorator, - title = {Decorator Pattern Structure Diagram}, - author = {Refactoring Guru}, - url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png}, - date = {2024} + title = {Decorator Pattern Structure Diagram}, + author = {Refactoring Guru}, + url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png}, + date = {2024} } @manual{man:DecoratorDesignPattern, - title = {Extension Object Design Pattern}, - author = {James Fawcett}, - organization = {Syracuse University}, - url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf}, - date = {2024} + title = {Extension Object Design Pattern}, + author = {James Fawcett}, + organization = {Syracuse University}, + url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf}, + date = {2024} } @manual{man:Decorator, - title = {Decorator Design Pattern}, - author = {Refactoring Guru}, + title = {Decorator Design Pattern}, + author = {Refactoring Guru}, organization = {Refactoring Guru}, - url = {https://refactoring.guru/design-patterns/decorator}, - date = {2024} + url = {https://refactoring.guru/design-patterns/decorator}, + date = {2024} } + -- cgit v1.2.3 From be63aadea11619a08878c25a26b7ccafc6174b53 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:10:43 +0200 Subject: added some feedback --- plan.tex | 32 +++++++++++--------------------- sources.bib | 7 +++++++ 2 files changed, 18 insertions(+), 21 deletions(-) (limited to 'sources.bib') diff --git a/plan.tex b/plan.tex index 147e49c..13c487d 100644 --- a/plan.tex +++ b/plan.tex @@ -1,13 +1,6 @@ \documentclass{projdoc} \input{meta.tex} -% @Jaro: Zie hieronder -% Version 0.0 seems not right -% I'm also missing a 'version table' -% Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers -% before the comma indicate versions ready for publication - \title{Project Plan} \version{0.1} @@ -18,19 +11,12 @@ \section{Background} This project is part of the fourth-year minor `Systems Programming in C++'. The minor -consists of several courses troughout 20 weeks, which create the basis for this -project. The project is focussed on building a game engine using the programming +consists of several courses throughout 20 weeks, which create the basis for this +project. The project focus is on building a game engine using the programming language C++. This document describes the plan of attack for the project. \section{Problem Definition} -% The assignments will be discussed with the project supervisor on specifics for this -% project. This will give the team the ability to direct the project. - -% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van -% background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu -% even uit gehaald en een nieuw kopje background toegevoegd. - \subsection{Problem Analysis} CodedFun Games is a small, single-person game company looking to scale up. The owner, @@ -45,7 +31,7 @@ user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. So far, the client has made all his games in Unity and is very fond of the structure. -Therefore, he wants the new engine to adhere to a similar structure. A simple +Therefore, the client wants the new engine to adhere to a similar structure. A simple requirements document is defined to specify how strictly this structure should be followed. @@ -62,6 +48,10 @@ The requirements document \autocite{crepe:requirements} has several requirements The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities. +\subsection{validation application} + +The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. + \section{Planning} The customer specified multiple deliverables throughout the 20 weeks of this project. Despite the fact that 20 weeks have been reserved for this project, the game will be delivered in week 17. Any delay/resit will take place between weeks 17 and 20. A rough planning can be found in \cref{tab:planning}. @@ -72,10 +62,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & Requirements document\\ + 7 & POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application, Research document, and Qualification - document\\ + 17 & Game engine, Validation application\\ \bottomrule \end{tabularx} \caption{Planning} @@ -100,6 +89,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro requirements. Lack of Team Collaboration: Insufficient collaboration among team members may hinder progress. \item[Lack of Team Collaboration] Within the team a lack of collaboration can result in miscommunication or delay in work. + \item[Falling out of specific team member] Within the team the scrum master and integrator have additional roles. If one or both members can not continue it can hinder progress of the project. \end{description} \subsection{Measures} @@ -113,6 +103,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro meetings, to check if the progress is within the scope, should be sufficient to decrease the risk. \item[Lack of Team Collaboration] Weekly team meetings will result in collaboration among team members and discussing what each other tasks is, will decease this risk. + \item[Falling out of specific team member] The scrum master can be taken over by any other team member. All tools (e.g. scrum board) are open to all members. The tasks of the integrator can be taken over by the team. Within GitHub the team as a whole has the same rights as the integrator. \end{description} \section{Documentation} @@ -128,7 +119,6 @@ This project consists of seven main documents:\noparbreak project, including timelines, milestones, roles, and responsibilities. \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. - \item[Research] Consists of all research related to this project. \item[Design] Describes the design choices, including architecture, user interface, and system components. \item[Qualification] Includes test cases, test plans, and quality measures to diff --git a/sources.bib b/sources.bib index 8d96ce1..31262fb 100644 --- a/sources.bib +++ b/sources.bib @@ -54,4 +54,11 @@ date = {2024-09-10}, } +@misc{crepe:validation-application, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Validation Application}, + url = {https://github.com/lonkaars/crepe/blob/master/Validation-Application.pdf}, + date = {2024-09-10}, +} + -- cgit v1.2.3 From 6f802231674685b9d1bb365d345c96aa15cdd311 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 14:47:03 +0200 Subject: Added the Extension Objects and ECS design patterns --- img/ECSBlockDiagram.png | Bin 0 -> 64822 bytes img/ECSComponentManager.png | Bin 0 -> 247012 bytes img/ExtensionObjects.jpg | Bin 0 -> 48639 bytes research.tex | 72 ++++++++++++++++++++++++++++++++++++-------- sources.bib | 32 ++++++++++++++++++-- 5 files changed, 90 insertions(+), 14 deletions(-) create mode 100644 img/ECSBlockDiagram.png create mode 100644 img/ECSComponentManager.png create mode 100644 img/ExtensionObjects.jpg (limited to 'sources.bib') diff --git a/img/ECSBlockDiagram.png b/img/ECSBlockDiagram.png new file mode 100644 index 0000000..4d36afa Binary files /dev/null and b/img/ECSBlockDiagram.png differ diff --git a/img/ECSComponentManager.png b/img/ECSComponentManager.png new file mode 100644 index 0000000..6602cd6 Binary files /dev/null and b/img/ECSComponentManager.png differ diff --git a/img/ExtensionObjects.jpg b/img/ExtensionObjects.jpg new file mode 100644 index 0000000..4807ff7 Binary files /dev/null and b/img/ExtensionObjects.jpg differ diff --git a/research.tex b/research.tex index ffba7ca..bec9471 100644 --- a/research.tex +++ b/research.tex @@ -24,7 +24,7 @@ A game engine is not the game itself but a platform with which games are built. should provide the functionalities with which the game is constructed. The purpose of a game engine is not to create data out of nothing. Instead, data is read, and the correlating features and effects are generated. However, the engine is also used to -create these files, referred to as ``assets.'' The game engine must be able to accept +create these files, referred to as ``assets''. The game engine must be able to accept a certain format of these assets---whether levels, sprites, or textures---and convert them into usable data. @@ -72,7 +72,7 @@ such Decorator design pattern, is that the interface of all components should be same (they should share the same methods), because the client (which is the scene in our case) can only call/reach the components through the interface. This would require very general methods (at the interface), which might make the programming -harder \autocite{man:DecoratorDesignPattern,man:Decorator}. +harder \autocite{man:DecoratorDesignPattern}. \begin{figure} \centering @@ -82,18 +82,66 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}. \label{fig:decorator} \end{figure} -TODO: Add Extension Objects design pattern (if this is applicable)! +The Extension Objects design pattern (as shown in \cref{fig:extension objects}) could +also be used to structure the game engine. The Extension Objects design pattern allows +to modify an object's propperties/behavior by adding one (or more) Extensions. The +object that is modified, could be the gameObject and the components could be the +Extensions. This is quite the same as the required API. An advantage is, that the client +(which is the scene in our case) can call all kind of different Extension's methods +(depending on the kind of Externsion, e.g. the method render() for the sprite Extension +and the method update() for the script Extension). In other words, the interfaces of the +different Extensions should not be the same. This is way more flexible than the Decorator +design pattern. A disadvantage is that the data and functionality are in the same class +(namely inside the Extion's methods), so it's not sepperated. Another disadvantage is +that the Extension Objects design pattern can be quite slow, because objects are scattered +in memory (and it is very hard to quickly get their memory address) +\autocite{man:ExtensionObjectDesignPattern, man:extionsionObjectsStackOverflow}. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ExtensionObjects.jpg} + \caption{Extension Objects design pattern} + Source: \autocite{img:extionsionObjects} + \label{fig:extension objects} +\end{figure} Another (very popular) design pattern to structure the game engine, is the Entity -Component System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, -namely entities, components and systems. Entities are just IDs. An entity is made out -of a gameObject and one (or more) components. Components are the classes that hold -the data. The components determine what kind of entity it is (e.g. a sprite, audio, -and so on). Systems take care of the behavior of the entities. Systems mainly read -and write the enity's components data. The \gls{ecs} clearly distinguishes the data -(components) from the functionality (systems). - -% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)! +Component System (\gls{ecs}) (as shown in \cref{fig:ECS Block Diagram}). The +\gls{ecs} is made out of three main subsystems, namely entities, components and +systems. Entities are just IDs. An entity is made out of a gameObject and one (or +more) components. Components are the classes that hold the data. The components +determine what kind of entity it is (e.g. a sprite, audio, and so on). Systems +take care of the behavior of the entities. Systems mainly read and write the enity's +components data. The \gls{ecs} clearly distinguishes the data (components) from +the functionality (systems), which is an advantage. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ECSBlockDiagram.png} + \caption{ECS design pattern} + Source: \autocite{img:ECSBlockDiagram} + \label{fig:ECS Block Diagram} +\end{figure} + +The \gls{ecs} is normally equipped with a component manager (as shown in +\cref{fig:ECS Component manager}). The component manager keeps track of the entities +(Alien, Player, Target, etc in \cref{fig:ECS Component manager}) and the connected +components (Position, Movement, Render, etc in \cref{fig:ECS Component manager}). +The component manager stores two lists (key value pairs). The key of the first list +is the ID of an entity, and the value of this list are the connected components. The key +of the second list is the component, and the value of this list are the entities that +have this component. These two lists make it possible to very quickly gather components +or entities. This makes the \gls{ecs} very fast, which is of course an advantage. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ECSComponentManager.png} + \caption{ECS Component manager} + Source: \autocite{img:ECSComponentSystem} + \label{fig:ECS Component manager} +\end{figure} + +Disadvantage: systems have to cummincate with each other... There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is diff --git a/sources.bib b/sources.bib index bf04165..e025492 100644 --- a/sources.bib +++ b/sources.bib @@ -84,7 +84,7 @@ date = {2024} } -@manual{man:DecoratorDesignPattern, +@manual{man:ExtensionObjectDesignPattern, title = {Extension Object Design Pattern}, author = {James Fawcett}, organization = {Syracuse University}, @@ -92,7 +92,7 @@ date = {2024} } -@manual{man:Decorator, +@manual{man:DecoratorDesignPattern, title = {Decorator Design Pattern}, author = {Refactoring Guru}, organization = {Refactoring Guru}, @@ -100,3 +100,31 @@ date = {2024} } +@misc{img:extionsionObjects, + title = {Extension Objects Diagram}, + author = {stackoverflow}, + url = {https://i.sstatic.net/GoIQ6.jpg}, + date = {2024} +} + +@manual{man:extionsionObjectsStackOverflow, + title = {Extension Object Design Pattern}, + author = {Supun Wijerathne}, + organization = {stackoverflow}, + url = {https://stackoverflow.com/questions/39331752/what-is-the-difference-between-extension-objects-pattern-and-adapter-pattern}, + date = {2016} +} + +@misc{img:ECSBlockDiagram, + title = {ECS Diagram}, + author = {Unity}, + url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/images/ECSBlockDiagram.png}, + date = {2024} +} + +@misc{img:ECSComponentSystem, + title = {ECS Component System}, + author = {Joel van der Werf}, + url = {https://i.imgur.com/VMQFIjW.png}, + date = {2024} +} -- cgit v1.2.3 From af0fa4a2ffce5f6a000c376cdadaec935dfc2fc4 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:22:50 +0200 Subject: Added sources --- research.tex | 7 ++++--- sources.bib | 17 +++++++++++++++++ 2 files changed, 21 insertions(+), 3 deletions(-) (limited to 'sources.bib') diff --git a/research.tex b/research.tex index 8a2ad7b..f9de6a5 100644 --- a/research.tex +++ b/research.tex @@ -131,7 +131,8 @@ The component manager stores two lists (key value pairs). The key of the first l is the ID of an entity, and the value of this list are the connected components. The key of the second list is the component, and the value of this list are the entities that have this component. These two lists make it possible to very quickly gather components -or entities. This makes the \gls{ecs} very fast, which is of course an advantage. +or entities. This makes the \gls{ecs} very fast, which is of course an advantage +\autocite{man:ECSComponentManager}. \begin{figure} \centering @@ -153,13 +154,13 @@ Systems should be aware of Collision Components and Rigidbody Components, as bot probably contain necessary information regarding physics simulation. It's best to see systems as “closed environments”. That is, they do not take ownership of entities nor components. They do access them through independent manager objects, which in turn will -take care of the entities and components life-cycle. +take care of the entities and components life-cycle \autocite{man:ECSExplanation}. Sometimes systems, entities and even components need to cummincate with each other. This might be very hard because systems, entities and components are more or less independent. One option is to use an event systems. A system, entity and component can raise an event and other systems, entities and components can react to that event. This is what makes the -\gls{ecs} a complicated system (disadvantage). +\gls{ecs} a complicated system (disadvantage) \autocite{man:ECSExplanation}. There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is diff --git a/sources.bib b/sources.bib index e025492..f48e8c3 100644 --- a/sources.bib +++ b/sources.bib @@ -128,3 +128,20 @@ url = {https://i.imgur.com/VMQFIjW.png}, date = {2024} } + +@manual{man:ECSExplanation, + title = {The Entity Component System C++ Game Design Pattern - Part 1}, + author = {GameDev.net}, + organization = {GameDev.net}, + url = {https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/the-entity-component-system-c-game-design-pattern-part-1-r4803/}, + date = {2024} +} + +@manual{man:ECSComponentManager, + title = {ECS Core API}, + author = {Unity Technologies}, + organization = {Unity}, + url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/ecs_core.html}, + date = {2024} +} + -- cgit v1.2.3 From 46d07c2c9e68597f3f6af76b4f8e837786781029 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 22 Sep 2024 19:25:02 +0200 Subject: finish audio research --- glossary.bib | 6 +++++ research.tex | 72 +++++++++++++++++------------------------------------------- sources.bib | 4 ++-- 3 files changed, 28 insertions(+), 54 deletions(-) (limited to 'sources.bib') diff --git a/glossary.bib b/glossary.bib index 8bf48ac..fda634f 100644 --- a/glossary.bib +++ b/glossary.bib @@ -46,3 +46,9 @@ long = {definition of done}, } +@abbreviation{poc, + short = {POC}, + long = {proof-of-concept}, +} + + diff --git a/research.tex b/research.tex index f3424c4..4ca3d3d 100644 --- a/research.tex +++ b/research.tex @@ -247,44 +247,14 @@ The game engine is required to have an audio system audio mixing engine is outside the scope of this project\mref, this section compares various standalone audio libraries for suitability in the engine. -\Cref{sec:audio:libs} details which libraries were considered, -\cref{sec:audio:benchmark} compares their performance, and -\cref{sec:audio:conclusion} concludes with a recommendation for most performant audio -library. - \subsection{Libraries} \label{sec:audio:libs} -\Cref{tab:audio:libs} lists the standalone audio engine libraries that fit -\cref{req:audio,req:lib:license}. - -\begin{table} - \centering - \begin{tabular}{llc} - \toprule - \textbf{Library} & \textbf{License} & \textbf{API}\\ - \midrule - miniaudio \autocite{lib:miniaudio} & MIT-0 & C\\ - YSE \autocite{lib:yse} & EPL & C++\\ - SoLoud \autocite{lib:soloud} & Zlip/LibPng & C++\\ - \bottomrule - \end{tabular} - \caption{Audio engine library comparison} - \label{tab:audio:libs} -\end{table} - -Other popular libraries that were researched but are unsuitable for this project -include:\noparbreak -\begin{description} - \item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license}) - \item[PortAudio \autocite{lib:portaudio}] Does not handle mixing -\end{description} - -\subsection{Benchmarks} -\label{sec:audio:benchmark} - -The same benchmark application was written for each of the libraries listed in -\cref{tab:audio:libs}. The application does the following:\noparbreak +After searching for libraries (search terms: `dynamic/adaptive audio', `real-time +audio', `audio library', `game audio engine'), several libraries were found. These +libraries were checked against the audio engine requirements +\autocite{crepe:requirements} and then tested by writing the same benchmark-style +\gls{poc} using the remaining qualifying libraries:\noparbreak \begin{enumerate} \item Load a background track (Ogg Vorbis) \item Load three short samples (WAV) @@ -294,28 +264,26 @@ The same benchmark application was written for each of the libraries listed in \item Stop all audio and exit \end{enumerate} -Each benchmark was profiled using \emph{perf} \autocite{tool:perf} and compared based -on total CPU and memory utilization. The results of these benchmarks are listed in -\cref{tab:audio:benchmark}. +Of these libraries the following were determined to be unsuitable for use in this +project due to various reasons:\noparbreak +\begin{description} + \item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license}) + \item[PortAudio \autocite{lib:portaudio}] Does not handle mixing + \item[miniaudio \autocite{lib:miniaudio}] With finished \gls{poc}, but dropped due + to very limited codec support (WAV, MP3 and FLAC only); Also does not have an + \gls{api} reference (only programming manual) + \item[YSE \autocite{lib:yse}] Attempted to write \gls{poc}, but CMake configuration + in repository is broken; This project seems to have been abandoned +\end{description} -\begin{table} - \centering - \begin{tabular}{lr} - \toprule - \textbf{Library} & \textbf{???}\\ - \midrule - miniaudio &\\ - YSE &\\ - SoLoud &\\ - \bottomrule - \end{tabular} - \caption{Audio engine library benchmark results} - \label{tab:audio:benchmark} -\end{table} +The only library that remained after these tests is SoLoud \autocite{lib:soloud}. It +is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}. \subsection{Conclusion} \label{sec:audio:conclusion} +Due to a severe shortage of libraries that fit our requirements, SoLoud appears to be +the most suitable (and only) audio library for use in this project. \section{Physics} diff --git a/sources.bib b/sources.bib index bb68067..adcfdd5 100644 --- a/sources.bib +++ b/sources.bib @@ -56,8 +56,8 @@ @online{lib:miniaudio, title = {miniaudio - A single file audio playback and capture library.}, % author = {David Reid}, - url = {https://miniaud.io}, - urldate = {2024-09-18}, + url = {https://miniaud.io/docs/manual/index.html}, + urldate = {2024-09-22}, } @online{lib:yse, -- cgit v1.2.3