Should be able to add a collection as a game object's child

Feature requests
#1

Is there any good reason why you can’t do this? You can reparent G.O. trees at runtime, so it seems like just an editor limitation?

The whole point of collections is to have reusable…collections of game objects. But if you can’t actually use them as pieces of something larger, that really limits their usefulness.

If you can make your reusable piece out of a single GO then great(!), you can build them up as much as you want, but as soon as you want to reuse a piece with more than one GO…suddenly that’s impossible.

IMO having separate GO and Collection files (and factory/collection-factory components) is just confusing and a nuisance.

I don’t think anyone’s requested this specifically before, but I think it really hurts the UX and causes a lot of other questions, like:

  • Q: “How do I move a sprite?” (at runtime), “How do I move a tilemap?”, “How do I scale a sprite in the editor?”
  • A: “Put the sprite/tilemap on a child GO and move that.”
  • Q: “I tried that and you can’t add child GOs in the editor.”
  • A: “Oh yeah, you have to use a collection instead. If you’re also spawning them at runtime you have to switch to a collection-factory component and switch the function you use to spawn it, etc.”

Game-Object Files

  • A single GO, can’t have child game objects.
  • Instances can be children of other game objects in-editor.

Collection Files

  • Can have multiple GOs, at the root level or as a tree.
  • Instances can not be children of other game objects, are always added at the global root level.

The engine can obviously handle any parent-child hierarchy of GOs, so I’m wondering why we have to work around this weird limitation.

Alternatively, you could allow child GOs inside .go files, but I believe that would cause a big mess with naming conflicts.

7 Likes
Is rendercam outdated/deprecated?
Any plans for improve the camera?
#2

I guess this goes hand-in-hand with the issue of: Not being able to add child objects inside a collection instance (it modifies the collection prototype instead).

I’m guessing this isn’t allowed because it might possibly be ambiguous which collection the child object is in, regarding its URL path and naming conflicts. I don’t know how that works in-engine.

• Collection 1
    - object_1A (in collection 1)
    • Collection 2 (instance)
        - object_2A (in collection 2)
        - object_2B (in collection 2)
            - object_X (added to collection 2 instance inside of collection 1)
        - object_2C (in collection 2)

Personally I would consider ‘object_X’ to be inside Collection 2.

Ideally, Defold would have one main building block—Collections—and you could use them however you want. Combine them, nest them, add instances inside of instances, etc.

2 Likes
#3

HUGE +1 for this!

Simplicity is alway a strong guidance in my opinion.

2 Likes
#4

+1 on this as well. It’s one of the things that came up very often for us in the past 3 years since we’re using Defold.

3 Likes
#5

I agree. It has been a source of much debate at the office as well. It’s currently not planned to change though.

1 Like
#6

I wouldn’t even have dared to request this but it would make things easier for beginners to get into.

3 Likes