Question What are best practices to Design a DOTS game

Hello everyone,

I started using Unity about 4 years ago with the standard Mono workflow, but around 16 months ago I saw a video made by @Joachim_Ante on Youtube talking about the performance by default of DOTS and all its advantages.
I immediately fell in love with DOD and started reading "everything i could find on the internet".
later I started a new game project with a small team of 4.

the only thing i cant find on the internet, is how to Correctly/Professionally Design a Game or even a complex System using DOD. obviously that didn't stop me from creating systems using known Patterns, like maximizing system reuse between different entity archetypes like health between anything damageable and minimizing reuse of components between systems to maximize parallelism between chunks.

Does Unity plan to offer Courses/Best Practices on recommended Patterns to develop Games/Systems using DOTS?

I've seen people on the forum working on some really good DOTS based games. Can you please share with us your best practices, tips and development workflow?

Thanks!

 

I don't think there are any of such. People will rather look into docs, which is even sparse at current state of dots, or look in source code, of specific packages. Also asking on the forum, is a way to educate self. There are also few good blogs, discussing certain Dots elements.

Regarding best practices, I am pretty sure, people still exploring for such. Dots evolving so fast, it would be very difficult to set specific pattern. Sure there are certain principles as you found out yourself.

But for example I remember first FPS sample. I really didn't like its code. Sure it was good learning reference however. New FPS sample maybe is better on that level.

I think also, the pattern which doesn't require of determinism, may be quite different for the systems and related games, where determinism is required and critical.

Lambda and SystemBase approach also will affect the pattern, in comparison to JobComponentSystem.

 

I am working on a primarily DOTS game. So far I haven't found there are any best practices. Mostly the reason for this, is that DOTS itself cant really be used wholistically build a game. It is not yet complete enough for that.

The Hybrid renderer is just not useful enough to use yet, and so you have to engineer with bits from DOTS and bits of GameObjects. So, there is no one nice way to make a DOTS game.

Also, that it changes so quickly, that most videos/sites are out of date with their examples/tutorials.

So, there arent any best practices. You have to fight fires at every turn and just keep trying to move forward, being prepared to write subsystems that dont work in DOTS yet.

 

I find that thinking backwards, or thinking that you are programing for a database works.
For instance, you do not put a DynamicBuffer on your inventory that says what are the items on it.
You place a SharedComponentData pointing to the inventory on every item.
In other words, you don't declare 'inventory have those items', you declare 'those items are in this inventory'.

This probably don't work every time, but sure helps to 'try thinking it backwards' when you are having issues with a specific problem.

Maybe another way of stating this would be: Try giving inherit meaning to EntityQueries

 

I'll give you a tip, whether you want it or not (more on that in a second).

In OOP, you typically try to solve the meta-problem (the generalized problem), and then you solve the actual problem. In DOD, you solve the actual problem, and then you solve the meta problem if the actual problem keeps reoccurring in different contexts.

For example, you have asked for people you have seen on these forums working on "good DOTS based games" and you want insight into their development. Each of these projects is a different problem with a different workflow and the question will yield different answers. What you just did is abstract away the individual queries to the specific projects you have seen into a general composite query. Worse, that query is not well-defined. How do I know if my project is one of the projects you have seen? How do I know if my project constitutes "good DOTS based games" from your perspective, which may be different from mine? Those criteria are abstracted and now I have to make assumptions without certainty.

What I would consider a better approach using a DOD mindset would be to call out the individual projects you have seen that you believe are "good" by linking forum threads, project repos, reddit demos, or game pages on its respective game store site. If that starts to become tedious, you can identify ways to automate the process (the meta-problem). Doing it this way, the details of the problem you are trying to solve rise to the forefront. You'll then be able to identify your inputs and outputs (questions are inputs, answers are outputs) and refine them such that you scaffold away the implementation details (asking short and simple questions) without losing the well-specified definition of the transformation (who is expected to answer and how).

 

Unity recommend in learn pages this https://www.dataorienteddesign.com/dodbook/, not focused in DOTS, but help me.

 

I believe it may be difficult to get good answers here, because the question in your OP is very open-ended.

It would be like asking for some good principles for writing OOP based games. That’s a very open ended question - there are countless ways to use OOP to organize good game code.

Similar to OOP, writing a good game with DOD patterns is more about understanding the building blocks very well (Jobs, Burst, and ECS) - well enough that you’ll intuitively understand how to use them to start solving the problems in your individual game projects.