I knew I was missing something.

I realize that picking to use the MonoGame framework means I have to roll my own code for a lot of features. However, something just felt off with how I had my scene manager set up.

Well there was...

Introducing `Game Components` and `Drawable Game Components`

GameComponent: Is a game object that calls the Update function.

DrawableGameComponent Does the same thing but also calls the Draw.

This is awesome because I can `override` all of the normal `Game` object functions too. This also gives me access to the Game object itself which allows usage of `Game.Content` and `GraphicsDevice` in my objects.

Bye Bye Resource Manager

Needless to say this completely removed the need for my old scene manager. The only functionality I was working on that I still needed was a way to easily switch between scenes.

TargetPractice.cs

The following function in my `TargetPractice.cs` allows me to easily switch between scenes and handle the Content clean up I had not yet implemented in my old ResourceManager (That's what started this path btw).

public void ChangeScene(string nextScene)

   {
       Console.WriteLine($"Changing scene to {nextScene}");
       DrawableGameComponent scene;
       Components.Clear();
       switch (nextScene)
       {
           case "MainMenu":
               scene = new MainMenuScene(this);
               break;
           case "Logo":
               scene = new LogoScene(this);
               break;
           default:
               throw new InvalidEnumArgumentException();
       }
       Components.Add(scene);
   }

Currently default switch statement is throwing an error that doesn't make sense. That will be fixed soon. It is left over from when I was actually using an Enum for this process.

LogoScene.cs

From there we use this line in our scene to call the switch scene.

((TargetPractice)Game).ChangeScene("MainMenu");

- `((TargetPractice)Game)` Here we are casting the `Game` Object to the `TargetPractice` Type.

- `.ChangeScene("MainMenu")` This is just a standard function call.

How I got here

I will admit to get here I went down some rabbit holes. I was just attempting to set up resource cleanup. Not realizing I had a feature like GameComponent I wrote the now defunct classes to manage those aspects myself.

I realized I would need some sort of messaging system and I played around with delegates, actions, and even MediatR. None of them really worked and the system was getting more and more complex. I realized I was falling into the trap of over engineering.

Taking a step back I decided to delve into the MonoGame API documentation to see if I had missed something. Turns out very near the top of the document I had. As I read about the GameComponent system and how I could actually Add Components to the Game Object and they would be called I realized I had made some mistakes.

Scraping code you have spent hours crafting and testing is always hard. It is even harder when you thought that code was production ready. It is also really hard to admit you were wrong in your approach. However, one of the keys to being a successful software engineer is realizing when you are going down the wrong path.

So with a heavy heart I scrapped my fancy messaging system, scrapped my huge refactor, scrapped my `ResourceManager.cs` and `SceneManager.cs` and moved forward.

The code is all working now, I moved from over 10 files to 4 for more functionality.

Where do I go from here?

Well I am going to keep learning.

I will start adding settings into allow control of volume, screen size, and other stuff.

I will keep posting a daily dev blogs while on my learning journey. Once I move to my normal game I will move over to weekly or bi-weekly dev blogs. I view the purpose of the two as different. Learning is a daily activity so I have new and useful information each day. My games Dev Blog, while I am sure I will learn new things, is mainly to show off progress on the game.