I had many problems with bundling things into collections, which I find is very helpful when it comes to optimization, but I always get stuck on some basic things that work within one collection but it’s impossible or difficult to do. For example, normally I’m getting other go’s position by simply using go.get_position(id) like mobs getting to know about a player’s position, but when I want to separate mobs to different collections to load them when needed, I have to set up message communication between collections. I wanted to load player and everything needed to play at the beginning in one collection and then just load level collections with mobs when needed. Maybe there is a simpler way to exchange go properties between collections?
Another problem I have, is that it seems, that when player have his collision object, it doesn’t interact with ground collision objects that I want to set in another collection. How can we manage to separate a level background from the player?
I know workaround is to create everything in one collection and eventually create objects via factories when needed, but just why can’t we use collections with ease? Or is my understanding of collections wrong?
Do you mean to say that mobs are loaded via collection proxies? That seems over the top (especially considering what I write below about physics worlds).
There is one physics world created per loaded collection (via collection proxy). And objects from two different physics worlds will not interact with each other. Additionally every physics world will increase runtime memory use a bit (can’t remember the exact number now).
Collections can be used in many different ways. They can be used for entire levels, parts of levels, screens/scenes, complex objects within a game world down to single game object things.
When you use collections for larger things such as entire levels or scenes it is quite common to load and unload them via a collection proxy to better manage memory usage.
When collections are used to represent smaller things it makes more sense to either use them as is inside a larger collection (via Outline->Add Collection File) or through spawning via a collection factory. If you chose to use a collection factory you also have the additional option to load the resources needed by the collection dynamically to give you fine grained control of memory usage.
The above is of course only a recommendation and not a rule, but it is how I would recommend that collections are used.
I understand that and that is the exact reason why they do not collide between collections, but now the additional disadvantage of memory usage does appeal to me, so I don’t want to increase it and make mobs in different collections.
Yes, my thought was to have a 2D platformer with main 3 collections:
- with player object, control scripts, data handling etc - main module that is needed to walk around and play - this would be loaded at the beginning and maintained for the game life time
- with each level - grounds and backgrounds - that could be loaded separately when player enters each level
- with mobs or npcs - just like above
I thought this could help with loading between levels (main module with player would be still in memory and only level and mobs will be loaded during transition). You know, I thought I could utilize the first collection throughout whole the game life. This could also be more convenient to mix collections and create different levels with different mobs. But those problems with different physics world can’t be bypassed and it is a sufficient argument against my ideas.
And as I think wider this separation is reasonable, thanks for the explanation! 
And yes, I will load then one collection with player and mobs and level via proxy
And what about accessing go properties from another collection? What are the arguments against? Is it risky and collection should be totally encapsulated?
I don’t know why there is a limitation in go.get() for access between collections. @sven or @Johan_Beck-Noren might know.
The internal URL resolving is the one to “blame” for this I think.
The code is a bit tricky and needs some rework to get that done. (And, I think that’s not the only place where the limitation is questionable)
So what do you think guys - is it something that could be changed? I mean reaching go properties from another collection? Or any simple workaround except asking via message?
Maybe I have an idea(it might be very much deviating from your style of doing things but, just in case).
Try arranging things like this.
- Base collection, in which you place the players’s collection manually. Since the players are not going to change in a drastic way, it will do the trick.
- Make your parts of maps, gameobjects, and try to keep them as simple as possible. Spawn them using factories.
- Based on a set of parameters, decide when to spawn a member of a mob, or an Npc, both of which are to be gameobjects.
- Now since everything is under one roof(or collection), message passing and doing things like that won’t be difficult.
Actually I was at the same stage a few months ago, but structuring my game like this proved to be far more easy.
Good luck.
Thanks @TheKing0x9, that’s how I’m making a game right now 
I was just trying to create much more convienient collections - why? Mostly, because I can see everything in Editor and arrange things visually. With factories, everything is in the code. For a small level I have enough RAM in my mind to deal with it and minimize amount of builds/reloads to check if everything spawns where I was imagining. But further and further, I was tired of creating one thing I would like to be in the exact position like a blind. That’s why I wanted to create collection for each level. I think I’ll stay with collections and simply adding all of the player data and go to every one of it. I hope they won’t be loading too long.
Store properties in a Lua table and access from anywhere? Key values on a hash_to_hex() of url components.