Loop through all game objects in a collection

Questions
#1

Is there a way to loop through all game objects in a collection? Like a go.get_children() or something?

#2

Hello Tproper,

There isn’t currently that functionality, however it is being discussed within the Defold team I believe (Any way to get the list of children of a game object?).

I will say, generally this isn’t something you should do, in my opinion, it will almost always result in highly-processing intense code, and can almost always be replaced by properly using the messaging system.

If you want to describe your situation I, or others, might be able to provide advice on a potential approach?

Cheers,
Spen

4 Likes
#3

Collections don’t exist at runtime, only objects. What exactly are you trying to do?

#4

@SpencerWF For clarity, that feature is for debug purposes, in order to be able to report the scene graph and its properties. It was created in order to be able to create an extension such as extension-poco, which let’s you test/control the game from another computer via python.

4 Likes
#5

I just want to run a few lines of code for all my objects in the collection without having to attach a script to every single object. Just a few lines of setup code that involves grid management.

If there was a way to msg.post() to all those objects then that would work too…I just think that’d be cleaner than having to put code in the init function of every object in my collection.

It’s not a huge deal at this moment but learning how to do something similar would be nice.

1 Like
#6

Are the objects following a naming convention? You could loop over the objects if you know their names have the same id and a sequence number.

2 Likes
#7

They are not but I just attached a script to each game object… thanks for all your help eveyone.

#8

Anyone, ever again needed something like this? What are your workarounds or feelings about its? I feel the same about use cases, where I want to parse a huge amount of game objects only to do something with them from one script and I feel like having a list of instanced objects in the runtime would be very useful, instead of name convention workarounds and eventually checking with go.exists().
Is there a possibility for Defold to have such list of instanced objects stored? Isn’t IT already stored anyway for purposes of managing the memory?

#9

The engine is designed with the philosophy that you should know things upfront, to prevent iterating scenegraphs all the time. It stems from actual use cases, that the authors wanted to restrict.
Also, there is always the question of “does everybody need this?”. I’d say no.
We do these things to keep performance, and also keep the engine size small.

If there was no workaround, it would be different, but we feel it’s totally possible for the user to keep their own record of these objects.
In this case I would create a .lua module to hold the objects. For static objects, parse the collection file and put them in the .lua file. For dynamic objects, store them in the list when you spawn them.

3 Likes
#10

There is also code in the C++ SDK of Defold to iterate the scene graph using dmGameObject::TraverseGetRoot. This is used in the Poco extension. I’m using the same for an experiment I’m doing currently and I pushed it here if you want to take a look:

You call graph.dump() to get a Lua table hierarchy of the entire scene graph. Note that this generates a lot of garbage (Lua tables) and I don’t know how it works on deep nested hierarchies. Use at your own risk!

3 Likes