Thank you all. Another shot, this time of Level 1.
Yes, I did get sucked into the allure of Godot 4 pre-alpha (GDscript enhancements, instance uniforms, SDFGI, ect...) and tried to get a new version of the game going there (at the least I wanted a running start when it became production-ready), but as the waiting game turned into months and then years (not to mention usability cratering from time to time due to heavy development), I now figure I should just convert it when it is time like many others will end up doing with their projects.
There are a number of things here to note.
1). I realize I needed to learn to trust the systems given to me by Godot itself more instead of trying to act as mr. sophisticated rolling my own systems. This means less breakage in general (as Godot is very stable compared to the general bugginess of game creation products) and possibly better performance. This also means making better use of features like how the UI system can automatically adjust to the screen resolution (which also means actually learning more features, I tend to have a knack for being quite slow in the discovery of existing features, which has been the case for nearly 20 years now with Blender and other apps.). Another thing is that the latest iteration will finally ditch the numbers for levels and just have them referred to by their names, the first iteration just used linear numbers and the second iteration saw me discover packedScene exports, now the levels in the level folder will have actual names and the global script will use a dictionary to track store their specific data throughout the game (as opposed to a simple array).
In short, Godot as your tool of choice is smarter than you think, don't doubt its ability to handle things for you.
2). Automate the trivial things when possible, the gems and collectables have a tendency to float, and I realized with the Godot 4 attempt that I could automate with GDscript (using an exported bool) while they sit on the ground (by way of page down) in the editor. It even affects the visuals like you see in the shots (noting the automated texture coordinates). As a consequence, I am using Godot's easy-to-learn shader API instead of the visual shader nodes (as things like blended mapping is a lot easier to set up and would otherwise be impossible to do without creating spaghetti).
3). The robot is largely created with joints and physics in mind, so actually power him with physics when possible. This means using the 6DOF Joint's ability to be a motor and turning him with torque (so he is moving in a physically plausible fashion). This also means using contact monitoring more instead of manual raycasting (as I mentioned in the first point, use a much more complete gamut of features provided by Godot).
4). Name and style consistency, I have trouble with this concept for nearly 20 years and I do not find it easy for me to maintain it after a while. As a result, I am really trying to hammer convention down to make development easier. The script names are to make it clear they are logic and the mesh names need to make it clear they are meshes. Then there's case schemes that need to be used to differentiate between different types of data (ie. object names and variable names).
5). Make sure things just work before adding the next big thing, one step at a time. The first two iterations of this game saw me struggling with the idea of getting too far ahead of myself, meaning I had a lot of different things to debug and fix at once. For this game, I need to make sure I do not go beyond the first level until everything looks polished and working nicely (as it means the minimal amount of features to work on at any one time). Going too far at once before everything is nicely done is just asking for trouble (since I am just a single developer anyway, which makes it extra important).
6). Godot makes it easy to have a script hierarchy, use it. The class_name feature is something I have long neglected and have not used enough. I have in fact utilized it for enemies, but I need to use it for other objects with similarities to further reduce breakage (this time because of far fewer lines of code being duplicated). I have already created a base class for collectables, needed and optional alike. The same will once again apply to enemies when I get around to that. I have long not used it much because my first 3D engine was the BGE, which did not have the straightforward and intuitive everything is a class design (so actually doing such was a bit more difficult and a bit more work to figure out).
Sure, some features were avoided because they seemed a bit obtuse in how they are used, but fortunately the team realizes this and has fixed the issue with many features even in 3.x, smooth camera movement for instance came quite early in development this time because of the backport of scenetree tweening.
