Question regarding DOTS and the old Unity workflow

[Joachim_Ante_1]

1. We have no plan of replacing MonoBehaviour or game objects. We are building a different way of writing code that can be used to do everything you can do with MonoBehaviours. For those who want to use it, we will invest a lot in making it be a simple & effective way of making a game

2. At the moment our strategy is to keep the editing tools mostly the same (Fixing scalability issues to support the scalability DOTS can achieve at runtime) but really our authoring format continues to be game objects with scenes, prefabs and various assets. We do this by using converting game objects to entities.

This is what we had around April:

New SubScene & ConvertToEntity workflows

With the Unity.Entities release today, we are adding support for SubScenes and the new ConvertToEntity script. The main concept is that instead of using ComponentDataProxy / ComponentDataWrapper. We simply convert existing game objects or MonoBehaviours to pure entity data. This is the same workflow we used to build the MegaCity demo. This makes it possible to create content for Unity.Entities in an effective way. We have updated the HelloCube samples to show it: This scene uses ConvertToEnti…

We are currently investing in making the conversion process live & better visualize what is happening as well as debuggable.
This gives a good way forward for content to easily be moved over to DOTS.

3. For the runtime. Our short term goals are to get as quickly as possible to a point where you can make a game with pure DOTS runtime simulation code and GameObject based authoring. So we want to make it that you don’t need to use any simulation code from the game object world at runtime. Solving issues like instantiation performance, load speed, everything becoming multithreaded. Following principles like determinism by default, networking, performance by default and much more. (Eg dots based Animation, VisualScripting, Netcode, Audio, AI, physics) Check out Unity.Physics for a good example of what we would like to achieve in those areas.

4. The realistic path to a well working renderer is to build on top of HDRP / LWRP. In the same way we have done in Megacity. (Low level API BatchRendererGroup gets added to Unity and Unity.Entities uses it to make a scalable renderer on top of SRP / HDRP / LWRP that connects with the game code and simulation systems) There is clearly much more work to get to completeness in this area, eg. VfxGraph, decals, light baking, texture streaming, skin mesh rendering and more.

We think we can get to a reasonable place that covers many game genres with DOTS in the first half of next year. Again we do not think of DOTS as something that replaces it. It’s something you can choose if it makes sense for your production.