After a few weeks of hacking around, I’m still quite new to Defold so I definitely don’t have a complete perspective on all its systems. But I’ve noticed a pattern in my usage where I’ve started defaulting to using Collections instead of Game Objects, even if at the present moment I only need a GO, so I wanted to ask about it:
There have been several times where I defined a game object, then later needed a second game object (for instance, adding a pivot to offset a camera), so then I had to migrate both the implementation and all the usage sites to a collection instead. Now, I generally just start with a collection with a single child GO by default. That way future expansion is easy and there doesn’t seem to be a downside (perhaps there is, and I just haven’t run into it yet?)
It does feel a bit weird, but you’re not wrong to default to collections. In my opinion, this is Defold’s most blatant example of poor engine design.
Game objects and collections are virtually the same, the only practical difference being that if you want to spawn a hierarchy of game objects, you use a collection. Collections act as a sort of root game object in a hierarchy, but they don’t actually exist… Which is so so strange, because game objects alone can already act as roots of other game objects, but only within a collection or via go.set_parent(). It’s a totally arbitrary abstraction of the concept of a root game object, a restriction that shouldn’t exist. They’re just an unnecessary addition to the web of complexity that comes with its own API, way of working, requirement for newcomers to wrap their minds around, source of confusion and bugs, etc.
Collections should be entirely axed from the engine, at least from the user’s perspective. Game objects should be able to nest other game objects in their component files, not just in collection component files or programmatically. They also fly directly in the face of Defold’s core bare-bones philosophy. I’m surprised they’ve lasted this long. They were probably included since the initial design of the engine, which might make them difficult to remove.
I ran into the same patterns that you mentioned, where eventually I found myself needing to spawn a hierarchy of game objects rather than just one. Like you said, this required me to refactor all of my code and files that touched anything related to the issue, which was… a lot of code and files.
I agree. The two concepts should be merged somehow. This has been the topic of many internal discussions and it may happen at some point but it is also a huge breaking change.
To follow up on this, I have also encountered the opposite problem: starting something as a collection, then needing to refactor it into a game object due to the limitations of collections.
For example, I made a “floating_platform” as a collection with a single game object. Later, I wanted to make a “pinwheel” that had 4 floating platforms within it, all rotating around a central pivot. The most convenient arrangement here is for the pivot point to be a game object, so that platforms can be parented to it and rotate around it, having a single GO to place in the world.
However, since collections can’t be placed inside of game objects and collections themselves do not create local coordinate spaces, I had to either refactor the floating_platform collection into a game object, or make the platforms themselves a little more complicated by having knowledge of a “pivot” they should move relative to.
I think unification of these concepts would go a long way towards making defold even more elegant and approachable. I’m still a little fuzzy about the details of what various combinations of game objects and collections would do, especially since collections seem like they might create local coordinate systems under some circumstances.
Since this would be a big breaking change and we don’t know when it will be implemented, would make sense to just add the ability for gameobjects to nest other gameobjects without removing Collections.
Even though it will add another way of doing things but at the same time this will greatly simplify crafting and architecting the project tree.
Visual editing works really well and I find it very helpful. This methodicalness is not always practicable. By the look of it the answer that is occurring, and all round panacea, is editor-scripts. As I understand it you can use Lua to create objects (GO/collections/components) and relationships; then use an editor script to automatically create the protobuf-structure to feed to the engine. This is mega and will make a GO<->collection swap trivial (once the infrastructure is in place…). Seems that this tiger is quietly being released into the wild and the devs are watching to see what it will do/eat. Editor scripting improvements in the upcoming 1.10.4 version.
Sure, my comment was predicated on gameobject nesting already being possible when the gameobject is placed inside a Collection. So this feature can be extended to gameobjects outside of a Collection, of course with the necessary care and testing.