- Newest
- Most votes
- Most comments
Hello, this is still relevant in 2019. Can we please get a clarification on the matter?
Yeah the docs a little bit lacking about how to create entity with various components on runtime (on fly).
But you still can ably construct entities with various components on fly.
For some components the LY API still lacking (not all methods of components are public or Ebus are missed some functionality for dynamic creation), since devs are mainly focused on using of Slices or DynSlices.
I think this wrong, since dynamic creation is more powerful than preconstructed with Slices.
But you can do own asset manager (pool of preloaded assets) and tried to use it for own dyn entities.
I think in this case you will got a less IO operations, since assets are already preloaded.
Some time ago I made my own simple componet with dynamic initialization.
you could take a look on this code here :
MeshComposedComponent.h https://pastebin.com/QUqKr1jv
MeshComposedComponent.cpp https://pastebin.com/JEqCb7WK
The problem of this example is that each instance of this component loads assets, but I think this can be fixed if you write your own system componet that will be load pool of assets. From this new custom asset manager(pool) such kind dynamic components may just requst the reference to some needed Assest and use it for internal components.
Dynamic slice docs are here: https://docs.aws.amazon.com/lumberyard/latest/userguide/dynamic-slices-what-is.html
Quote: "Standard slice assets (.slice
files) rely on the editor and cannot be instantiated at run time. However, Lumberyard provides a mechanism for designating any .slice
asset that you've built as a dynamic slice."
So yes, dynamic slices are there for you spawn slices dynamically at runtime. Dynamic slice shouldn't be hitting I/O once their assets have been loaded once before. The caching system behind the scenes should take care of that.
Are you specifically seeing I/O being hit on each instantiation of the same dynamic slice over and over?
In fact, if you are using Interest Manager from GridMate ( https://docs.aws.amazon.com/lumberyard/latest/userguide/network-interest-manager-large-scale-worlds.html) it will load only the slices around you and will deactivate/activate entites in a dynamic slice that are within your promixity.
You can spawn a dynamic slice, then deactivate all of the entities in the hierarchy, but don't destroy the entity. Deactivated entities will still hold references to their resources.
Depending on how the entities interact with your game, you could spawn them and move them very far away from the playter, and then move them in range when needed. StarterGame uses this approach with the Bullet that the player fires. It needs to appear very very quickly after player input so they prespawn it and move it far away.
Another approach used in StarterGame (I'm not endorsing the approach) is to create an object pool to preload a bunch of slices and then get one from the pool and use it in the level. This is done with some particles like the muzzle flash, and with decals, such as the decal applied when the bullet hits static objects.
LY probably needs to make a slice preload component that can be used be used for the purpose you're describing - preload all resources required by a slice asynchronously at runtime so that slice instantiation is immediate and with minimal IO.
This post is closed: Adding new answers, comments, and votes is disabled.
Relevant content
- Accepted Answerasked 5 years ago
- Accepted Answerasked 7 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 10 months ago