Just gamedev ux / dissonance wise: Why can only “arbitrary” types of components be seen in prefabs, while others only added from code?
I suppose the very long term goal of Unity is to completely move to some form of ECS, when it’s full featured and friendly enough, and not require all this bridging between the Mono assets side and ECS side.
But I don’t like not having an in-editor visual saveable asset with all its creation-time necessary components on it.
Does anyone do any workarounds, or y’all okay with surprise hidden components appearing from random hidden systems?
Fair, I mean you can’t make a Mono Authoring for a ISharedComponent – the baker doesn’t recognize it; so you can’t “put it on” a gameobject or on a prefab.
It was a project management concern. For example, you want to have a player prefab file, that has all the data the player needs in one place. Your team looks at it, and knows everything about it.
But if some components can’t show up on that prefab, then you don’t know what’s going on and where the data is coming from.
Oh is that right? I was looking at the now removed [GenerateAuthoringComponent] which was known to not support ISharedComponent.
Thanks!
While on this topic of being able to see the data, can you / how do you do this for components of Systems?
Systems always have their own entity, and can have components added to them, as of 1.0. But systems are created automatically – you can’t make a mono authoring for a system, right?
So in that case, if I want a PlayerSpawnerSystem, which has various components e.g. randomness generator, spawner state, whatever. I create these components, and their authoring mono, and put the on a game object / prefab.
But they won’t actually be on the PlayerSpawnerSystem, because that only exists at runtime. So it’s a bit annoying / confusing, that my system’s components are not actually on the system’s entity.
I suppose I could move them to the system’s entity at runtime, but…
Can’t be better answer. Can only add that there are no direct equivalence between GameObject and some Component now (as it was in past days of AuthoringComponent existance). It is up to you as programmer to convert some editor representation (unity mono component) to optimized internal entity representation (IComponentData, ISharedComponentData, IBufferElementData) and you can do “single to multiple” and “multiple to single” relations between mono and entities worlds.
Do not tie spawner parameter to the system. Make a component that defines all spawn parameters and use it. I have made exactly the same task as you mention in mine Rukhanka samples. I have an spawner system to spawn many animated prefabs in scene. I’ve made a component with prefab list, spawn count, spawn radius and spawn delay:
PrefabSpawnerSystem consumes converted by baker SpawnPrefabComponent, spawns needed number of prefabs and removes it from entity. By this approach I can spawn things many times and it is flexible because code (system) and data (component) are decupled.
Another example. To configure some global debug parameters I have created DebugConfigurationComponent, that has corresponding authoring script and created as singleton in entity world (idea is taken from UnityPhysics package configuration). Various systems that require to be switched in debug operation mode read data from this singleton. But there is no direct intersystem communication.
Yeah alright, good examples. But it would be nice to also be able to bake onto system’s entity directly. Hmm would be nice if you could, in an Authoring Baker, find and specify on what entity you want to AddComponent.
You forgot that baking process is split into two phases: Baker and BakingSystems. Documentation says:
“A Baker can only add components to the primary entity that it’s baking and the additional entities created by itself.”
And:
“Baking systems are regular systems that process the output that a Baker produces, for example by combining results.”
Bakers can be used for simple use cases solely. For more compilcated cases use BakingSystems and do whatever you want in them.
