Question about using DOTS versus a custom system

I am currently brainstorming the way i will approach creating my game and i have the following question:
Is it better to use DOTS(in particular ECS) right now or go for some custom system nested inside MonoBehaviour?

What i mean is that i need to have large amount of data in my game and as we know, MonoBehaviour system doesnt work well with large amounts of gameobjects.
I have a choice of approaching it with the way games like RimWorld approached it (as far as i know, RimWorld uses MonoBehaviour for rendering, while building the final mesh and texture in a separate system and managing all objects independently)
OR i can try and go for DOTS. My current concern about dots is that because it is still in preview different things may change and also the documentation and tutorials can be outdated. For example which way is correct to load sprites and tiles with ecs and build a tilemap?

So my question is whether i should go for DOTS and figure it out or approach it the way RimWorld did?

 

Imho this is the main problem with DOTS right now. It still changes. A lot. Documentation is outdated.. tutorials as well, finding a solution to a problem can take a real long time. It's very powerful tho. For most people, it will probably be orders or magnitude faster than what they would come up with. However, for most applications you really do not need this performance. So it's rather a matter of you estimating what you are actually going to need for what you are attempting to do, and whether or not it's worth to learn, use and maintain DOTS for it. If you are only looking into it for ECS i would probably not bother. However, if you need to parallelize a CPU-heavy workload which may otherwise affect frametimes, it may be a viable solution for just that. Even in realistic scenarios, you can expect speedups of 10-100x.

So think about what you really need to do and whether DOTS is a good solution to that. Maybe do some prototyping and testing to get an idea about expected performance problems. As a rule of thumb, unless you have several thousand, or tens of thousands of entities, most of the time DOTS wont be required. It's also a matter of whether you already have some experience with DOTS, or if you still have to look into it, which may take some time. For some of the cases where i would use DOTS, a compute shader can also be a viable alternative - especially if it's a non-GPU-intense game.

 

I suppose that it will be enough for me to avoid dots for now. I mostly need to procedurally generate large tilemaps and for that i think i could build a custom mesh or a custom texture and assign it to a large quad and assign it to a single game object to avoid having a few thousands separate game objects. and for parallel computing, DOTS is of course good, but well as you said, it is still changing and all documentation is outdated so i think that it could be substituted somewhat by c# native tasks.

 

I actually used DOTS for some procedural generation (marching cubes based) in the past. However, i used it to heavily reduce computation times, which could also have been done by a compute shader. In your case, if i understand you correctly, you are mostly worried about having too many separate game objects.
Do these gameobjects have other components attached besides the Transform and Renderer? If not it may not be a problem. I did no testing on this, but what the Unity engine eventually struggles with is calling and maintaining all the functions on all the Monobehaviours involved.

If you are worried about drawcalls, or run into other problems due to the amount of gameobjects, there is some functionality to merging and combining meshes, like CombineMeshes.
https://docs.unity3d.com/ScriptReference/Mesh.CombineMeshes.html

Depending on the type of game you are going for you may also want to use chunking with appropriately sized chunks. Then again depending on the game, you can disable some chunks that are out of range, such that you only need to work with a limited amount of chunks at a given time. Generally speaking, it is bad design to let any given system snowball out of hand without any limitations. So if your game can potentially create a hundred, or a hundred thousand game objects, you need to do something about that. If your game created a fixed amount of, say, ten thousand gameobjects, you may want to take that number and reduce it, for example by increasing chunk sizes, or whatever is applicable in your situation.

Sadly i dont really have experience with tilemaps, but i suppose you could employ something similar to an QuadTree, just in reverse, where you merge already created tiles once a quad of the next size was fully filled, thus heavily decreasing the amount of involved single objects and draw calls.