#Spawning multiple entities from MonoBehaviour

1 messages · Page 1 of 1 (latest)

leaden plaza
#

I have a game that would benefit from using entities as I need a lot of enemies.

At the moment, I have a MonoBehaviour that does a bunch of calculating and assigns many property values to each instantiated GameObject.

Is it possible to pass a request to spawn this entity along with this data to ECS?
So far, I can only see baking as an option, but I need to define the properties of each entity with my MonoBehaviour code at runtime.
Is there a way to do what I'm describing, or do i have to port all this logic to ECS?

crimson tapir
#

I don't suggest to use ECS this way, instead you can just use jobs to do heavy logic to solve performance bottlenecks

#

Managing entities via game objects is probably not going to work as good as you imagine

sly knoll
#

If you already have a game then you might be better off just using jobs for the heavy lifting, without using entities. If you can fully port the logic to ECS you might be better off.

That said, you can use entity manager to create entities with different types at runtime if you really want to.

leaden plaza
#

Thanks both. The game is at a prototype stage, so we're able to be a bit more flexible with porting, so if I may ask some more questions, let's go down this route.

In our MonoBehaviour implementation of the spawner, we have a coroutine that contains a for loop that spawns a group of enemies with data that is scoped to that for loop's lifetime.

I naively thought that I could simply scope this by having a system that starts a job, which starts another job within, but I'm told this is not supported.

So, I'm now trying to figure out how I can scope data to each group, so that enemies spawned for this group can take advantage of chunking.

One idea was to spawn a group entity which then instantiates enemies with a "GroupData" component, but this is probably wasting memory, as the enemies would depend on the group entity and it could persist for the whole game, meaning that we have a pretty big chunk requirement if we wanted to spawn loads of groups. Otherwise, it could need to be deleted once the enemies are spawned...but I'd rather it be flatter, and we just allocate chunks for the enemies.

Another idea, and it's a sort of compromise, is to instantiate enemies with a marker component, marking them as "non-initialized".
Then I'd initialize them in a system looking for the "non-initialized" archetype, which takes the next required component data from a central buffer, sort of like a factory.
This also has me concerned about chunking, as this requires a chunk that would only ephemerally be utilized prior to the near instantaneous initialization of the enemy. Of course, we could just make this a really small sort of "staging" chunk so that it doesn't have too much of a footprint.

But honestly, I think it could be flatter still, as the staging chunk idea could be an issue if we try to initialize a ton of enemies at the same time.

Is there some general wisdom you could bestow on me, or even a known DOD pattern that I could leverage for this problem?

Thanks!

leaden plaza
#

After a bit more research, it seems like the factory style instantiation would be pretty good actually!

Given a chunk size of 16 KB (16,384 bytes), and considering approximately 128 bytes for the header, we are left with approximately 16,256 bytes.

So, number of Entities per Chunk = 16256​/16 = 1016

I've learned that there is practically no overhead for tag components, and thus ~1016 is plenty.

I think this is the way to go, would you agree?

devout lantern
#

A tag that is also IEnableableComponent can solve the problem of archetype.

#

In this demo, I use a NeedsInitComponentTag that is enableable to prevent other systems from processing the newly spawned entities until they're fully initialized with correct data.