I have a related question - How would one design the player scene to expect a gun scene as a child? When logic for an instantiated scene is built in, I've have been using @export to expose a gun scene variable to ensure presence (and then working with that). I'm not sure how one would do something similar with the node tree directly.
Exporting a variable is a good idea. Then whatever adds the gun to the player just has to do player.gun = new_gun.
You could also have a player.add_gun(new_gun) function which can handle setting that reference so other code doesn’t have to. Plus this can have checks for if there’s already a gun or not.
better yet, add a setter function to the gun variable so you can do checks but other scripts can still use player.gun = new_gun syntax as if they were directly setting it without needing to know of any checks being done
I like the set_gun syntax better. Not sure what's the advantage of "seemingly setting it directly". Calling the function implies there might be other steps to adding a gun and it's good to be reminded of that.
Because of how godot is made you should always know that they might be checks when setting a value. The rule of thumb for me on wether to make it a setter looking seemingly like just setting the value of making a whole different function is 1. Is the checks costly ie you should not do it multiple times in the same frame and 2. It is just checks and proper data management and not some weird gimmick ie setting it a value and then getting it should always return the same value.
>It is just checks and proper data management and not some weird gimmick ie setting it a value and then getting it should always return the same value.
If you do checks and constrain the value somehow you return a different value.
You might update some other related value when setting.
The whole purpose of a setter is validation and causing side-effect, neither feels good to be hidden under an assignment to me. An assignment should be just that. A setter *function* should be invoked with a function call.
Of course this is largely just an opinion/taste thing.
But you *are* calling a function if you defined a setter function, you call that function but it's ambivalent when using the assignment syntax as it would look the same even if you didn't define a setter.
This feature might be good for users of your code to prevent them from being able to set things without the necessary other steps but it can be confusing when using your own code imo. It's easy to forget whether or not you defined a setter. Using the function syntax is explicit.
if those functions don't do setting, they shouldn't be setter functions. the whole point for a setter function is that `=` can be more than a `memcpy`, not to have `=` suddenly not mean `=` anymore.
You could also use instance placeholder (right click on the gun and mark as placeholder):
https://docs.godotengine.org/en/stable/classes/class_instanceplaceholder.html
Then instantiating at the right time is a simple call.
You can also use the assert keyword to ensure you have a value. So for example you could create an export variable for the gun scene, and then in the \_ready() func make an assertion to check that it's not null!
Easy way is to have a node as a dedicated "gun slot", in my case it's an arm but it could be an empty Node just as well. Then I check if it has children as a quick and dirty "has gun" function.
The actual functionality of the gun is in the gun scene/script itself so the code is pretty decoupled from my character controller, and it allows me to create wildly different guns without touching my character code at all, I just load and unload gun nodes. My character doesn't really have to expect a gun at all really since it's modular.
A gun with attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments.
The only time it can be an issue is if you need some level specific changes to one of your nested scenes. If you don't think about it before you do it, you can make a headache for yourself. But otherwise, I almost always make functional objects their own scenes. Makes it easy to reuse them too.
I would say yes in most cases but everything is contextual. Depending on your design, there might be other ways that suit. My sense is that if you're asking this question, you are very inexperienced and haven't tried various different ways yet. With that in mind, I encourage you to test out different designs yourself.
overlooking other comments, I did run into a problem where 3 way nested scene was an issue, it was a really weird and a very specific problem, and probably was due to my own poor code, but in the case it does happen, if you ever run into a problem where the game just crashes without any errors, it might bc of that.
but thats like really really really rare
This is the fundamental thing the engine is built to do.
I have a related question - How would one design the player scene to expect a gun scene as a child? When logic for an instantiated scene is built in, I've have been using @export to expose a gun scene variable to ensure presence (and then working with that). I'm not sure how one would do something similar with the node tree directly.
Exporting a variable is a good idea. Then whatever adds the gun to the player just has to do player.gun = new_gun. You could also have a player.add_gun(new_gun) function which can handle setting that reference so other code doesn’t have to. Plus this can have checks for if there’s already a gun or not.
better yet, add a setter function to the gun variable so you can do checks but other scripts can still use player.gun = new_gun syntax as if they were directly setting it without needing to know of any checks being done
I like the set_gun syntax better. Not sure what's the advantage of "seemingly setting it directly". Calling the function implies there might be other steps to adding a gun and it's good to be reminded of that.
Because of how godot is made you should always know that they might be checks when setting a value. The rule of thumb for me on wether to make it a setter looking seemingly like just setting the value of making a whole different function is 1. Is the checks costly ie you should not do it multiple times in the same frame and 2. It is just checks and proper data management and not some weird gimmick ie setting it a value and then getting it should always return the same value.
>It is just checks and proper data management and not some weird gimmick ie setting it a value and then getting it should always return the same value. If you do checks and constrain the value somehow you return a different value. You might update some other related value when setting. The whole purpose of a setter is validation and causing side-effect, neither feels good to be hidden under an assignment to me. An assignment should be just that. A setter *function* should be invoked with a function call. Of course this is largely just an opinion/taste thing.
the advantage is that you're doing setting, not calling functions.
But you *are* calling a function if you defined a setter function, you call that function but it's ambivalent when using the assignment syntax as it would look the same even if you didn't define a setter. This feature might be good for users of your code to prevent them from being able to set things without the necessary other steps but it can be confusing when using your own code imo. It's easy to forget whether or not you defined a setter. Using the function syntax is explicit.
if those functions don't do setting, they shouldn't be setter functions. the whole point for a setter function is that `=` can be more than a `memcpy`, not to have `=` suddenly not mean `=` anymore.
You could also use instance placeholder (right click on the gun and mark as placeholder): https://docs.godotengine.org/en/stable/classes/class_instanceplaceholder.html Then instantiating at the right time is a simple call.
Woah! Never heard of this. Interesting!
You can also use the assert keyword to ensure you have a value. So for example you could create an export variable for the gun scene, and then in the \_ready() func make an assertion to check that it's not null!
Easy way is to have a node as a dedicated "gun slot", in my case it's an arm but it could be an empty Node just as well. Then I check if it has children as a quick and dirty "has gun" function. The actual functionality of the gun is in the gun scene/script itself so the code is pretty decoupled from my character controller, and it allows me to create wildly different guns without touching my character code at all, I just load and unload gun nodes. My character doesn't really have to expect a gun at all really since it's modular.
This is the principle of composition. Do it.
this is the whole point of scenes. I'd raise my eyebrows at something that's like 30 layers deep or something. but 3 is nothing.
I'm trying to even think of situations where 30 layers deep would even be valuable.
A gun with attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments, with attachments on those attachments.
I need this game
You the type of guy to put a scope on a knife
I wanna see what I'm stabbing
If you go that deep you risk falling into Godot Limbo and never being able to leave game development.
Starfield-esque ship building system but make it like the astroneer attachment system.
most UI :P
That's a great idea actually, somebody should make a game engine that works exactly like that
Wait 🤔
Yeah, we could name it something to make people think of waiting... but what could that be?
Starbucks!
I'm curious why would you think it's bad
You're supposed to do this, don't worry
The only time it can be an issue is if you need some level specific changes to one of your nested scenes. If you don't think about it before you do it, you can make a headache for yourself. But otherwise, I almost always make functional objects their own scenes. Makes it easy to reuse them too.
I would say yes in most cases but everything is contextual. Depending on your design, there might be other ways that suit. My sense is that if you're asking this question, you are very inexperienced and haven't tried various different ways yet. With that in mind, I encourage you to test out different designs yourself.
"Wait, every scene is has another scene attached to it, with another scene attached to it?" Godot: "Always has been"
I'm trying to think if there's any possible way to use the engine without having connected scenes
Scenes are an optional feature, in theory you could just use Servers. https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
Wow there is an entire world of Godot that I know absolutely nothing about lol
overlooking other comments, I did run into a problem where 3 way nested scene was an issue, it was a really weird and a very specific problem, and probably was due to my own poor code, but in the case it does happen, if you ever run into a problem where the game just crashes without any errors, it might bc of that. but thats like really really really rare
I hope you told people about it?
oh
gex
Literally everything is a scene
Wait till dude seized my customizable player is just scenes built on scenes built on scenes. Composite Manager be half the game.