I’ve just started prototyping my first game in Godot. I did some stuff in Unity, but moved over after the whole price debacle thing last year.
I’m loving the engine for it’s lightweightness (not officially a word, but I think you get it) but some of the things are slightly messing with my head as I work through them - whilst trying to use Godot how I should, not just doing things how I would have in Unity.
The slightly mind blowing concept for me was having your scene as an independent standalone thing. In Unity, I would be very quick to have anything dependant on going and finding a gameobject somewhere in the hierarchy and doing some process there. Godots idea of - you can look downstream, but not upstream, use signals instead - took a while but I’m getting there.
I’m creating devlogs on my project as I go. I’ve already done 3 in this early stage with quite small incremental parts - essentially just making sure that I can get one of the core mechanics I want to see working. The first one is linked below:
Would love some feedback on these. My unfamiliarity with the engine means that I’m talking about what I struggle with and how I sort of the issue - but no idea if this is the “right” way of doing things, so I’m very open to different approaches.
One thing I can’t do is pixel art… or indeed any art. So the graphics in these early stages are just placeholders. I prefer to get the core mechanics in place to make sure the game works as I want it to rather than spend time making it pretty - that’ll come later.
You can still look ‘upstream’ btw in a scene by using nested getparent calls, and then casting to check if its correct if needed. (if you know its always of a certain class then you shouldn’t need to cast).
So for example if you have an object in a level scene (because you might be building separate distinct levels) and that object needs a reference to the ‘base’ level script that its a part of you can either use export in the object script and drag a reference in the inspector (which is similar to how you can do it in Unity).
Or in code you can get the reference by doing getparent, if the structure of the level scene doesn’t change and you know its going to be static.
So if for example your level object was three levels deep, you could do getparent().getparent().getparent().
There might be a way of getting the root of the ‘scene’ as well, rather than the ‘root’ of the whole application tree, although you can also get that easily enough too.
How Godot structures things is a little weird coming from Unity, it took me a couple of days to get my head around it, but it makes sense fairly quickly.
Or just: get_node("../../.."). Or even shorter: $"../../..". 
There’s get_tree().get_current_scene(), but that’s only one step from the root away anyway. If you need something in between, you’ll have to either start digging or keep a reference to the node in question handy (as a variable).
Thats why I prefer to just export the variable and drag it in the inspector. The onyl issue with that is if you make a copy of the level ‘template’ scene (if thats how the game is being constructed) then you have to set those up again. But its not a massive issue.
1 Like
So while it’s possible to look upstream in Godot - the question I was more considering is “should I” given that the docs are saying essentially “you can do this, but it’s no recommended” then blah blah signals.
So far I haven’t found something where I can’t do it the “right” way. Though I suppose that could well go out of the window if I find something that becomes a bit painful
Parsing up and down the tree is going to be slow., thats probably why its not recommended.
But if its a one off when you are instantiating an object as part of a level ‘load’ then I don’t see why it should be a problem, as you are doing a load of initialisation stuff there anyway.
You certainly wouldnt want to do it every frame thats for sure.
Its always best to just get the references and store them at initialisation. In that regard Godot is no different from Unity.
1 Like
