On dynamic slices

Hello!

As far as I gather LY team seems to push dynamic slices as a way to create new entities at run-time. I came to this conclusion based on lack of any documentation whatsoever regarding creating a simple entity with some arbitrary components at run-time, and the existence of scripting solutions which implements spawners with dynamic slices. This post is about game entities at run0time, not about chuncked world management, where I believe dynamic slices are cat’s meow.

This begs the following:

  1. LY team please clarify whatever dynamic slices are indeed your vision of instancing new game entities at run time.

  2. Dynamic slices are IO storage baked objects. When you instantiate a dynamic slice, the system will inevitably hit the IO storage stack to load the slice, resolve the resource dependency graph, then load resources (meshes, textures, … you got the idea). Once those are loaded, they seem reference counted, which is a good ideea. Note that this step can result in pretty heavy IO.

  3. Now assume you use dynamic slice mechanism to instantiate an arbitrary gameobject at run time, lets say an enemy AI. Its a pretty heavy object it has meshes, skins , skeleton , texture, animgraph of its own. This will cause pretty heavy IO. No problem , it can be solved, just be attentive where you spawn the object and because it is loaded asynchronously , the player wont notice.

  4. The player wont notice, except in a worst case scenario , it may cause a load of IO. Imagine I spawn such an object, the destroy it, only to spawn it again 100 ms later. This will cause asset reference count to drop to 0, resources freed, then, 100ms later, the IO stack is hit again to create a new instance. This will affect your IO budget. How much, is n a case by case basis. It will also cause effects on CPU memory pools, then PCIe bus to cache new data in GPU, trashing caches , eating bandwidth and forcing gpu / cpu synch . Last but not least, it has the potential to cause memory fragmentation on all the memory pools, both GPU and CPU. (worst case scenario we are taling here, short life spans, reference counts drop to 0, only to be recreated ms later.

  5. Also, the player WILL notice IO if you cannot hide it with level design. For example weapon projectiles , imagine a game where your weapon spawns demon projectiles with basic AI, mesh , animation, fx and all that instead of a hit scan . It will hit very heavily the IO stack, causing both player annoyance, and eating a good chunk of your IO budget.

  6. LY team, please clarify. If this is indeed the preferred way to create game objects at run time, then is there any way to load a template of a dynamic slice in memory, precache it, and just clone from it the required game objects , to totally avoid IO ? It would solve the issue with worst case scenario, because the template slice will hold references to the resources in question.

  7. LY team, please clarify, if dynamic slices is not to be used for objects with such problematic life cycles, which is the intended way to do it and document it properly in your entity component sytem documentation.

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.

@Lumberjack

CC @fluffy @Vidas_Maslauskas

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.

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.