February: 12

Notes

2025

Market Trump Tar-Rifts

• 03:56PM

  The term that would best describe these tariffs, aka tar-rifts, where they are just a tool to cause chaos.

Cache Manager

• 04:21PM

  The CacheManager would be structured similar to our other node-base, with the focus of moving the ResourceCache out of the Maiky and into this manager. I am wondering if the ShaderCache could just be broken down and turned into a shader manager, hmm.

  This is what I am thinking the basic structure would look:

#[derive(GodotClass)]
#[class(base = Node)]
pub struct CacheManager {
    base: Base<Node>,
    texture_cache: ResourceCache<Texture2D>,
    canvas_layer_cache: ResourceCache<CanvasLayer>,
    ui_cache: ResourceCache<Control>,
    audio_cache: ResourceCache<AudioStream>,
    shader_cache: Option<Gd<ShaderCache>>,
}

• 06:38PM

  To test the windows build, we will be using this command:

./kbve.sh -nx rust_godot_towerdefense:build-windows

Keeping this in the notes, so that I can switch over to it easily.

FoodShoppin

• 06:27PM

  Just came back from food shipping and picked up two boxes of the most fire / epic mangoes! These mangoes seem to come from Peru and have the perfect balance of sweetness and juice. Anyhow, back to the grind I go.

• 08:01PM

  Took some of the fresh green peppers and tomatoes, made a ramen soup that felt so delicious! For the green peppers, I boiled half of them with the water and then quickly grilled the other half, giving a wombo combo type effect to that veggie.

MusicManager with CacheManager

• 08:06PM

  After making sure the new CacheManager compiles, the music.rs file can be the first to test it out. In the file, we can drop the effect_cache and sfx_cache, since both them will be just stored inside of the AudioStream cache. Before in the music.rs:

  // New Audio Cache!
  audio_cache: ResourceCache<AudioStream>,

  // Dropping these:
  effect_cache: HashMap<String, Gd<AudioStream>>,
  sfx_cache: HashMap<String, Gd<AudioStream>>,

  // Side-Note: These HashMaps were from the std::collections::Hashmap, which we are also dropping because of the mutex concerns.

  // ++ Future Update

  // Dropping these

  global_music_volume: f32,
  global_effects_volume: f32,
  global_sfx_volume: f32,

  // During the init() or ready(), we will link the CacheManager from the GameManager but while we have that ref, we can also link the pointer to the UserDataCache.

This gives us the read-heavy hashmap as a reference and makes it easier to continue down the path of multi-threading. Okay, so drop those two maps and then pull in the CacheManager into the MusicManger, but only once upon the init or ready function. Since the CacheManager gets built inside of the GameManager, we can reference it from the parent, just like how we are doing it in Maiky. Right when we grab the GameManager aka its parent, we can also grab the UserDataCache because we will need that for the user’s control of audio.

Then the final volume value will just come from the UserDataCache, acting as a source of truth for it all. In the future, we could also scope extend out into the supabase integration, allowing the user to cross-platform save their settings BUT I feel like that is an over reach. We really have no reason to save data like that, but it makes sense to maybe have it so that certain core features do get saved in a remote database.

Oh boi, I was wrong, it seems that it would make more sense to just reference the GameManager, then use that reference to grab the CacheManager and the UserDataCache. That makes more sense, hmm, we are splitting the UserDataCache and the CacheManager, one concern that I had was what if we also move the UserDataCache into the CacheManager but its not worth it. As of right now, we have three different cache systems in play, one is for the static objects that we will hold in the CacheManager, then we have the UserDataCache, which is for the user-data, this will have some changes and here and there. Finally the 3rd instance of a cache is through the ClockMaster aka the timer.

Making some progress on this front, migrated the music.rs into the managers module as music_manager. I did not get a chance to drop the globals yet, I will have to loop back around to handling those once I get the audio moved over.

// Raw GD Function - Proof of Concept

#[func]
pub fn insert_into_audio_cache(&self, key: GString, audio_stream: Gd<AudioStream>) {
    self.audio_cache.insert(&key.to_string(), audio_stream); // Key -> to_string -> to_str
}

Well, hmm, wait, since its already a ResourceCache<T> and we are calling this all within the Rust logic, we could just skip the #func creation and handle it all internally through rust. Granted, having the helper functions there would make it easier on the GDScript side to interact with the audio files, but for now, we should just focus on the Rust-internal code. This is because if we need to change anything, then we would have to also make sure that the #func have to be changed too, thus, we wait until a standard is built around it. All of the moving of files is getting a bit confusing for me to keep track of.

2024

Unity

After finishing up my morning work session, I am going to continue working on my the unity game! Ugh character selection and the character handler, oh boy.

This is how our Engine Initalizer looks right now:

using KBVE.Services;
using UnityEngine;

namespace KBVE.Engine
{
  public class EngineInitializer : MonoBehaviour
  {
    void Awake()
    {
      InitializeServices();
    }

    private void InitializeServices()
    {
      DontDestroyOnLoad(gameObject);

      var servicesInstance = KBVE.Services.Services.Instance;

      //  Register AuthenticationService
      var authService = gameObject.AddComponent<AuthenticationService>();
      servicesInstance.RegisterService<IAuthenticationService>(authService);

      //  Register SceneLoaderService
      var sceneLoaderService = gameObject.AddComponent<SceneLoaderService>();
      servicesInstance.RegisterService<ISceneLoaderService>(sceneLoaderService);

      //  Register UserDataService
      var userDataService = gameObject.AddComponent<UserDataService>();
      servicesInstance.RegisterService<IUserDataService>(userDataService);

      //  Register APIRequestService
      var apiService = gameObject.AddComponent<APIRequestService>();
      servicesInstance.RegisterService<IAPIRequestService>(apiService);

      //  Register CameraService
      var cameraService = gameObject.AddComponent<CameraService>();
      servicesInstance.RegisterService<ICameraService>(cameraService);

      //  Register Weather
      var weatherService = gameObject.AddComponent<WeatherService>();
      servicesInstance.RegisterService<IWeatherService>(weatherService);
    }
  }
}

The current design plan is a hybrid of service oriented architecture and event driven architecture. We split the two types into different namespaces, KBVE.Services and KBVE.Events, SOA vs EDA!

To add a service on the Initalizer, we just throw in these two lines, for example adding the Entity Service.

  //  Register EntityService
  var entityService = gameObject.AddComponent<EntityService>();
  servicesInstance.RegisterService<IEntityService>(entityService);

Next we need to register the clock service, which will represent the global tick.

  //  Register ClockService
  var clockService = gameObject.AddComponent<ClockService>();
  servicesInstance.RegisterService<IClockService>(clockService);

I believe we have enough of the base services to move forward with the StartZone!

Before I get started on the next update, I want to make sure everything builds and that the rolling updates via the cicd pipeline works. We will move everything up from the alpha branch to the beta branch, after it builds, we can then shift it up to main for a release.

Over the weekend, I was trying to test case multi agents working on the repo, there were some minor issues regarding them not isolating the changes and throwing a ton of git diffs. Uhh, long story short, either I need to find a way to resolve the git cherry picks OR really isolate the agents on where they can work, which needs to be done automatically as well.

I am thinking that we we could also move the KBVE namespace into its own nuget package and then call it within our application, but that will be for a later time.

The character section could be split into a couple different components, hmm, thinking it through, it might make more sense

AutoReview

During the pipeline roll out, it seems that the auto review passed on 3 of the test cases but faild on the remaining 7.

I actually think the failure in the test case was on my end, I need to adjust the test casing again, which will be easier with finish products to test against.