Any way to get the list of children of a game object?

[Mathias]

@britzl

We are looking into a bigger feature to provide full inspection of the scene graph. The main purpose of this functionality is to use it for UI automation, test frameworks and editor and stand alone tools. As part of this we must also look at the whole get parent and get child/children functionality that the engine provides. It is not unlikely that you will see this functionality available in the engine during Q3.

This is from 2020… is there some advance to this?

My use case is to add plug&play generic systems in my dev environnment, for example a visual debuger where you can show ingame objects, for example all sprite components, with their size or mesure stuff, or get id of object under mouse etc.
Or visually track specific properties

So I can inspect stuff, and properties of my components live, but I dont need to modify any of the game code to do so.
Just drop a script in the main collection and BOOM! visual debugger!

Same for an in game editor: i want to code something reusable that dont know upfront what is the structure of the game collections, objects and components. I want it to discover objects then give you possibilities to modify them. Right now it is not feasible unless you modify your game code so that objects register themself to a self maintained table. But that means it is invading the game code, no more plug&play.

[britzl]

Yes, sure, we’ve had a C API to do this a very long time now. See dmGameObject::TraverseGetRoot() etc

TraverseGetRoot - API reference (Gameobject)

It is used in the POCO test automation extension and I built a small extension to return the scene graph from Lua.

[Mathias]

Thanks! This is a nice start!
I will dig a bit maybe propose a PR to add some lua api for example to get the graph only from a specific object id if possible.

[a-daniel]

@sergey.lerg

Is it possible to get access to this list and request parent and children of a game object?

@xixi012.c

unfortunately, there’s still no go.get_children method.

@britzl

https://defold.com/ref/stable/engine-gameobject-src-dmsdk-gameobject-gameobject-h/#TraverseGetRoot:regist-node

Hi everyone,

I decided to have a try at my first Defold extension. So I modified the example from @britzl and I made extension-descend .

This extension returns the descendants(ids of children, grandchildren etc.) of a specified game object. Also it can return all the game objects in the scene.

The implementation is kinda hacky, because I didn’t want to use the iterator API so I’m accessing some game engine private data.

Regarding performance concerns, it’s slower than I expected but I think it can be used in some cases. For a scene of 1024 game objects, on my laptop, it takes about 0.5-1ms to get all the game objects from the scene.

[Mathias_Westerdahl]

@a-daniel

The implementation is kinda hacky,

I agree, and it’s is quite “dangerous” to simply cast an Instance pointer into your own struct.
It’s quite likely we’ll change layout of the struct, making your extension crash (at best) or exhibit strange behaviors (much harder to figure out).

because I didn’t want to use the iterator API

Why not?

[a-daniel]

@Mathias_Westerdahl

because I didn’t want to use the iterator API

Why not?

I wanted to get only the game objects but the iterator API iterates over the components too so you have to check the node type etc. which takes a lot of time. The difference is 0.5 ms vs 50 ms.

@Mathias_Westerdahl

it’s is quite “dangerous” to simply cast an Instance pointer into your own struct.

Yes, that’s why I added warnings in the repo docs and at compile time and I did some compile time tests on structure size and field offsets although I just realized that I might be testing my own types so that might be useless.

I think if the risks are clear and people think it’s worth it, might help someone.