diff options
| -rw-r--r-- | contributing.md | 2 | ||||
| -rw-r--r-- | glossary.bib | 6 | ||||
| -rw-r--r-- | img/ECSBlockDiagram.png | bin | 0 -> 64822 bytes | |||
| -rw-r--r-- | img/ECSComponentManager.png | bin | 0 -> 247012 bytes | |||
| -rw-r--r-- | img/ExtensionObjects.jpg | bin | 0 -> 48639 bytes | |||
| -rw-r--r-- | projdoc.cls | 3 | ||||
| -rw-r--r-- | reqs.toml | 16 | ||||
| -rw-r--r-- | research.tex | 253 | ||||
| -rwxr-xr-x | scripts/reqs2tex.py | 2 | ||||
| -rw-r--r-- | sources.bib | 95 | ||||
| -rw-r--r-- | style.md | 61 | ||||
| -rw-r--r-- | time.txt | 38 |
12 files changed, 348 insertions, 128 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/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/img/ECSBlockDiagram.png b/img/ECSBlockDiagram.png Binary files differnew file mode 100644 index 0000000..4d36afa --- /dev/null +++ b/img/ECSBlockDiagram.png diff --git a/img/ECSComponentManager.png b/img/ECSComponentManager.png Binary files differnew file mode 100644 index 0000000..6602cd6 --- /dev/null +++ b/img/ECSComponentManager.png diff --git a/img/ExtensionObjects.jpg b/img/ExtensionObjects.jpg Binary files differnew file mode 100644 index 0000000..4807ff7 --- /dev/null +++ b/img/ExtensionObjects.jpg diff --git a/projdoc.cls b/projdoc.cls index ee94835..16b1790 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -397,3 +397,6 @@ } \makeatother +% missing reference marker +\def\mref{\textsuperscript{\textit{\,ref?}}} + @@ -62,7 +62,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 = ''' @@ -70,3 +72,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 5340bf5..228f3ac 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,28 +72,98 @@ 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 - \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} \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 \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} + \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). +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} -% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)! +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 \autocite{man:ECSComponentManager}. + +\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} + +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 \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 @@ -115,12 +185,56 @@ 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}. \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} @@ -240,45 +354,50 @@ 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 -various standalone audio engines that could be used in the engine. +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 libraries for suitability in the engine. + +\subsection{Libraries} +\label{sec:audio:libs} + +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) + \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} + +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} -% TODO: requirements first! +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}. -% 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++\\ - \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/ +\subsection{Conclusion} +\label{sec:audio:conclusion} -Not considered further: -\begin{description} - \item[FMOD] is proprietary - \item[PortAudio] requires manual mixing -\end{description} +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} @@ -304,48 +423,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} diff --git a/scripts/reqs2tex.py b/scripts/reqs2tex.py index 31303ff..2bab558 100755 --- a/scripts/reqs2tex.py +++ b/scripts/reqs2tex.py @@ -75,7 +75,7 @@ def convert(reqs): reqs = [item for item in reqs if item[KEY.DELETED] == False] # sort by label - reqs = sorted(reqs, key=lambda req: req[KEY.LABEL]) + reqs = sorted(reqs, key=lambda item: item[KEY.LABEL]) return reqs diff --git a/sources.bib b/sources.bib index 126c3a8..a34f739 100644 --- a/sources.bib +++ b/sources.bib @@ -29,7 +29,7 @@ @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}, + url = {https://github.com/lonkaars/crepe-docs}, date = {2024-09-10}, } @@ -47,17 +47,53 @@ date = {2024-09-10}, } -@misc{crepe:requirements, +@online{lib:miniaudio, + title = {miniaudio - A single file audio playback and capture library.}, + % author = {David Reid}, + url = {https://miniaud.io/docs/manual/index.html}, + urldate = {2024-09-22}, +} + +@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}, +} + +@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}, +} + +@report{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}, + date = {2024-09-18}, } @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}, } @@ -98,7 +134,7 @@ date = {2024} } -@manual{man:DecoratorDesignPattern, +@manual{man:ExtensionObjectDesignPattern, title = {Extension Object Design Pattern}, author = {James Fawcett}, organization = {Syracuse University}, @@ -106,7 +142,7 @@ date = {2024} } -@manual{man:Decorator, +@manual{man:DecoratorDesignPattern, title = {Decorator Design Pattern}, author = {Refactoring Guru}, organization = {Refactoring Guru}, @@ -114,3 +150,48 @@ 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} +} + +@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} +} + @@ -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. - @@ -39,6 +39,8 @@ 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 +loek: 2024-09-22 2h15m docs :: research max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting @@ -60,6 +62,12 @@ max: 2024-09-16 1h researching self-made ECS possibilities max: 2024-09-16 1h30m researching ECS libraries max: 2024-09-17 1h30m fifth project meeting max: 2024-09-18 4h researching engine structure +max: 2024-09-19 20m sixt project meeting (part one) +max: 2024-09-19 1h30m third project lesson +max: 2024-09-19 45m sixt project meeting (part two) +max: 2024-09-19 20m researching facade design pattern +max: 2024-09-20 1h30m checking PvA (and fixing LaTeX) +max: 2024-09-20 3h researching engine structure wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting @@ -76,6 +84,13 @@ wouter: 2024-09-10 45m project videos wouter: 2024-09-10 40m second project lesson wouter: 2024-09-12 2h researching gameloops wouter: 2024-09-14 3h working on game loop poc +wouter: 2024-09-16 4h working on gameloop poc +wouter: 2024-09-17 1h30m fifth project meeting +wouter: 2024-09-18 3h finishing gameloop poc and starting event manager +wouter: 2024-09-19 15m project meeting +wouter: 2024-09-19 1h30m project meeting +wouter: 2024-09-19 45m project meeting +wouter: 2024-09-19 15m docs :: remove versioning niels: 2024-09-02 1h project meeting :: project kickoff niels: 2024-09-02 45m project meeting @@ -93,6 +108,15 @@ niels: 2024-09-11 3h researching the different resourches from unity niels: 2024-09-12 3h researching the best option for audio/sprites format and comparing it to sdl2 and sfml. niels: 2024-09-13 1h30m project meeting niels: 2024-09-13 10m weekly update +niels: 2024-09-16 1h30m Discussing with jaro about resource manager +niels: 2024-09-16 4h programming resource manager POC +niels: 2024-09-17 1h30m project meeting +niels: 2024-09-18 2h Continued with programming resource manager +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 @@ -112,6 +136,18 @@ jaro: 2024-09-10 1h project plan research physics jaro: 2024-09-13 1h project preparing meeting and reading review project plan jaro: 2024-09-13 1h30m project meeting jaro: 2024-09-13 30m weekly update - +jaro: 2024-09-16 1h30m Meeting Niels resource manager +jaro: 2024-09-16 2h requirements and sdl2 example +jaro: 2024-09-16 30m requirements +jaro: 2024-09-17 30m preparing meeting +jaro: 2024-09-17 1h30m meeting +jaro: 2024-09-17 30m requirements +jaro: 2024-09-17 2h30m class diagram +jaro: 2024-09-18 45m project plan (feedback) +jaro: 2024-09-19 1h30m research physics +jaro: 2024-09-19 30m project meeting +jaro: 2024-09-19 1h30m project lesson +jaro: 2024-09-19 1h project meeting +jaro: 2024-09-19 30m project plan and class diagram # vim:ft=cfg |
