I posted about this project a long time ago in an early iteration of this forum (when it was just starting). To note, I was trying to get a new version off the ground in Godot 4 but things kept breaking, it was an endless waiting game to see if things would improve enough to really get it going.

Then I noticed 3.x getting big improvements still. As I looked at all of the version 4 features being backported, I figured I should just rewrite the game in the new 3.5 version instead. This is where I am now after a couple of days.

One of the biggest changes is that due to 3D labels being a thing now, the information on playing the game can now be handled in a non-blocking and non-intrusive way (as opposed to a UI popup). Improvements to rendering performance meanwhile allows for higher quality in areas like GI, making for more beautiful environments (in which some milliseconds are regained from not needing things like SSAO so much). The terrain and a couple of other objects also make use of Godot shader scripting to allow for automated coordinates and some automated masking (which will greatly speed up environment creation).

Then there's two other aims. One is to really get a state-based system going to ensure that things like player movement does not break near as often when changes are made, and the other is to try to make every bit of logic as self-contained as possible (so as to make it far easier to test the game and also to reduce the amount of breakage). What that means is not having too much in the way of interdependency and control from a central point, as even the UI won't be all bundled together in a monolithic block anymore.

In short, I take everything I learned in the many years since starting Godot and figure out what needs to be done better and how to do it. What I hope is that a combination of what I wrote along with Godot's advances make things a lot easier this time around.

    Ace_Dragon What that means is not having too much in the way of interdependency and control from a central point, as even the UI won't be all bundled together in a monolithic block anymore.

    Music to my ears, also, your game looks good! What is this game about?

        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.

        I decided that the camera will, for the most part, use the basic transform.interpolate() function instead (Tweening worked, but it did not work easily for smooth transitions to a completely different angle). What that means is that there is now a basic system to prevent the camera from clipping walls in some cases.

        It does not mean tweens did not have a use among other effects and polish, look at what happens to the yellow point object for instance (a bonus, the gem has an effect as well). This was made using a simple .gif recording program, so the apparent FPS is entirely because of the encoding.

        More short clips will be coming now that I know how to make a basic one (as I do not need a fancy video software to showcase in a way that is an upgrade from screenshots). Also getting done is some UI stuff (Gem number bar, HP Bar, ect...), the player getting hurt with spikes, sound & music, ect...

        Getting checkpoints started. They also have a secondary feature, which takes into account the fact it would probably be frustrating to take a long roll to the end of the level only to find there's still a gem to find near the start. The checkpoint will still save your position though and it won't stop you from ignoring the text.

        This works by separating the gems throughout the level into groups, which will also become a factor in how the gem finder widget will now work (that little gem polygon in the top right). The Gem polygon in the checkpoint structure will turn green when all so far have been found.

        In addition, it is now possible to get hurt, the new tweens mean I can easily create the sequence of the player flashing red without adding timer variables and what not (allowing the use of yields instead in a function that runs for just one tic). Simpler and less likely to break or lose track of.

        One final thing, I may need to add a simple blackboard behind the text to make it easier to read (since for one thing this is one case where such will not get too much in the way, as the text will no longer display when all gems so far are collected).

        5 days later

        Basic Bugbot movement.

        For enemies to work well in general, the design is that each enemy's script will extend another script that holds all of the common functions (which is not exactly new in this latest go-around except there's a common script for collectables as well). This time though, the bugs have a simple yet clear state system going, and also new is a virtual tether (centered at their starting location) to ensure they do not go every place except areas where they would challenge the player (if they go outside their tether, they turn around and keep moving until they are back where they should be).

        The movement other than that is the same, for these first enemies the movement is just a slow, straight walk until they hit a wall or the floor drops out (in which they turn for a random length of time). You will also notice via the shot that I started work on more advanced debugging logic, in this case a debug camera so I do not have to bring the player over to see if things are working.

        There's also new bushes as you can see, just to increase the choice of assets other than rocks or trees.

        2 months later

        I have been busy with art and other things, but I have completed certain mechanics like the one where you collect a set of green point objects to unlock some red point objects (which are the special ones that will unlock things like bonus levels).

        For the green point collection challenge, I have it now contained within a single scene added to the main level with overrides applied to the positions (in which the green objects are arranged in a simple grid by default). That means ensuring a working challenge is now just a single step, meaning it should not be possible to break it theoretically.

        I was also somewhat thrown for a loop when team Godot started giving us Godot 4 beta releases. At first it looked like my project's scenes were somewhat broken when it tried to convert. Now I do not know if it is because of this month's Nvidia driver update removing the LHR handicap to combat crypto or Godot just needed to start up again, but everything 'appears' to work save for the fact that materials do not convert as of now (which can easily be rebuilt). It is admittedly quite tempting to give Godot 4 a go again since the API is nailed down and breaking changes has (largely) stopped, since some of the new stuff makes even version 3.5 feel outdated in comparison.

        Now some things may have to be fixed on my end, but I am not terribly far in this yet (since level 1 is not even done).

          7 days later

          The player is moving again, and just about everything in the hub is working. Also notice the nice fog barriers I can make now to hide the edges of the terrain mesh.

          The only thing to note is that since the 6DOF joints actually work properly now, the bot needed a little additional code to ensure he can be controlled and turned easily, but otherwise he works like a physics object as expected. The ability to set a custom center of mass and custom inertia also means I no longer need any code that helps with stability.

          There also was a minor issue in the form of the project converter converting text box text as if it were code, but I do have a ton of that yet and it is a onetime change, so it was not a big deal.

          2 months later

          You might be wondering what is taking so long, like usual I have been busy with other passions (for instance, modding for a rather nice FOSS game known as Sonic Robo Blast 2, which I would recommend if you want a good quality experience without having to spend money). There is also Blender like usual, especially with the recent upgrades to Cycles.

          However, I am still tooling around with Collect the Gems, it has finally gotten to the point where the gameplay at least is right where I left off when starting the remake in Godot 3.x (abilities are working on a basic level and you can smash the bugbots as they twirl around and disappear in a puff of smoke, the green object collection challenge is also working). Now it is no longer about catching up to what I had earlier in the thread and all about getting the first level nailed down.

          23 days later

          Again, other hobbies and interests took over, but with Godot 4 actually feeling somewhat solid now, things are starting to get interesting.

          So far, everything on a basic level is working, with the bugbots even being able to navigate slopes in the terrain to an extent. There is still a ways to go yet before I figure out game progression (with multiple levels), but Blender (at least the dev builds) now being able to write to mesh UV's procedurally (with the Geometry Nodes) means a faster workflow and a reduced need to create procedural coordinates on Godot's side (which should save a few GPU cycles).

          3 months later

          Again, Godot is not the only thing I work with, but I do have more progress to share.

          What was worked on includes the battery indicator, the exit and exit sequence, additions to the first level, the directional arrow that helps you find gems, extra lives and other goodies, and player death with reset. The game is almost to the point where you can now complete the first level and be sent back to the hub (with the next level then unlocked). Yes, the game now has up to three indicators to make sure you are not all the way at the other end only to have missed one at the beginning (one in the UI, one over the player, and one at the checkpoints).

          However, I had an issue where the command to change scenes in Colossal Courtyards did not have any recognition of the Hub level as a valid resource (because while the scene was not corrupt, it could not be parsed). This was fixed by recreating it from scratch with the other elements copied and pasted from the broken version (which saved a bit of time from that, at least it was still in a very early state).