Quaxum and Unity! 

I wanted to take some time to share thoughts and experiences I have had working on this project with Unity and C#. It's been a couple months on this project so I thought it would be a good time to share some hardships even with a project this small in scope. Because Quaxum and Unity are united it such a interwoven marriage of love and hate , that the fights and arguments though short, are worthy to talk about and explore. 

The hardest part of working on this project has been the little idiosyncrasy with unity. There is always some little issue that pops up when you are doing anything. Like, importing a huge sprite sheet. Normally, I never worry about the size of the sheet because I never go over it. But when I am animating these 30 frame backgrounds, the size is larger than the standard. Which results in the blurry sprite. And if you are not aware of why, it would be a long process to try and figure out what is causing this. Thankfully, I remembered there was a size setting and after doing the math, realized I would just need to increase it. But I didn't realize that right away. The blurred planet background with the shooting meteor is blurring because of this. And it's a happy little accident, I actually like the aesthetic of that one. But the ocean one looked horrible which is what had me start troubleshooting the issue. It's these little things that cause the most issue with troubleshooting and bugs, not so much the coding. Which is opposite of what most people would think.

Another issue is learning how to make C# work in a non complicated way. No, this isn't contradictory to my previous statement, the code can work most of the time simply. But there are times where code can bloom to a complicated level if you read online and don't investigate yourself.

The code needs to be simple and not full of complex math, patterns, bloat, or functions for simple actions. Too many times online something simple is told to be done in a complicated way that really does way too much for something as simple as rotating a sprite.
My example, for the dart obstacles that spawn, I wrote code that is supposed to point the object at start to the player, Well, many funny iterations later, I ended up dividing the start position by the player potion and got some decent results. A simple 3 lines of code got really good results but then another issue popped up with Unity.

Problem is, this is a pixel 2D game and not everything works math wise at this scale. This is one of the down sides of Unity for 2D Pixel game and another little idiosyncrasies, there is no pixel units, only Unity units. Which is very confusing to understand. You set the PPU (Pixel Per Unit) which is how you scale the pixels to the Unity unit. But, what is the measurement of a Unity unit? There is very little information online that explains it and converting the PPU to a different number other than the default 100 has caused a crap ton of issues for me. So I stick with 100.  This of course requires you to really tinker with formulas to get results that scale to your game. With Godot there are already pixel units for you. Makes it a little easier to code.

And as every Unity developer knows, Unity will slow way down the longer you leave it open. But, even a restart sometimes will still cause it to hang. Recently, I restarted it and despite being fresh, it hung for 30 minutes! And it did this 3 more times! Finally it started working again but I have no clue why it decided to hang. And this leads into a bigger issue.

Working with Unity can slow down the progress of development. With Godot the built in IDE and GDscript language doesn't slow down when you are saving code. With C# and Unity, it does. Even simple save of a comment will cause the recompile and that takes time. Time that compounds when you are rapidly fixing issues. Most of my development time is waiting for Unity to compile the code after I save it, and then waiting for it launch so I can test it. This can turn into hours of wasted time a day depending on how long Unity has been open. So frequent restarts of Unity is sometimes needed just to keep working on your project with less wasted time. It is a huge issue with Unity.

To bring this discussion to a close, I want to point out some positives as well between Quaxum and Unity. Compared to Godot, I can rapidly prototype and implement features for Quaxum. Simply because I understand C# better and how Unity does work. I enjoy the work flow in Unity and it allows for fast development and organization of assets. C# is wonderful to work with for the most part. I love the prefab system. I have all of my prefabs organized in folders. Dragging and dropping into the scene or inspector is easy and intuitive. It's probably one of my favorite parts of Unity. All I have to do is create and object, writer the scripts for it, drag the components I need and make it a prefab. Then I now have a premade object I can do whatever I want with. 

Overall, like every marriage, there is a constant flux between fighting with and working with eachother. And Quaxum and Unity has been the embodiment of that love and hate.