I wouldn’t recommend such usage of the feature.
Our build system counts components in a world (the collection spawned using collection proxy).
If some component’s count is static - then this collection will allocate this exact amount of memory, if some components are dynamic, then count will be taken from game.project.
So, fo example:
Collection (world spawned with collection proxy)
-go
--sprite
--factory with `Dynamic Prototype` unchecked
----go
------label
will allocate 1 sprite and label->max_count labels, because labes componens is in factory and you can spawn many of them. The rest of component will not allocate anything (because we analyze your collection and see you can’t spawn them).
But if you use Dynamic Prototype then all the component will be dynamic and this collection will take counters for each component from game.project.
For our example:
Collection (world spawned with collection proxy)
-go
--sprite
--factory with `Dynamic Prototype` checked
----go
------label
this collection will allocate sprite->max_count of sprites label->max_countof labes and so on for all the components.
This feature isn’t a hack that makes Defold engine dynamic. I do not recommend to use it just because “I don’t wanna make a factory”.
This feature solves the one particular problem: an ability to spawn downloadable content in existent world (a collection which is loaded using collection proxy).
It’s important when you have your main game and a lot of customizable, seasonal content you don’t wanna deliver to all the users.
Let’s say you have a shooter with a season pass. For people who passed the season pass you give a unique character skin.
All the new users will not be able to get it, because they didn’t pass this particular season. So you wanna this content in your main game collection for some count of player who have it on their accounts, but not all of them. Then this feature is your choice!
I hope now it’s clear.