We had a nice discussion over what project I should do, and several options were brought up, including

• TF for robotics
• PID for robotics
• Something from my game engine
• App Starter Kit

We decided on the website, and here is in general how it will be organized: 

The core will be FastAPI, deployed behind Uvicorn as a runner and Gunicorn as the process Manager, with NGinx as a reverse proxy. The web frontend will be React / Sass. The hope is to get a very good baseline for a project, with login, user pages, roles, OAuth login through Google, potentially chat rooms / forums protected by the roles if I get around to it.

This class was great, if admittedly I didn’t understand the command palate for the coding. I learned a lot about the electronics and how everything connected, but I’d be concerned trying to do something that complex again without more documentation, especially since it took a good while to find the proper docs. 

I did fine on the AP test, less good in the class. Didn’t focus much and just depended on my prior knowledge. I developed some good ideas and designs for other things, but of course those didn’t particularly pertain to the class. 

This was absolute chaos at the beginning of the year. The codebase was started completely from scratch, and it expanded into a system that was hard to organize. I would have liked to organize it into the semi-explicit format that I normally use, but beforehand the code got refactored, and I would be worried to do it again without complete knowledge and understanding.  

This is an overview of my vector hours, and an approximate for just my game engine work. If other things besides this are required, I can submit those as well. 

I designed and coded a game engine from scratch using C++, Vulkan, and several other low level libraries. The core premise of this engine was to show the simplicity and elegance of how game engine backend code could be organized, and also to showcase the ease and extensibility of a new style of game development code. This also allows for my game engine to become “more than just a game engine,” as submodules can be added or removed to fit perfectly into most projects. Instead of an unknown update time and main function, everything is called from the user’s main function, allowing for functionality far beyond what one can get with traditional layouts. Compared to Unity’s C# layout, or Unreal’s “All in for 3D”, my engine offers a way to still have the cleanliness of code, without removing any possible extensibility.

In my game engine's code, I wanted it to be easily extendable. So I created a method of creating submodules and dynamically linking them into the engine with inheritance. 

void Engine::instanceCreation(const char* appName, uint32_t appVersion, bool requestValidationLayers) {

    // loop through all submodules and set up the most basic of things. Initialization of objects should happen as early as possible
    // to ensure that there are enough cycles (9 in total triggered by this engine) so that other submodules that depend on it can initialize in time
    // since the order of submodules is not guaranteed. 
    for(Submodule* submodule : this->submodules) {
        submodule->beforeInstanceCreation(this);
    }

    InstanceBuilder instanceBuilder; // Custom class that holds all the parameters for instance creation when instanceBuilder.build() is called.
    for(Submodule* submodule: this->submodules) {

        // This allows for each submodule in turn to ensure that it has had its turn to adjust parameters as needed (extensions, layers, etc.)
        submodule->adjustInstanceParams(this, instanceBuilder);
    }

    // The core engine should run the overrides presented to it by the user last to ensure that there are no overridden settings (such as a submodule requiring a lower-than-minimum version)
    instanceBuilder.setAppName(appName);
    instanceBuilder.setAppVersion(appVersion);
    instanceBuilder.setEngineName(DRAGON_ENGINE_NAME);
    instanceBuilder.setEngineVersion(DRAGON_ENGINE_VERSION);
    instanceBuilder.requireAPIVersion(1, 2, 0);

    if(requestValidationLayers) {
        instanceBuilder.requestValidationLayers();
        instanceBuilder.useDefaultDebugMessenger();
        instanceBuilder.enableValidationLayer("VK_LAYER_KHRONOS_validation");
    }

    // Result is a template class to store either a correctly initialized object, or an error response as shown below. getValue() and getError() are the respective functions.
    Result<Instance> instanceResult = instanceBuilder.build();
        
    if(!instanceResult) {
        throw fmt::format("Failed to create Vulkan instance. Error: %1%\n", instanceResult.getError().message);
    }
    this->instance = instanceResult.getValue();

    for(Submodule* submodule : this->submodules) {
        submodule->afterInstanceCreation(this);
    }
}

Overall, there are 3 sections of this, but this piece is in regard to the builder classes that took a lot of research until I eventually adopted the style of Vk-Bootstrap. (https://github.com/charles-lunarg/vk-bootstrap) So far it works perfectly fine. Next will probably be extending out my classes for the PhysicalDevice and Device to produce a load balancing mechanism for queues.