Breadth-First Search option for Node.find_child()

[guilleatm]

Reading the docs, found that Node.find_child() function (old: Node.find_node) performs a Deep-First Search. I thought it could be great having an optional parameter to choose between deep and breadth search. Of course, depending on each project or use case, one of the two options will be more convenient but this way we give the user more control over what it's happening.

[Calinou]

Can you describe your use case for using find_child()? Also, are you running into a performance bottleneck with the current implementation?

[dalexeev]

I think it's not just about performance, but that the two options can give different results. Perhaps this really has some practical meaning (children are more priority than grandchildren).

[guilleatm]

I am not running into a performance bottleneck but in some cases this might help.
I feel that it is more intuitive to think in a brearh search when guessing about how find_child works.

More than that, find_child is not meant to be used a lot so it can be used in the _ready function for finding some managers / controllers that you don't know where they are in the tree.

The path for the children inside these manager nodes is usually known, probably the manager is a separated scene and there is no reason to look for deep nodes first.

[Jesusemora]

Why are you using find_child()? And why are you using it in such a way that you have to worry about the search algorithm that is used by it?
What kind of mess is your tree? Are all your nodes parallel or what?

[SlugFiller]

BFS has a cost, in that it requires keeping the "wavefront" in memory while searching. In real time software, memory allocations need to be kept to a minimum, because allocating memory is an operation that could take any amount of time, based on the amount of allocations made so far.

In other words, without adding skip-links to the nodes (which would be its own additional layer of complexity), BFS would simply be far too costly relative to DFS, and not practical for use in a game engine.

[SlugFiller]

The issue is that it would revisit the low-depth nodes as many times as the tree is deep. If the tree is wide at the base, but has a very long stringy branch, the performance cost could be massive. We're talking O(n^2) for an operation that should be O(n). So, still not practical in a game engine.

[ivxvm]

@SlugFiller All of this is mostly called once in "_ready" anyway. Calling any search repeatedly at simulation rate would be terrible, be it bfs or dfs or ids. I can understand memory concerns for one-shot computations in "_ready" because it can cause some cascade memory usage spikes on scene initialization which might be problematic, but why is anything performance related is a concern I'm not sure. It only means the scene can take slightly more time to load, but it's not going to blow user's RAM. Personally I mostly use this for component search to mimic Unity-style GetComponent. I wish Godot had more first-class support for modular component-based programming, it seems it tries to suggest to use inheritance instead of composition, but I don't see how to get anywhere close in flexibility and modularity this way without multiple inheritance or traits. And even if Godot had multiple inheritance or traits I would probably still prefer composition-based approach because it's simpler and more manageable to me.

[SlugFiller]

Actually, Godot suggests the use of composition by using multiple nodes. The need to search for nodes, however, is averted by simply using a constant structure per entity. i.e. a node serving a specific purpose should be at a specific path from the entity root. That way, instead of needing to use find_child, you just use $node/path notation. Rather than doing it in _ready, you do it in onready variables, e.g.

@onready var sprite : AnimatedSprite2D = $sprite

This is a relatively common pattern in Godot.

If you need to get all nodes representing a certain component type, the correct solution is to use groups, which are optimized for this exact purpose. The search order shouldn't really be relevant in this case. Groups don't operate by search anyway, but rather, by keeping an up-to-date list, making it significantly more performant if you're going over the entire scene.

[ivxvm]

Actually, Godot suggests the use of composition by using multiple nodes. The need to search for nodes, however, is averted by simply using a constant structure per entity. i.e. a node serving a specific purpose should be at a specific path from the entity root. That way, instead of needing to use find_child, you just use $node/path notation. Rather than doing it in _ready, you do it in onready variables, e.g.

@onready var sprite : AnimatedSprite2D = $sprite

This is a relatively common pattern in Godot.

If you need to get all nodes representing a certain component type, the correct solution is to use groups, which are optimized for this exact purpose. The search order shouldn't really be relevant in this case. Groups don't operate by search anyway, but rather, by keeping an up-to-date list, making it significantly more performant if you're going over the entire scene.

I've tried this approach at the very beginning, as this is what doc says. I've had problems with having my components in consistent place/depth in entities of different types though. I'll probably try again because I can't even formulate what exactly the problem was.

constant structure per entity

It's more like "constant structure per component", because the same component can be used in many different entities and it might depend on other components and they should all have the same layout within all those entities. But again I don't remember where exactly this failed, so I will try this again. Maybe I didn't even try at frist because I needed something like $parent/OtherComponent and couldn't find the way to do this.

[SlugFiller]

If every component has a unique name, then a depth of 1 should be all you need. As for getting the component from a parent, get_parent().get_node('component_type') would do the trick.