\documentclass[aspectratio=169]{beamer} % pdfpc slides.pdf --notes=right % comment out to disable notes %\setbeameroption{show notes on second screen=right} \usetheme{metropolis} \usepackage{outlines} \usepackage{minted} \setminted{fontsize=\footnotesize,samepage=true} %\usepackage{xcolor} %\definecolor{codecolor}{HTML}{FFC300} \usepackage{csquotes} \title{VEGO-Engine} \subtitle{A student project} \author{Benedikt, Nicole} \begin{document} \maketitle \note{Tone: light hearted "What did we learn"} \begin{frame}{Outline} \tableofcontents \end{frame} \section{Context} \subsection{The team} \begin{frame}{Who are we?} \begin{itemize} \item Group of 5 people \item At the start of the project we had about 1 Semester of C++ Programming under our belt \item All shared a common interest in C++ Programming + a curiosity for game development \end{itemize} \end{frame} \subsection{The project} \begin{frame}{The assigment} \begin{itemize} \item "Development of a fantasy game console" (similar to Pico8) \item For simple Arcade like games (think Pong/Space Invaders) \item Goal was to teach how to manage and program within a larger project \end{itemize} \end{frame} \begin{frame}{Our interpretation and goals} \begin{itemize} \item Started out with a Minigame \item Realized we can split it into "Engine" and "Game Specific" Content \end{itemize} \Rightarrow We could then build on what we have while simultaneously having an implementation using the engine Smart right :D ?... \end{frame} \begin{frame} What awaited us was about the equivalent of trying to neatly sort single spaghetti strands next to each other after it has previously been generously mixed with some *juicy* pasta sauce. In other words, quite a messy endeavor... \end{frame} \begin{frame}{Roadmap} 3st Semester - learning SDL 4th/5th Semester - making the engine \end{frame} \section{Learnings} \subsection{Project environment} \begin{frame}{Baby's first \texttt{CMakeLists.txt}} \begin{itemize} \item On UAS: Only ever Make or no project setup \end{itemize} \end{frame} \begin{frame}{Visual Studio} Hate \end{frame} \begin{frame}{How the \_ do I import a library?} \begin{itemize} \item git-modules \end{itemize} \end{frame} \note[itemize]{ \item SDL is a library, static compile \item git-modules - do not bloat contributions } \subsection{ECS} % ECS slides, split into 3 sections \begin{frame}[allowframebreaks, fragile]{We made an ECS} Why an ECS - Entity Component System? \begin{itemize} \item Encourages reusable code \item "Plug-and-play" to add functionality \item We found a video tutorial series for it \item Simplified implementation: Entities propagate updates to the components \end{itemize} \end{frame} \note[itemize]{ \item Reusable code mainly on engine side, but also applies to game dev components \item plug and play mostly an advantage for game dev - i.e. "I want physics, here are physics" \item \enquote{video series} - tease issue of abruptly ending \item Components usually only have data, and are querried by the system (hence ecS) \item System part used for rendering } \begin{frame}[allowframebreaks, fragile]{We made an ECS - Implementation} \begin{minted}[linenos,autogobble,samepage=false]{c++} class Entity { private: std::vector> components; ComponentArray componentArray = {}; ComponentBitSet componentBitSet; public: void update(uint_fast16_t diffTime) const; template bool hasComponent() const { return componentBitSet[getComponentTypeID()]; } template T& getComponent() const { auto ptr(componentArray[getComponentTypeID()]); return *static_cast(ptr); } template T& addComponent(TArgs&&...mArgs) { T* c(new T(std::forward(mArgs)...)); c->entity = this; std::unique_ptr uPtr{ c }; this->components.emplace_back(std::move(uPtr)); componentArray[getComponentTypeID()] = c; componentBitSet[getComponentTypeID()] = true; c->init(); return *c; }; }; \end{minted} \end{frame} \note[itemize]{ \item appologize for formatting - for the sake of compactness \item TypeID: increments through all components - copied from video tutorial \item NOT beginner friendly } \begin{frame}[allowframebreaks, fragile]{We made an ECS - Usage} Very easy to use: \begin{minted}[linenos,autogobble]{c++} auto& projectile(this->manager->addEntity()); projectile.addComponent(pos.x, pos.y, 32, 32, scale); projectile.addComponent(texture, 4); // 4 => zIndex projectile.addComponent(range, speed, velocity, owner); projectile.addComponent(0.6f); \end{minted} \end{frame} \note{mention: this ease of use is our goal} \subsection{Memory Management} \begin{frame}[allowframebreaks, fragile]{Memory Management} \begin{minted}[linenos,autogobble]{c++} class Manager { public: Entity& addEntity() { Entity* e = new Entity(*this); std::unique_ptr uPtr{ e }; this->entities.emplace_back(std::move(uPtr)); return *e; } private: std::vector> entities; } \end{minted} \framebreak Does that solve memory management? Not quite: \begin{itemize} \item Missing separation of concern - manager also propagates update call \item Does not allow "saving" existing entities \end{itemize} Architectural issues like this are hard to solve this late in development However it does solve memory management\footnote{For \texttt{Entity} classes only, there are some leaks due to bad usage of the \texttt{SDL\_mixer} library} \end{frame} \note[itemize]{ \item \enquote{Perfect example of why our ECS is not ideal} \item scene management - would replace manager - however manager is too widely used - break API consistency \item classic example of good on surface level only for a beginner; transition to more such examples } \end{frame} %code example \begin{frame}[fragile]{Hello, World!} \begin{minted}[linenos,autogobble]{c} #include int main() { printf("Hello, World!"); return 0; } \end{minted} \end{frame} \begin{frame} \begin{enumerate} \item Eins \item Zwei \item Drei \end{enumerate} \end{frame} \end{document}