cppusergroup-vego-pres/slides.tex

\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}

\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
}

\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 \say{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<std::unique_ptr<Component>> components;
    ComponentArray componentArray = {};
    ComponentBitSet componentBitSet;
public:
    void update(uint_fast16_t diffTime) const;
    template <typename T> bool hasComponent() const {
        return componentBitSet[getComponentTypeID<T>()];
    }
    template <typename T> T& getComponent() const {
        auto ptr(componentArray[getComponentTypeID<T>()]);
        return *static_cast<T*>(ptr);
    }
    template <typename T, typename...TArgs> T& addComponent(TArgs&&...mArgs) {
        T* c(new T(std::forward<TArgs>(mArgs)...));
        c->entity = this;
        std::unique_ptr<Component> uPtr{ c };
        this->components.emplace_back(std::move(uPtr));

        componentArray[getComponentTypeID<T>()] = c;
        componentBitSet[getComponentTypeID<T>()] = 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<TransformComponent>(pos.x, pos.y, 32, 32, scale);
projectile.addComponent<SpriteComponent>(texture, 4); // 4 => zIndex
projectile.addComponent<ProjectileComponent>(range, speed, velocity, owner);
projectile.addComponent<ColliderComponent>(0.6f);
\end{minted}
\end{frame}
\note{mention: this ease of use is our goal}
\begin{frame}[allowframebreaks, fragile]{Memory Management}
\begin{minted}[linenos,autogobble]{c++}
class Manager
{
public:
    Entity& addEntity()
    {
        Entity* e = new Entity(*this);
        std::unique_ptr<Entity> uPtr{ e };
        this->entities.emplace_back(std::move(uPtr));
        return *e;
    }
private:
    std::vector<std::unique_ptr<Entity>> entities;
}
\end{minted}
\framebreak
Does that solve memory management? Not quite:

\begin{itemize}
    \item Missing separation of concern - manager also propagates update call
    \item What if I want to "save" existing entities
    \item Everything is an entity
\end{itemize}
\end{frame}

%code example
\begin{frame}[fragile]{Hello, World!}
\begin{minted}[linenos,autogobble]{c}
#include <stdio.h>

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}