Creating reusable yet configurable collections / gameobjects

I’m attempting to create a reusable trigger + generic object setup. The trigger sends a message to the object and the object reacts. I want this to be easily reusable, so not having to rename and rewrite the path for every pair would help a ton. The only way I know of to make the relative paths work is by putting them in a collection and then load that into the main scene.

Having them in a collection is problematic though. Being able to change the position of the trigger and gameobject is vital though, but when I do that it sometimes gets saved to the collection file, changing it. Sometimes it doesn’t get saved and the transform is reset to what the collection file contained, even though they were changed and saved into the main collection.

What is the proper way of doing this? Or is it a bug hidden in this?

There are multiple things here, I think.

Could you prepare some repro of you problems?

Generally, I’m guessing you are making collections in assets and modifying them sometimes, but sometimes you modify those collections that are included in othe4 collections, right?

@Pawel here is the smallest repro I’ve managed to make.


Here is the main collection. reusable_thing has gotten one of its children moved and scaled. reusable_thing1 hasn’t gotten it’s children touched. They both use reusable_thing.collection.


This is what the reusable_thing.collection looks like.


Here it is ingame. There are no scripts, nothing. Just these objects.

repro_collections.zip (41.7 KB)

Alright, so yeah, that’s exactly because there is no collection in runtime, but collection is a file which is used to instantiate game objects and their hierarchy, so only runtime objects exist. Because you are referencing to a file, in runtime, you read the file to create the objects - and in the file the objects are described like you see - with scale 1 and those positions.

When you are referencing to the collection inside collection, you still follow the same mechanism, so when you want to modify the sub-collection, you should open it and modify it. Or you can do so in runtime in the script, as then the objects are instantiated and each is their own instance.

This is confusing, I know. :pensive:

I don’t think my explanations are so good sadly, but the point is - sub-collection still refers to a separate file, so changes, while in parent collection does not affect those sub-collections.

The building blocks of Defold - let me know if after reading this manual you get why it’s like this.

On the other hand, I totally get your understanding and I can agree with you that it’s counter-intuitive in such case.

So, @britzl or @Mathias_Westerdahl - from UX perspective it is confusing to be able to modify the subcollections in the editor, but it does not affect the runtime, so it’s not WYSIWYG and it’s confusing :confused:

4 Likes

That explains things for me. What I really was concerned about was how I’d go about designing levels. I’ll probably end up doing a custom level editor (if I don’t find anything that is better before), and then I can use a factory to place the elements in at runtime. Then I get the nice relative paths but also the positioning and scaling that I want.

Thanks a ton for helping me out!

1 Like

Glad it helps! :relaxed:

Use game objects like reusables, you can then modify them however you want for each instance :wink:

Also, it’s a good idea to check out this forum, as there are some ideas about creating levels written down by others, there are a lot of open source projects too to check out (for example, you can check out https://github.com/benjames-171/Defold-games, there are a lot of games with nice and simple levels), there are more advanced approaches too, guys are creating levels in runtime, some are using e.g. Tiled (simple import of tilemaps or more, using json data, like https://github.com/d954mas/defold-tiled-example)

If you ask me, I make separate collection for each level and I have a collection with things that are in all levels (game collection with game logic, player, music, etc).

3 Likes

Sorry for necroposting, but today I faced exactly the same issue! I had the very same idea: a collection I can place in my level collection and set it up, quite similar to @Wistpotion tried, by moving its parts around. But when I pressed play… they moved back to their original position.

So what’s the solution? Not using collections but gameobjects, right? In my case it’s a zipline, so I need a go for where it begins, a go for where it ends and the line itself. A script on the beginning with some properties would tie everything together. But a collection with the three things made a lot of sense! Am I missing something?