Hey there, and welcome to another devlog for Assembly RTS!
This week I worked on the in-game user interface.
I used Photoshop and photo-bashing to create this panel. And I used Adobe Illustrator to create the Icons.
You are probably already familiar with similar panels from other strategy games like the Command and Conquer franchise.
Besides the UI, I also created a dissolve effect for building materialization...
...and a screen-space build-radius shader, also using Unity's Shader Graph.
This is a screenshot of my initial version of the build-radius shader.
The newer version is more advanced but needs some additional wiring to display correctly.
It's actually a spaghetti solution, but it will get the job done. With better shader knowledge I would probably write a shader like this using Better Shaders instead: Something to learn in the distant future for sure.
Changing my focus from visuals back to game logic
Coming back to the in-game UI:
I had to remove the previous Shader Graph-based design for the energy bar entirely because it doesn't mesh well with the new photo-bashed panel. Let's take another look at it:
As you can see, the buttons on the UI panel are still blank, plus the mini map logic is still missing.
The problem is that the buildings will get a major overhaul in the future so I currently don't want to spend too much time on them. A lot may change for gameplay reasons.
I don't have enough vehicle and weapon variety to make icons from either.
In conclusion, creating icons for the buttons is likely a waste of time at this point.
I also came to realize this: Including UI in Steam screenshots is very important.
And now I'm no longer sure if I should proceed with my efforts to improve the visuals of Assembly RTS currently. As a reminder: I've been improving the visuals to take screenshots for the Steam page in the end. But I'm afraid that I simply can't deliver on this front (yet).
For now I decided to change my focus and to continue working on the game logic.
But please let me know what you think of this decision!
Is including UI elements in Steam screenshots really that important?
If the true answer is "no" I would continue my efforts towards getting a Steam page up and running as soon as possible!
Yet another code overhaul
I've already spent a considerable portion of my time working on Assembly RTS with adjusting already existing code (mostly with the goal of improving performance).
Regardless of that, I still think that this new change I'm about to tell you about will be worth it in the end.
Lately, as you may already know from a previous devlog, I've started using the Hot Reload tool for Unity to speed up my workflow. This tool isn't compatible with Unity ECS, the technology I've been using to write the majority of my gameplay-related logic.
A few weeks ago I also discovered how I can write high-performance code with less boilerplate and improved productivity.
Taking what I've learned into account and putting it into action, I've spent the past few days converting a considerable amount of my gameplay logic into array-based data-oriented code.
This has turned out great so far and it makes writing unit tests a breeze.
Even though GPT4 has been dumbed down as of late, it can still write a lot of unit tests very quickly for my array-based logic. Most of the time the new tests only require minor adjustments now.
It's all thanks to the relative simplicity as compared to my previous Unity ECS-based code base.
A large collection of unit tests will make my life as a programmer much easier:
Whenever I face a new bug I'll still be comfortable knowing that my code covered by unit tests aren't the root cause. This narrows the possible culprits down considerably.
Whenever I change code that is covered by unit tests, I'll see if I have broken anything right away.
(That is all assuming that these unit tests don't take too much time to maintain)
I'm using the burst compiler In my new data-oriented code for blazingly fast performance. I can even optimize my array-based logic further by using parallel processing where necessary, utilizing all 16/32 threads of your CPU at the same time.
In one instance this optimization made one of my slow systems speed up ten-fold from 5ms to 0.5ms!
In a lot of cases ChatGPT could even write these optimizations for me (unless it gets dumbed down even further). Fast iteration speed, robust code and blazingly fast execution speed- What's not to like?
