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(-) 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(-) 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 40f485af1bdcc04477a2cfcb71c899d397d7c6e6 Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 18 Sep 2024 19:03:53 +0200 Subject: removed TODO and change some small typos --- plan.tex | 70 +++++++++++++++++++++------------------------------------------- 1 file changed, 23 insertions(+), 47 deletions(-) diff --git a/plan.tex b/plan.tex index 076ce11..2f9cc94 100644 --- a/plan.tex +++ b/plan.tex @@ -20,7 +20,7 @@ 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. +language C++. This document describes the plan of attack for the project. \section{Problem Definition} @@ -34,7 +34,7 @@ language C++. This document describes our plan of attack for the project. \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, +who is 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 @@ -49,29 +49,19 @@ 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}. +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 is 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 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}. \begin{table} \begin{tabularx}{\linewidth}{lX} @@ -106,21 +96,20 @@ weeks 17 and 20. A rough planning can be found in \cref{tab:planning}. \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. + \item[Lack of Team Collaboration] Within the team a lack of collaboration can result in miscommunication or delay in work. \end{description} \subsection{Measures} \begin{description} \item[Multiplatform] The team can switch any time to a single platform, so this - risk is metigated. + 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. + \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} \section{Documentation} @@ -177,8 +166,8 @@ Each project member will keep track of their own working hours and add them to t \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 +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} @@ -200,9 +189,9 @@ 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 -without valid reasons. It is essential that any concerns regarding a team +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 +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} @@ -212,9 +201,9 @@ 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 -on what has been accomplished, plans for upcoming work, and an overview of the +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 +on what has been accomplished, plans for upcoming work, and an overview of the team's overall progress. \subsection{Weekly Meetings} @@ -230,8 +219,7 @@ 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 starts using scrum after the initial phase, of structering the project, is finished. This phase is finished after a initial design of the product is made. \subsection{Scrum Board} @@ -257,26 +245,22 @@ 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. + \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} -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 +Each task or user story will be assigned user points, which indicate the relative size or complexity of the task. Examples of certain tasks will be available in the scrumboard. \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. +Burn Down Chart is shared in the weekly updates with the team. % 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 \autocite{crepe:code-repo} and @@ -284,16 +268,8 @@ documentation \autocite{crepe:docs-repo}, each in its own respective repository. keeps the documentation and code seperate, resulting in ordened and manageable repositories. -\subsection{Git New Branch} +\subsection{Code Standard and git workflow} -% 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}. +The code standard and the git workflow can be found in the contributing.md \autocite{crepe:code-standard}. \end{document} -- 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(-) 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 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(-) 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 3c6a635c6a8d38aae2284cbe744c060e765968a6 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:13:16 +0200 Subject: removed qualification --- plan.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/plan.tex b/plan.tex index 74f6a2b..54cc9d6 100644 --- a/plan.tex +++ b/plan.tex @@ -120,8 +120,6 @@ This project consists of seven main documents:\noparbreak functional and non-functional requirements. \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 -- cgit v1.2.3 From 23ceaf0edc1db82240740dbcc6d305d1e10726c8 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:37:07 +0200 Subject: changed role max --- plan.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plan.tex b/plan.tex index 54cc9d6..a1cbb15 100644 --- a/plan.tex +++ b/plan.tex @@ -145,7 +145,7 @@ reviewed and agreed to these terms. \item[Loek Le Blansch] Integrator \item[Wouter Boerenkamps] Project Member \item[Jaro Rutjes] Team Leader / Scrum Master - \item[Max Smits] Project Member + \item[Max Smits] Project Member / Product owner \item[Niels Stunnebrink] Project Member \end{description} -- cgit v1.2.3 From 34c2031eabff221f2d8928eae2de53ab1d75fa60 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:57:37 +0200 Subject: added class diagram from client --- figs.drawio | 761 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 761 insertions(+) create mode 100644 figs.drawio diff --git a/figs.drawio b/figs.drawio new file mode 100644 index 0000000..7c961d1 --- /dev/null +++ b/figs.drawio @@ -0,0 +1,761 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3 From 77c9588359df6a72097e46074b1ff14f80350285 Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Thu, 19 Sep 2024 20:02:17 +0200 Subject: Read through the plan.tex and fixed some issues --- plan.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/plan.tex b/plan.tex index a1cbb15..11d8d41 100644 --- a/plan.tex +++ b/plan.tex @@ -72,10 +72,10 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \section{Risks} -\subsection{Techincal Risks} +\subsection{Technical Risks} \begin{description} - \item[Multiplatform] The team works in both linux and windows, which poses a risk + \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. @@ -95,9 +95,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \begin{description} \item[Multiplatform] The team can switch any time to a single platform, so this - risk is metigated. + risk is mitigated. \item[Integration] By following standards and having an integrator, which checks - every pull request, this risk is minimilised. + every pull request, this risk is minimized. \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. @@ -209,7 +209,7 @@ project needs. % Information about how and when Scrum will be used in this project (using Miro). \section{Scrum (Miro)} -The team starts using scrum after the initial phase, of structering the project, is finished. This phase is finished after a initial design of the product is made. +The team starts using scrum after the initial phase, of structuring the project, is finished. This phase is finished after a initial design of the product is made. \subsection{Scrum Board} @@ -255,7 +255,7 @@ Burn Down Chart is shared in the weekly updates with the team. 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 +keeps the documentation and code separate, resulting in ordered and manageable repositories. \subsection{Code Standard and git workflow} -- cgit v1.2.3 From dcd17e39494010e3696f8e6b935e2da1d63ea37a Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 10:22:07 +0200 Subject: Corrected cappital letters --- plan.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/plan.tex b/plan.tex index 11d8d41..55707ce 100644 --- a/plan.tex +++ b/plan.tex @@ -47,7 +47,7 @@ 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} +\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. @@ -61,7 +61,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & POCs\\ + 7 & Some POCs\\ 10 & POCs and Design document\\ 17 & Game engine, Validation application\\ \bottomrule @@ -139,7 +139,7 @@ protocols for handling absences or delays, guidelines for addressing inconsisten participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project roles} +\subsection{Project Roles} \begin{description} \item[Loek Le Blansch] Integrator @@ -149,18 +149,18 @@ reviewed and agreed to these terms. \item[Niels Stunnebrink] Project Member \end{description} -\subsection{Work hours} +\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} +\subsection{Inconsistent Participation} Inconsistent participation will be addressed in a structured manner: @@ -258,7 +258,7 @@ documentation \autocite{crepe:docs-repo}, each in its own respective repository. keeps the documentation and code separate, resulting in ordered and manageable repositories. -\subsection{Code Standard and git workflow} +\subsection{Code Standard and Git Workflow} The code standard and the git workflow can be found in the contributing.md \autocite{crepe:code-standard}. -- cgit v1.2.3 From f55937c99dfdd08d89d3d7db24780d42b9f4ea75 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 12:03:16 +0200 Subject: Last minor changes --- plan.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/plan.tex b/plan.tex index 55707ce..c439aa7 100644 --- a/plan.tex +++ b/plan.tex @@ -38,18 +38,18 @@ 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. 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. +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 \emph{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} -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 \emph{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. +The \emph{validation application} \autocite{crepe:validation-application} is explained in a document where the features of the \emph{validation application} are linked to the user stories. \section{Planning} @@ -63,7 +63,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro 4 & Project Plan\\ 7 & Some POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application\\ + 17 & Game engine, \emph{validation application}\\ \bottomrule \end{tabularx} \caption{Planning} @@ -145,7 +145,7 @@ reviewed and agreed to these terms. \item[Loek Le Blansch] Integrator \item[Wouter Boerenkamps] Project Member \item[Jaro Rutjes] Team Leader / Scrum Master - \item[Max Smits] Project Member / Product owner + \item[Max Smits] Project Member / Product Owner \item[Niels Stunnebrink] Project Member \end{description} -- cgit v1.2.3 From 7102902f319d450253159a20da207b013d77f7ce Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 13:13:33 +0200 Subject: Replaced .puml with .png, since .puml was causing LaTeX errors --- research.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/research.tex b/research.tex index 5340bf5..ffba7ca 100644 --- a/research.tex +++ b/research.tex @@ -76,7 +76,7 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}. \begin{figure} \centering - \includepumldiag{img/decorator-design-pattern.puml} + \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png} \caption{Decorator design pattern} Source: \autocite{img:Decorator} \label{fig:decorator} -- 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 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 110ffb785a8eaf54106b92f49f008f0003193a2b Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:13:48 +0200 Subject: Continued ECS research --- research.tex | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/research.tex b/research.tex index bec9471..8a2ad7b 100644 --- a/research.tex +++ b/research.tex @@ -141,7 +141,25 @@ or entities. This makes the \gls{ecs} very fast, which is of course an advantage \label{fig:ECS Component manager} \end{figure} -Disadvantage: systems have to cummincate with each other... +Another aspect that makes the \gls{ecs} very fast, is that a system can handle all +components (of the same type) together at once. This is possible because all entities +are independent of each other. + +There are many ways of implementing the systems. Some say that each component type has +their own system. This interpretation of the systems does not take the interplay of +different component types, into account. A less restrictive approach is to let different +systems deal with all components they should be concerned with. For instance a Physics +Systems should be aware of Collision Components and Rigidbody Components, as both +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. + +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). 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 -- 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(-) 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 b8e3fcbe333558d3c0aa1ae36fe80c161d8202c1 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:34:19 +0200 Subject: Moved the section GameObject/Components upwards --- research.tex | 84 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/research.tex b/research.tex index f9de6a5..ed3d2cf 100644 --- a/research.tex +++ b/research.tex @@ -188,6 +188,48 @@ library \autocite{github:ecsfaq}. \subsection{Conclusion} +\section{Gameobjects/components} +\label{sec:Gameobjects/components} + +\subsection{Introduction} + +One of the requirements of our customer, is that the game engine's structure is +similar to Unity. The customer has created a class diagram of the game engine's API, +which is (of course) very similar to Unity. One of the most important parts of the +class diagram is a so-called gameObject (with several components). It's needed to +understand the exact meaning/function of these gameObjects, that's why this research +question arose. + +\subsection{Findings} + +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. \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, +and so on. Multiple (different) components can be assigned to a single gameObject +(e.g.~a sprite and an audioSource). + +Since we now know that a gameObject needs components to do something, it's obvious +that there should be a way to add components to a gameObject. Some components +(e.g.~the behaviorScript component) should also be able to reference to its +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. \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. \autocite{man:unityTransformClass} + +\subsection{Conclusion} + \section{Third-party Tools} \subsection{Introduction} @@ -371,48 +413,6 @@ Not considered further: \subsection{Conclusion} -\section{Gameobjects/components} -\label{sec:Gameobjects/components} - -\subsection{Introduction} - -One of the requirements of our customer, is that the game engine's structure is -similar to Unity. The customer has created a class diagram of the game engine's API, -which is (of course) very similar to Unity. One of the most important parts of the -class diagram is a so-called gameObject (with several components). It's needed to -understand the exact meaning/function of these gameObjects, that's why this research -question arose. - -\subsection{Findings} - -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. \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, -and so on. Multiple (different) components can be assigned to a single gameObject -(e.g.~a sprite and an audioSource). - -Since we now know that a gameObject needs components to do something, it's obvious -that there should be a way to add components to a gameObject. Some components -(e.g.~the behaviorScript component) should also be able to reference to its -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. \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. \autocite{man:unityTransformClass} - -\subsection{Conclusion} - \section{AI} \subsection{Introduction} -- cgit v1.2.3 From 444550c8fa8c88fcfe4c450012156051a0ea60c7 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:48:13 +0200 Subject: Added a TODO --- research.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/research.tex b/research.tex index ed3d2cf..ed34730 100644 --- a/research.tex +++ b/research.tex @@ -182,6 +182,8 @@ based on the amount of stars on GitHub. \label{tab:popularECSLibraries} \end{table} +TODO: Add library benchmark to find the best library. + 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}. -- cgit v1.2.3 From 375a551a1b59bfa34b3a419b2f00363afd4206ea Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 21 Sep 2024 14:50:19 +0200 Subject: merge #21 --- research.tex | 79 +++++++++++++++++++++++++++++++----------------------------- 1 file changed, 41 insertions(+), 38 deletions(-) diff --git a/research.tex b/research.tex index ed34730..1f55d70 100644 --- a/research.tex +++ b/research.tex @@ -83,18 +83,19 @@ harder \autocite{man:DecoratorDesignPattern}. \end{figure} 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) +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 \codeinline{render()} +for the sprite Extension and the method \codeinline{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} @@ -110,10 +111,10 @@ 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. +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 @@ -126,13 +127,13 @@ the functionality (systems), which is an advantage. 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 +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 -\autocite{man:ECSComponentManager}. +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 \autocite{man:ECSComponentManager}. \begin{figure} \centering @@ -146,21 +147,23 @@ Another aspect that makes the \gls{ecs} very fast, is that a system can handle a components (of the same type) together at once. This is possible because all entities are independent of each other. -There are many ways of implementing the systems. Some say that each component type has -their own system. This interpretation of the systems does not take the interplay of -different component types, into account. A less restrictive approach is to let different -systems deal with all components they should be concerned with. For instance a Physics -Systems should be aware of Collision Components and Rigidbody Components, as both -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 \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) \autocite{man:ECSExplanation}. +There are many ways of implementing the systems. Some say that each component type +has their own system. This interpretation of the systems does not take the interplay +of different component types, into account. A less restrictive approach is to let +different systems deal with all components they should be concerned with. For +instance a Physics Systems should be aware of Collision Components and Rigidbody +Components, as both 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 \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) +\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 @@ -222,7 +225,7 @@ 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 +to e.g.~scale a sprite. Other components eddit this information to e.g.~model gravity. \autocite{man:unityTransformClass} A gameObject can have one (or multiple) children gameObject(s). All children -- cgit v1.2.3 From aa80bd19d2242636ffb20bb7a384a97e436bd6dc Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 21 Sep 2024 15:13:38 +0200 Subject: update writing and code style --- contributing.md | 2 ++ style.md | 61 +++++++++++++++++++++++++++++---------------------------- 2 files changed, 33 insertions(+), 30 deletions(-) diff --git a/contributing.md b/contributing.md index db58388..46cfeca 100644 --- a/contributing.md +++ b/contributing.md @@ -17,6 +17,8 @@ other document. - Only environments indent the LaTeX source code - Insert a non-breaking space (`~`) after (Latin) abbreviations such as "i.e." or "e.g.". Never place a comma after either of these. +- Multiple references (both `\cref` and `\autocite`) should be done in a single + command (i.e. `\cref{fig:a,fig:b}` and `\autocite{source1,source2}`) # Banned practices diff --git a/style.md b/style.md index c518e7c..8dca81b 100644 --- a/style.md +++ b/style.md @@ -4,6 +4,28 @@ LaTeX commands and LaTeX source style requirements are detailed in a number of frequently used snippets that may be used as a cheat-sheet style reference. +# General rules + +- All documentation is written in U.S. English +- Section headers are in sentence case (i.e. only the first word and proper + nouns are capitalized) +- Section headers should not contain punctuation (e.g. no question marks, "or" + instead of a slash, etc.) +- Quotes are closed before punctuation marks. +- Do not use contractions, modal adverbs or rhetorical questions. + +# References + +- Citations are inserted before the full stop at the end of a sentence. +- When a library or piece of software is introduced in a document, reference + the project homepage using the bibliography. +- Direct quotations or paraphased text must be cited. +- Acronyms, abbreviations and jargon reference the glossary. +- All figures and tables must be referenced in the body text. Don't write + paragraphs that 'lead up' to figures, as this forces LaTeX to not break the + page between the paragraph and figure. +- Figures from third-party sources must be cited. + # Fonts The documents use the following fonts. All of these are free and open source, @@ -27,15 +49,18 @@ workshop and VimTeX. [texgyreschola-math]: https://www.gust.org.pl/projects/e-foundry/tg-math/download/index_html#Schola_Math [jetbrains-mono]: https://www.jetbrains.com/lp/mono -# Spelling +# Figures -- All documentation is written in U.S. English -- Section headers are in sentence case (i.e. only the first word and proper - nouns are capitalized) +Non-raster figures are preferred over rasterized figures (where applicable). +Please note that LaTeX does not support SVG images, and these need to be +converted to PDF (e.g. using `svg2pdf` on linux). + +Raster images should only be used when the source is already in a raster format +(e.g. for photos) or when otherwise impractical. -# Grammar +# Specific rules -## Comma And +## Comma and **In lists**, the last element is mentioned using the word 'and', *without* a comma. @@ -50,27 +75,3 @@ consistency. > > Action X was performed, and this had Y impact. -# Figures - -Non-raster figures are preferred over rasterized figures (where applicable). -Please note that LaTeX does not support SVG images, and these need to be -converted to PDF (e.g. using `svg2pdf` on linux). - -Raster images should only be used when the source is already in a raster format -(e.g. for photos) or when otherwise impractical. - -# References - -- When a library or piece of software is introduced in a document, reference - the project homepage using the bibliography. -- Direct quotations or paraphased text must be cited. -- Acronyms, abbreviations and jargon reference the glossary. -- All figures and tables must be referenced in the body text. Don't write - paragraphs that 'lead up' to figures, as this forces LaTeX to not break the - page between the paragraph and figure. - -# Document structure - -- Use `\section`, `\subsection`, `\subsubsection` and `\paragraph` to insert - headings. - -- cgit v1.2.3 From 153f7be519d18248461c315df647f743ff17d721 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 21 Sep 2024 15:14:17 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 43f70df..8b4931b 100644 --- a/time.txt +++ b/time.txt @@ -39,6 +39,7 @@ loek: 2024-09-19 15m project meeting loek: 2024-09-19 1h30m project meeting loek: 2024-09-19 45m project meeting loek: 2024-09-19 15m docs :: remove versioning +loek: 2024-09-19 30m PR merge and style guide update max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- 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(-) 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 From 9a05cb4acb4eb3304744be1b57809ad67466d9f4 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 22 Sep 2024 19:27:08 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 8b4931b..40b7c9f 100644 --- a/time.txt +++ b/time.txt @@ -40,6 +40,7 @@ loek: 2024-09-19 1h30m project meeting loek: 2024-09-19 45m project meeting loek: 2024-09-19 15m docs :: remove versioning loek: 2024-09-19 30m PR merge and style guide update +loek: 2024-09-22 2h15m docs :: research max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 7202e04b143e06d4411869c0cf77a7b9a8cc979b Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Sun, 22 Sep 2024 19:51:22 +0200 Subject: Today time update --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 40b7c9f..b989d53 100644 --- a/time.txt +++ b/time.txt @@ -116,6 +116,7 @@ niels: 2024-09-19 15m project meeting niels: 2024-09-19 1h30m project meeting niels: 2024-09-19 45m project meeting niels: 2024-09-19 15m PvA reviewing +niels: 2024-09-22 2h30m Adding spritesheet functionalities jaro: 2024-09-02 1h project meeting :: project kickoff jaro: 2024-09-02 45m project meeting -- cgit v1.2.3 From 1d641c7a907f02c16275aa6f5df1b2933f4af80e Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 25 Sep 2024 17:37:59 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index b989d53..3e027af 100644 --- a/time.txt +++ b/time.txt @@ -41,6 +41,7 @@ loek: 2024-09-19 45m project meeting loek: 2024-09-19 15m docs :: remove versioning loek: 2024-09-19 30m PR merge and style guide update loek: 2024-09-22 2h15m docs :: research +loek: 2024-09-24 1h45m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 762f422c2dbf93b88460f9f677ae124fee6643fc Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 25 Sep 2024 17:39:01 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 3e027af..68f3054 100644 --- a/time.txt +++ b/time.txt @@ -42,6 +42,7 @@ loek: 2024-09-19 15m docs :: remove versioning loek: 2024-09-19 30m PR merge and style guide update loek: 2024-09-22 2h15m docs :: research loek: 2024-09-24 1h45m project meeting +loek: 2024-09-25 3h implementation :: audio facade and API max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 7a385155a6b89077ec53b25efea10aa77b0a746d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 26 Sep 2024 14:07:45 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 68f3054..fc1394c 100644 --- a/time.txt +++ b/time.txt @@ -43,6 +43,7 @@ loek: 2024-09-19 30m PR merge and style guide update loek: 2024-09-22 2h15m docs :: research loek: 2024-09-24 1h45m project meeting loek: 2024-09-25 3h implementation :: audio facade and API +loek: 2024-09-26 2h project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 6329755a372d90985bda1cd164fae8d91d4a60c6 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 26 Sep 2024 15:50:58 +0200 Subject: remove meta.tex and just set defaults directly in projdoc.cls --- example.tex | 1 - meta.tex | 9 --------- plan.tex | 1 - projdoc.cls | 15 +++++++++++++-- requirements.tex | 1 - research.tex | 1 - timerep.tex | 1 - 7 files changed, 13 insertions(+), 16 deletions(-) delete mode 100644 meta.tex diff --git a/example.tex b/example.tex index 24c525b..9f36f59 100644 --- a/example.tex +++ b/example.tex @@ -1,7 +1,6 @@ \documentclass{projdoc} % if the document compiles too slow (likely due to many/large images), try compiling % with the [draft] option. this replaces all images with placeholders. -\input{meta.tex} \title{Example Document} diff --git a/meta.tex b/meta.tex deleted file mode 100644 index db7c7b1..0000000 --- a/meta.tex +++ /dev/null @@ -1,9 +0,0 @@ -\organization{Avans University of Applied Sciences} -\project{Project cr\^epe} -\author{% - Loek Le Blansch\and% - Wouter Boerenkamps\and% - Jaro Rutjes\and% - Max Smits\and% - Niels Stunnebrink% -} diff --git a/plan.tex b/plan.tex index c439aa7..a67598e 100644 --- a/plan.tex +++ b/plan.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Project Plan} diff --git a/projdoc.cls b/projdoc.cls index 16b1790..8a2c05d 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -1,6 +1,19 @@ \NeedsTeXFormat{LaTeX2e} \ProvidesClass{projdoc}[2024-09-03 class projdoc] +% project defaults +\makeatletter +\def\@project{Project cr\^epe} +\def\@organization{Avans University of Applied Sciences} +\def\@author{% + Loek Le Blansch\and% + Wouter Boerenkamps\and% + Jaro Rutjes\and% + Max Smits\and% + Niels Stunnebrink% +} +\makeatother + % based on article \LoadClass{article} @@ -160,9 +173,7 @@ % \maketitle format \makeatletter -\let\@project\relax \def\project#1{\def\@project{#1}} -\let\@organization\relax \def\organization#1{\def\@organization{#1}} \def\@maketitle{% \centering% diff --git a/requirements.tex b/requirements.tex index be0e103..6b4a87a 100644 --- a/requirements.tex +++ b/requirements.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \makeatletter \projdoc@description@leftmargin=2ex diff --git a/research.tex b/research.tex index 228f3ac..5aa7c4f 100644 --- a/research.tex +++ b/research.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Research document} diff --git a/timerep.tex b/timerep.tex index 7590217..34a30ea 100644 --- a/timerep.tex +++ b/timerep.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Time Report} -- cgit v1.2.3