Anyway, that was a kind of "rant" about some things that have been on my mind a lot. Kind of "out of character" compared to my other online posts, but figured I would write this down anyway if by some miracle that will help me figure things out better.

9/9

I also DO NOT like VSCode or really any other similar options I know of.

So the only options I can really think of would be something like Neovim or Emacs or something.
Either one would be different enough to not register as "VS with annoying differences" in my brain.

But I am unsure.

8/9

Then there's also another issue which is making things harder. Which is the fact that I am slowly migrating to Linux. The only major road block for me currently being:

'How do I transfer +10 years of Visual Studio muscle memory and knowledge to Linux alternatives?'

7/9

Which leads to there not being many options for me when limiting language choices to C# and C++. I'm sure there may be some engines out there, but I have not found any, so the only viable option is to roll my own engine which I have been wanting to create anyway.

6/9

Next, I want to like Godot, but it just doesn't work for me. I have some personal issues with how the core things in the engine work, including the "everything is a node" part, and those nodes being massive objects by my standards (Unity's objects aren't much better on that front though).

5/9

About engines I have tried and have not found to be for me.
First, Unreal Engine is an automatic no for me, I despised every second I had to use it during the one time I had to use it, I wouldn't use it even if I was going to be paid for it. I value my mental health more.

4/9

One of the important things to me about programming and dev in general is the ability to help my friends and others with issues etc and most of my knowledge is in Unity.

There are a lot of engines, but, I have yet to see a single one that would be a good enough replacement for Unity for me.

3/9

I mean I do have my own engine, but that is still FAR from functional, but that WILL be the thing I will do most of my own projects with later on.
But that also means, I likely won't be able to help with issues since a lot of people are moving/have moved to engines I don't use.

2/9

I was planning on making it a 16 bit ref to contain a bit of extra data for some sort of categorization like you mentioned, but that wasn't really relevant right now so I at least for now, to simplify implementing the system, I left it as just a byte. So it should be possible to implement later.

I would've liked to decouple the actual input definition (so keybinds etc) stuff too, but Unity does need to serialize that stuff.

The "Core" of the system is a C# library I wrote, which takes in an IInputProvider interface which is used to pass the current state of gamepads & keyboard etc.

Thank you! I'm real happy how this new Input System turned out, especially considering the old one I wrote years ago was such a nightmare to deal with in editor & in code.

I was going to use platform specific APIs to fetch inputs, but figured using Unity as said "API" was better in this case.

That's I think all of the important & interesting parts of the new Input System.

Also, I will be releasing this Input System on my Github at some point, also including the Localization System since it uses the same libraries I wrote too. I'll have to first create an example project for it though.

Another very good change is the way I serialize the mapped inputs to a file. Before I was only using Unity's built in JsonUtility which made the old Input System's JSON be a BIG mess. For the new one I manually write only what needed. Below are screenshots of both with extra info in alt text.

The Input Icon config in the old Input System was a really big mess too which I made miles better in the new system, below are screenshots of both with more info in the alt texts.

Another thing I got from my Localization System is the way we reference inputs in code & by in the editor. Instead of strings like I used before, the new system is assumed to have a max of 256 total inputs which means the ref can just be a single byte. This makes accessing inputs easy & super fast.

One thing I should note too is that the new Input System does use Unity's new Input System, but not in the way it's "supposed" to be used, instead I just pass keyboard & gamepad states to my Input System from Unity, making it so the system is cross platform while not changing how it should be used.

Just before writing the new Input System, I also had written my own Localization system which taught me a bit more how I should approach the configuration editor window in the new input system too. It might not still be the "best" but it's way better than the old input system's custom inspector.

The main reason I made the old input system was that Unity's own new Input System was still new & Unity's Input Manager is much not the greatest. At the time my Input System felt like a cool thing, but looking back, it's a real mess. Below is part of the input configuration of the old input system.