Question Just Components and Systems without Bakers?

May we expect in future versions of DOTS more usability for better workflow?

For example
1) Drag & drop Components to entities without using Mono Bakers
2) Work with entities in inspector like with gameobjects
3) Create entities prefabs

I've just watched video about Godex and I am upset that DOTS are way less intuituve and way more overcomplicated.

I want to use DOTS for performance, but current workflow requires too much overengineering.

 

ECS without baking works great with really trivial setups like the one demonstrated in that video but quickly breaks down with more complex entities. It should be known you can still drag and drop an authoring component to a gameobject and have a 1:1 workflow if you choose. With 1.0 you can edit authoring data in the inspector and have ecs update to changes(which I have found finicky if we are being honest). Your authoring prefabs are entity prefabs.

With ECS, the most optimal setup is usually quite granular(for performance) and thus would be extremely tedious to setup without baking.

Lets take Physics as an example. For entities that you would think of as your traditional rigidbody gameobjects, each may or may not contain a:
- PhysicsVelocity
- PhysicsMass
- PhysicsSharedWorldIndex
- PhysicsDamping
- PhysicsCollider
- PhysicsGravityFactor
- PhysicsMassOverride

Not to mention every non static physics entity is deparented into root world space by bakers, so you would have to author all of those things in root space too without baking.

Do you really want to be individually adding and configuring each of those components every time you want something to have physics? Or would you rather have one authoring script that contains a few tickboxes which handles everything behind the scenes?

Baking already exists with things like asset importing, take a 3d model which opened in a text editor would be a bit of an incomprehensible wall of text. Unity takes that, bakes it into a human readable format where you have a transform, meshrenderer and meshfilter and possibly parent/children and its seamless. You just never noticed it because when done right it works behind the scenes. I agree we aren't quite there yet with ECS baking, but the idea is the same.

 

thelebaron,

Perhaps I formulated my thought incorrectly. It's not specifically Baking that annoys me, but the need to duplicate essentially one script 2 times and weird sintax.

I would like to just make a script MyScript : Component and assign it.
That's it. It's completly enough. All other stuff Unity should handle behind the scene.
There are plenty realizations of ECS where its done like that.

So I want it to look like that.

Code (CSharp):

1. public struct Health : Component
2. {
3.      public int health;
4.      public int healthMax;
5. }
6.  

You see? It looks very clean, beautiful, compact, decent.
That's exactly what needs to be done.

 

We used to have [GenerateAuthoringComponent] for simple component types. However, Unity hasn't released an equivalent for baking yet. But such a solution is only really viable in the simple cases. Do anything more advance, and you need explicit baker scripts to define the data transformation from an authoring-friendly to a runtime-friendly representation. Unity can't do that automatically, and it would be a disaster if they tried for some of the advanced use cases.

 

DreamingImLatios,

I can explaing why your argument is not correct.
Basically you are saying that in 1% of cases my solution will not be perfect.
And you think that in order to have a better solution in 1% of cases we should waste time in 99% of cases.

But the thing is that it makes much more sense to have fun 99% of the time and just spend some extra time in 1% of the cases.

 

https://forum.unity.com/threads/generateauthoringcomponent-in-1-0.1342727/#post-8488502
There's supposed to be plans to work along these lines anyway.

 

Spy-Master,
I've read the thread you've linked and it feels quite the opposite actually

 

Please don't put words in my mouth. My view is that it is necessary for us to be able to write bakers explicitly for some percentage of use cases. Does that mean that should be the only solution? Probably not for you. For me, I rely heavily on a stat-state pattern in a lot of my gameplay code, so I am almost always splitting every authoring component into at least two runtime components.

But besides that, there's a whole bunch of other useful things you can do with bakers. You can run validation checks and filter out bad data at bake time so you don't have to have it at runtime. You can invert masses or convert FOVs into cosines. You can clamp values to something sane. You can automatically populate fields that weren't populated prior to baking. ECS is aimed at production use cases where the best data representation for designers is drastically different from the runtime. The more you optimize your game code and work with such designers, the more frequent these divergences will make themselves apparent, and the more you will appreciate the ability to write explicit bakers (assuming you get that far).

As Spy-Master pointed out, Unity plans to present a simpler workflow for simpler use cases, while still leaving the existing API intact for people like me. I suggest that if bakers make you miserable right now, that you wait for Unity to finish their new workflow.

 

What is the stat-state pattern?

 

So let's say you want to add a gun to your game. Now a gun has all sorts of data associated to it, and there are numerous ways you could divide this up into separate components. Compared to OOP where everything just gets shoved into an object, this set of divisions can be overwhelming, and sometimes you just need a place to start.

For our gun, it has some properties that don't really change at runtime. These include the magazine size, the fire rate, the reload time, the bullet prefab entity, and the muzzle flash entity. These are "stats", so put all of them inside a GunStats IComponentData. The gun also has "state", such as bullets remaining in the magazine, and timers for when the next bullet can be fired or how much time is remaining in the reload operation. That goes into a GunState IComponentData.

Now, you write GunSystem that writes to GunState and reads from GunStats along with some other components related to the rest of the game. And that system can use a command buffer to spawn bullets and muzzle flashes. Other systems are allowed to read GunStats and GunState, but you should make it a point that only GunSystem ever writes to GunState.

This is the stats-state pattern. The beauty of it is that it provides a low mental-energy default way to design your components and systems and get you out of decision paralysis, and is based on a very simple principle, which is what data you expect to change regularly versus rarely. Eventually as your game evolves, you will find ways to refactor away from this pattern and make things more modular where it matters. If a state component gets especially unwieldy, a typical next step is to split it into public and internal state components, where other systems are only allowed to even read the public state.

Another benefit that I discovered kinda by accident is that it is an easy pattern for others to mimic, so it is especially powerful if you are working with others new to ECS.

With all of this, I usually have a single GunAuthoring component. That way, all my serialized authoring data remains intact while I evolve and refactor the runtime representation.

 

I realized that I actually used something like this, but just didn't formalize this pattern in my head. Thanks for a great description of it.

 

Just out of interest, is there a particular reason you decided to go with all "stat" data inside an ICD as opposed to making it in to a blob? I'm currently in the same situation myself and I'm having difficulties deciding which route to go.

 

If you get over the fact to write the same data twice you'd realize that it's a very clever system. Runtime data and authoring data isn't the same for the most part. Unity doesn't design for easy cases but also complicated or very complex ones.
So what a programmer can do is to design very nice authoring MBs for designers and convert them to one or more runtime components or buffers. As there's no direct link between them other than code that can be changed it's also great in case something changes with the required data. (Which is a total pain if you only have one dataset.)

On the state of [GenerateAuthoringComponent]. It wasn't good and it's for the best that it got removed because it entangled runtime and authoring data.
Copy & paste exists, as does templates. The code can be written very quickly.

 

Enzi,
Are you serious about copy and paste "solution"?
We not only create scripts, but we also change them. So doing it twice all the time is annoying.
Also you mean that I can create a Vector3 and bake it into 3 floats? Actually I don't see any problem in giving the designer just three floats with proper names.

P.S.
People who understand the beauty of simple and convenient solutions, do not worry - I will fight for us to the end, despite the fact that I am alone, and there is a whole army of overengineering fans.

 

There's a lot of stuff that can't go into blob assets. Entity references are a big one. Other BlobAssetReferences are another. But sometimes I use RNG to initialize some stats too, or copy a stat value from whatever instantiates the entity. Then whatever is left is usually too small to justify making a blob asset. That doesn't necessarily mean that I won't switch later. But usually what ends up happening is I have some variable-length array of data and/or some cold data that qualifies as stats, and in such cases I build a blob out of that array and stuff the blob reference in the stats ICD.

 

Thank you.

I've been agonizing over my component design for the past week, and I could feel my anxiety dropping as I read this post.