Companion Gameobjects, What's Next?

Unity Engine
, , ,
1

Companion GOs at its present state is incredibly limited, only officially supporting a select amount of monobehaviors as hard-coded in a static class list. An internal method normally used for testing can be accessed to expand the list dynamically but is clearly not intended.

What is the future of hybrid workflow and companion GameObjects? Why is CompanionLink even internal in the first place? Deleting the link from server worlds requires internal access which is very annoying.

Edit: I just realized I asked this question twice. Well, this is more on the companion GO and my earlier question was on hybrid components…

2

There are no further plans with Companion Components. They just about work in a very narrow set of ways, and even those have a lot of special exceptions we had to write into the code to allow this. For server worlds, it’s probably better to not have those Bakers run at all, which can be done with Baker assembly filtering with NetCode. This would stop your server version even getting them in the first place.

1 Like
3

If there’s no plans moving forward with Companion GOs, what’s going to happen to features that only exist in MB land and not yet replicated in DOTS (which was the second question that I duplicated).

4

Honestly, just get rid of Companion Components.

5

I guess what you’re specifically asking is- how do you use these GO-only features in DOTS?

It’s important to remember that the GameObject Scenes are still there, so things placed in them can be accessed at runtime. You can’t easily drag and drop a binding to them due to current limitations, but it is straightforward to have them in a static class you can look up and reference things how you like at runtime.

Another path is to use Prefabs, as Entity Scenes support Unity Assets. In this case you can keep a reference to a Prefab asset and at runtime spawn the game object, then do whatever you like with it from your Entities code.

In the long run we don’t want it to be this involved to work with both, but this is how it will work for 1.0.

2 Likes
6

Huh, interesting idea. I was hoping for a deeper integration of existing GO features, particularly sprite renderer, without the need for a IJobParallelTransform intermediary. If I could just feed the local to world 4x4 and call the Render() using direct data.