Moving existing projects to DOTS

Hi
I am trying to upgrade my existing project to DOTS framework. Can you please help with any resources that will help me understand the steps involved in the upgrade?

Thanks in advance.

 

Try the ecs examples. It has lots of examples and many people refer to them when they need to know how something is done. There is also the best practices posted here on the forum

 

There will be no single guide for upgrading project to DOTS. Every problem needs different solution. You need to think about your data access patterns. Read a best practice guide.

 

I have started to think that there could be a Mid OOP - DOTS solution where every method in an Object becomes a system and the function calls and properties are turned into Data.

So could there not be an automated conversion process that takes apart OOP systems and converts them to DOTS or even better a way to make OOP design into DOTS systems?

 

The problem is still not the syntax. If you can write OOP which fulfills the restriction of the DOTS systems (blittable types), then you can write Components and Systems too. So there is no real value to convert a thing looks like an OOP class into entities components and systems. The hard work is to find the way to do the thing with proper memory management.

Sure, as soon as Unity wins the Epic mega-grand five times in a row and develop an AI which can code DOTS properly based on an OOP code base, they can give you an API to convert your code into DOTS.

 

Is it really that complex to write DOTS code as I assume it would just be converting functions to Systems and their parameters/properties as data structs?

So what are the big roadblocks for some automated or templated way to convert OOP code to DOTS?

 

Define 'complex'. It is not complex in the ordinary meaning of the word complex. But you don't write DOTS code the same way you write OOP. That's why it requires completely restructure your application if you convert it from the Game Object world (nothing to do with OOP or not) to the DOTS world.

Functions can contain anything. From a single command (easy to convert) to an entire application worth of complexity.

Computer simulated understanding of problems is very-very non-existent at the moment. Humans can recognize problems, intents and solutions, even patterns better than computers. When the AI can write themselves, then maybe they will be able to convert a game object code base into a DOTS code base. There is no real 1:1 connection between the two as soon as you leave the "oh, here is the bullet, let's replicate it 100,000 times and we're done"-territory.

 

Once you can fully articulate every design pattern, every dependency management pattern, and every structural pattern ever used in every Unity project that exists or has ever existed, then I will believe that this problem can be solved. Until then, I don't believe you, nor anyone for that matter understands this problem well enough to actually solve it.

Baby steps that work on a small subset of patterns may be doable. But they don't offer much value to Unity. So if you believe it is possible, I encourage you to try it yourself.

 

Maybe not a great analogy but look at automated translations from one language to another. It is easy to translate words, not so hard to translate simple sentences but translating a book is very hard and translating something like a poem is even harder. Same things with translating OOD design to DOD, some simple algorithms probably could be translated but more complex ones would be impossible to do right.
Here are some problems:
How to decide which methods should be turned into systems?
How to convert events?
How should classes be divided into separate components?
If you have created some data structures how should they be converted to DOTS?

I would rather choose to improve DOTS, create some commonly used systems than loose time on creating something that is hard to do, and result will be worse than hand porting.

 

I have been writing a plugin that works with both entities and gameobjects simultaneously. The plugin operates with both entites and gameobjects from the same interface. So I have some experience on the differences of both.

Biggest roadblocks that I think are that oop and data oriented systems work differently. Data oriented systems are aimed at speed while object oriented systems are aimed towards ease of use and readability. If this would be doable by scripts Unity or someone would have done that. Maybe thats their end goal, but that I think can happen at most in 10 years(unless, if someone has been working on it for years)

With object oriented systems you are dealing with objects and there are no big limitations on what you can do and what not.

With data oriented design you are limited to basic types and size for everything needs to be precalculated. Also spawning and destruction complicate things, since you need the command buffer to to have that code burst compiled and parallelized. This alone creates a lone lots of issues that are only available after testing it in the editor. For example trying to access data from regular ecs code that has been already destroyed by some commanbuffer group.

Also doing a pure conversion doesn't necessarily maximize the speed. If you want the maximum speed you need to redesign the whole thing. For example if you have many objects that each do something, then one of the fastest way in data oriented world is to just have one pipeline that run all that data in parallel. No objects just data running through system/systems. To make object oriented code that translates well to data would mean that the oop code would need to have data oriented design in it.

Since most optimization cases are different, you would need to have some sort of AI to figure out the best strategy to optimize normal oop game code. It would need to purge all the oop objects/structures, convert them to primitive data and make it run in multiple perfect streams. Also there are no nulls so there would always need to be a basic value for everything.

For example let say you have monobehavior self aware obstacle and for managing obstacles you would have obstacle manager. In DO world you would have obstacle data and obstacle systems, if you want the self awareness then you have think how you can move the self awereness to the systems from the object, since data cannot have functionality in it. I think this would be the biggest issue since script would need intelligence to figure how make that happen, then it would need to figure out how to remove all the technical issues that follow. The end result might not be the same.

 

So in few words you can probably automate some oop code conversion to data oriented world, but it would not scale well, unless its made with data oriented design already.

 

We discussed this already, in one of your previous DOTS thread.
OOP is just having too many variables, to make it any how easy to convert.
For starter is managed and none managed data type. UnityEngine vs Unity methods.
Then complexity starts ramping up.
-using strings
-using delegates, events etc
-using on collision checks
-using nested classes.
-using nested collections in nested classes
-using imterfaces
-classes initialisations

And so on and so forth.

Now try make universal converter to dots, which accommodates all these and more.

I rewrote few OOP algorithms to DOTS. Each OOP written by differet person, with different approaches and standards. It doesn't work just replacing class for strict, or managed collection to native collection.

The process of conversion is basically rewriting everything from ground up, with completely different approach in mind. Some methods can be copied and just slightly modified. But when nesting and other magic tricks of OOP happens, need to rethink them.

There is no 1 to 1 conversion.