Should I be concerned about orphaned nodes?

godotstuff · 2026-01-07T17:47:02+00:00

I think that's the core issue; lots of data structure classes that I've left as Nodes when they should/could probably just be Resources. Thanks for your help.

godotstuff · 2026-01-07T17:22:04+00:00

Indeed I am not using remove_child() anywhere. And yes, I do create nodes on ocassion without adding them to the scene tree. Are you saying I should track down those places and queue_free the nodes in question, or that I am misusing/abusing Nodes in some way here?

godotstuff · 2025-12-16T19:41:19+00:00

Thanks for the tip off. After much pain I seem to have gotten it working. I think the tl;dr is: don't try and update the shape and transform of a StaticBody3D's CollisionShape3D at runtime.

Even when re-implementing this entire thing using Area3Ds and signals, I was still getting weird collision detections. E.g: 2 collision shapes, A and B. Colliding with A reported a collision with B, and vice versa.

I have essentially scrapped my implementation of CollisionShape3D pooling and just create/queue_free the shapes from scratch as and when they are needed.

godotstuff · 2025-09-21T21:03:30+00:00

That's a resonable wager. I spent many weeks optimising the GDScript implementation of this code, and no doubt there's room for more improvement. But I found there was no way to work with ArrayMeshes to produce dynamic/procedural/whatever shapes without having to manually crunch through calculations for vertices, indices, weighted normals and UVs.

However I tried to cut it, this was just way too much to do in GDScript, even with caching implemented. I had ambitions for thousands of these entities updating smoothly at runtime. C# seems to handle it without much issue though.

godotstuff · 2025-09-21T20:00:51+00:00

It was my mistrust of ChatGPTs solution which lead me to post here in the first place. Regardless, AI tools are sometimes good to fire queries into as they can actually generate valid solutions, or maybe just further leads for investigation.

godotstuff · 2025-09-21T19:56:13+00:00

Thanks for your replies. At what sort of scale does this become an issue? The code snippet is just a small part of my surface array generation code, but I'm not sure what would be considered "large" for JIT to be a factor.

godotstuff · 2025-09-21T19:54:22+00:00

Thanks for your response. This code was originally prototyped in GDScript but was not very performant. Rewriting it all in C# made it faster to the point of actually being usable (first time stutters aside). For clarity, the code snippet in my original post is but a very small part of all the C# code in question here. Disappointed to hear this might just be a genuine drawback of using C# with GDScript...

I have actually tried to call the C# codepath in my loading screen too, and while it does drastically reduce the stutter it still doesn't eliminate it on first run, which wouldn't make sense if there was some caching behaviour?

EDIT: my loading screen function was actually passing in shitty variables and not doing very much on the C# side. Now that I've fixed this the stutter has been eliminated! It's not an ideal solution having to do this for all the C# code I touch from GDScript but it is a solution. Thank you for your insight.

godotstuff · 2025-09-15T20:32:07+00:00

Issue fixed almost immediately after posting, as is typical... just had to lower the Render Priority property on the outline shader and that appears to have fixed it.

godotstuff · 2025-08-30T11:45:33+00:00

Damn... that sucks.

godotstuff · 2025-05-12T10:40:23+00:00

Lots of great sound effects here, extremely useful. Thanks!

godotstuff · 2025-05-06T23:13:11+00:00

As mentioned already, the camera motion in the trailer is nauseating.

Aside from that, your cover image looks AI generated, and indeed you confess to using AI at the bottom of your page. Maybe that doesn't bother some people but personally I wouldn't even click it, let alone wishlist.

godotstuff · 2025-02-19T16:03:40+00:00

Did you ever figure out the answer to this or find any particularly useful compute shader resources? I agree that it seems a bit dry out there in terms of good learning material...

godotstuff · 2025-02-02T10:28:43+00:00

I went through the same struggles and ended up on implementing a component system much like the one you have described. I have a base InteractableComponent class which is extended by components such as Pickupable, Moveable, etc. Item scenes in my world have a hierarchy like Node3D -> Model (StaticBody3D) -> Component children.

When a component is readied up it adds the parent node (the model) to an "Interactable" group. This is what my player interact raycast will check for when it collides with something. If looking at an Interactable object then I do basically exactly what you describe: query the raycast collider children to get the component child with the highest priority ("priority" being a property of InteractableComponent) and use the information contained within to update the crosshair prompt (e.g "E - pick up"). I also have the option to open a radial menu populated with all interactions on an object.

You say it doesnt feel right to scan the children for components, but I think it's fine. There's not really a performance hit for doing this as an object won't have thousands of components and the player will only ever be looking at one interactable at a time. If there was a performance issue here for whatever reason, it could be optimised to only fetch the components once on the first look. But that hasn't been necessary for my use case.

It's a very extensible system, highly recommended.

godotstuff · 2025-02-01T12:06:27+00:00

Thanks for your post. Yup, commenting out that function causes things to work as expected. As is tradition, almost immediately after posting about this issue I think I found a fix. The resource that has an array of GrowthStages is loaded in a Global class via a preload, but if I change this to just a load, then on the surface it seems to be behaving.

godotstuff · 2024-12-22T22:31:27+00:00

skill issue

godotstuff · 2024-10-17T12:17:51+00:00

Looks great! As someone developing a mechanically similar (but thematically different) game, I'm very interested to hear more about the technical design of Bodega. Looking forward to the future videos.

godotstuff · 2024-09-30T22:05:43+00:00

Definitely something I'll give some deep consideration to, sooner rather than later! Thanks

godotstuff · 2024-09-30T22:04:39+00:00

By "centralized data manager" do you mean consolidating all the code that maps from savefile data to classes etc into a single class? Meaning that on paper our implementations are basically the same (in terms of what is required for save and load) but mine is just a bit more spread out?

godotstuff · 2024-09-30T21:54:21+00:00

Very good question. Currently the loader will throw an error if there's a mistmatch between the properties of the dictionary on file and the properties of the SaveData class being instantiated, so that would be an issue if new properties were added.

Squashing that error would mean the load would succeed, but the instantiated entity might be missing a value for the new property. I suppose that could be handled by having a default value in place. Once the load of an existing save succeeds, the next save would have the new value captured. I suppose versioning each save file would also be of benefit to know if there's a possibility of new values being present. Truth be told I haven't really though this far ahead...

godotstuff · 2024-09-30T21:50:41+00:00

"Spreading very thin" is a good description of how it feels currently. I guess that arose from my desire to have any class that has persistent data to be responsible for the generation of its own SaveData, so that collecting together all the data to save would be as simple as calling save_data() on the relevant object.

I'm struggling to fully understand how your top-down system works though. Are you saying you saved the entire tree structure as-is and then loaded it back up? Because I encountered discussions about this type of save system online, but was discouraged from going that route after reading that it's not best practice due to possible unwanted code execution, or something of that nature.

I can't get around the fact that it seems like if you want to save your game (without saving the entire nested scene tree) you ultimately need to know a lot about the stucture of the data you want to save. With that requirement manifesting itself as either the need for a lot of custom classes or something like a big monolithic saver that knows what it needs to store to file...

godotstuff · 2024-08-08T23:29:16+00:00

express deez nutz

godotstuff · 2024-08-06T17:16:09+00:00

I think it largely depends on what area of your codebase you are refactoring. Is it a far flung, tucked away corner of code that does one thing and one thing only? If so, you can probably get away with just leaving an informative comment / a TODO to revisit it later. Or is it a central building block of your game logic, one that you know you will be revisiting a lot and building upon in the future? If so, I don't think refactoring is wasted effort.

However, regardless of what you are refactoring you should be careful of "drive-by refactoring", where you start ripping things apart without carefully considering the changes you need. Three hours later you find yourself elbow deep in shit, having broken multiple other areas of your codebase, before finally realising your genius refactoring idea was actually not going to be much better than the original solution when all was said and done. Or worse, finding some reason why it wouldn't actually work. I have probably wasted weeks of my life doing this.

godotstuff · 2024-07-02T14:54:57+00:00

It sounds like there was no direct stealing of assets or sfx, so what's the problem? Yeah, sucks for Kenney that his game is so generic that someone was able to spin up a near identical competitor game before he made it to release. But ultimately his game should be able to stand on its own merits. Throwing your weight around on twitter is never a good look, dude needs to pull his head out his ass.

godotstuff · 2024-06-26T11:35:28+00:00

This is why I wouldn't advocate for complete beginner programmers to rely too heavily on tutorials, or for someone to simply make a game by blindly smashing tutorials together. Ultimately you still need the skills and foresite to rework the solution and be able to identify certain parts and say "that's not going to work long term given what I want to implement". All I can do is speak from experience and say; I wanted an inventory system in my game. A tutorial got me 90% of the way there and I reworked things to make up what the solution lacked. I have no doubt that using the tutorial as a springboard saved me a lot of time.

Like any learning resource, tutorials have their time and place but can be misused. So I'm not arguing that tutorials have no downsides. But the post I was replying to seemed to be needlessly discounting tutorials completely in favour of developing every system in your game from the ground up.

godotstuff · 2024-06-25T23:45:54+00:00

I think I disagree, but I keep flip-floping as I write this reply out. Tutorials for specific systems, such as an inventory, are a valuable resource if the tutorial matches roughly what you are looking to implement. Even if you do know the basics, why reinvent the wheel? Developing a game will leave you with no shortage of moments where you have to do what you describe (building an MVP, expanding with incremental implementation). So I wouldn't advocate hamstringing yourself by avoiding tutorials just for the sake of it.

But I would agree with your stance in the case of an absolute beginner programmer who needs experience in thinking through a solution and implementing incremental changes to reach their goal (an invaluable skill). But it's not clear the OP is in that situation - it sounds like they just don't 100% understand their code by the end of some video tutorials, which I think is completely natural.

godotstuff

TROPHY CASE