The engine for Dine N Bash heavily incorperates the ECS pattern. While not the as performant or complex as many implementations, it still allows our game to run incredibly efficiently. Entities are simply tracked indexes that become stored inside component containers, which systems can read and modify.

The graphics implementation is designed specifically for our use case, and the ease of use for others. While not the most efficient for some tasks, it lays the groundwork for easy entity manipulation without worry. It is implemented in OpenGL 4.3, and GLFW.

The 2D renderer has most of the expected objects, including Shader, Texture,  and Mesh objects along with a Graphics Component to allow entities to render. The real magic is the Material and EntityBuffer objects. 

The base structure of the Material object is to specify the Shader, Texture, and Layer that will be rendered to. Whenever you want to draw an object with the Material, you provide a Mesh along with any data required by the shader program. Instead of drawing it directly to the screen, the necessary information required to draw will be stored within the material for later use.

The EntityBuffer is simply a OpenGL buffer that stores necessary information for all calls made through a material. This means that every frame, all of the Materials provide the EntityBuffer with every draw call it has been given. As Materials provide data to the EntityBuffer, they are returned indices that they pull from to render.

Once all of the entity data is sent to the GPU, the Materials (in draw order) run instanced draw commands using their Texture, (shader) Program, and indices into the EntityBuffer. 

The implementation for this system is fairly rudimentary. Some details:

• Every draw call in the entire game (other than the editor) is instanced. The computation required for rendering objects that share the same material is very low. 

• This implementation provides no optimizations for any objects that do not change, or mutate specifically on the GPU. Fortunately, there are very few entitles in our engine that are in this category.

• This implementation requires a lot of data copying. The pipeline goes:
  Entity Components --> Materials --> CPU Entity Buffer --> GPU Entity Buffer
  This happens every single frame of the game, and is a large bottleneck. Though this may be the case, we still have the ability to reach incredibly high framerates. 

While many parts of this renderer are great, most (if not all) are based on specific assumptions that we could make due to the nature of our game. This renderer would not be great for general purpose uses, but for small games with few static objects, this renderer fits our needs perfectly.

Our editor is created using Dear ImGUI, a C Immediate Mode GUI library. From it comes a incredibly easy to use and robust set of GUI tools, including the ability to create docking windows.

Existing windows and features in the engine include:

• An object property window that allows for quick access to data. It supports the ability to load custom types, and has a very fleshed out entity window.

• A game render window, which allows you to interact with and view the game as it runs in the background.

• Toolbar with an FPS counter, Entity counter, mouse position display, and menus to open windows as well as other toggles.

• Scene window to load, unload, and modify currently loaded scenes

• Entity window to display entity states, open the entity property editor, or remove specific entities

• File window to browse and open specific scene and archetype files

• Archetype window to view and modify all archetypes loaded into the engine

• Hierarchy window to see the parentign of all entities within scenes

• Edit mode, which allows you to click on entitles to open their property windows, and drag the camera around

• Collision debug drawing toggleable from the toolbar

• Timestep scaling, allowing for time to be scaled up and down as needed

The deserialization system in the engine is far too complex, with way too many moving parts to be my proudest work. What did end up coming out of it was something that worked *mostly* efficiently, with some quirks that did not get completely sorted out. The deserialization system will be from here on out referred to as the Archetype System, as that is how it is labeled in the engine.