Could Unity do with some built in interim API features between GOs and DOTS?

Unity Engine
1

Unity’s GameObjects have a few weaknesses built in that DOTS goes out of it’s way to solve.

The many objects performance problems of Update()/FixedUpdate() and the instantiation/destruction memory problems to name two.

There are a number of ways for developers to write interim solutions in this GAP e.g. Manager objects and Pooling systems.

However what if Unity designed interim solutions for this GAP with the aim to not only make it easier to solve these issues in a Unified way but also to allow a smoother transition from GameObjects to DOTS for programmers?

Unity has a lot of features that help span the gap but they are disjointed and require more work/learning for the developers/game designers.

Or instead of thinking of Unity as two disparate systems at separate points but a range of systems that span the problem domain issues of game development.

Could we get to a version of Unity where going from GameObjects to DOTS is as easy as changing a loop from for to while?

1 Like
2

Probably not. An Entity is not a GameObject. It’s more like just an index number.

I don’t think there would ever be consensus on what this “unified way” would be.

A good developer understands their data well and devises the correct solution. Holding your breath as you develop with GameObjects while imagining in the future you can do something today to predict how it will go to ECS/DOTS, well, that is a complete and colossal waste of your time.

Understand your current data and data transformation needs, learn from others as best you can, focus on the currently problem context only, develop your own methods, move forwards, ship games today.

3

Well what if a GameObject (GO) was just a group of entities.*

Unity could then easily provide a managed API that cycles through groups of game objects quickly as per DOTS.

A pooling system could be introduced that then works across DOTS and GOs.

Transitioning from GO to DOTS would just be adding levels of data filtering or refinement/optimisation and multi-threading.

*With a WYSIWYG editor for entities/GOs developers would just see the current Unity API as a group of DOTS entities and pre-packaged API calls to those entities.

4

I’d rather Unity focus on wrapping up the DOTS system implementation, and getting detailed documentation/tutorials out. I’ve played with it a bit, but am afraid to actually build anything serious with it since the system’s implementation seems to be in flux, and help if I get myself in trouble is pretty limited.

1 Like
5

What if you could write GO code then optimise it into DOTS code more easily, would you need as much help or documentation?

1 Like
6

That sounds like something where you’d need even more documentation to explain what exactly is happening, and any potential pitfalls, than just writing in DOTS from scratch. I like your idea in principal, but I’d expect the same devs working on DOTS would be needed to implement this, which means they would have less time for DOTS proper in the short term.

7

In theory you could have non-core DOTS programmers just re-implementing DOTS features to replace standard API features. And it could work as an internal test of how good the DOTS api and documentation is.

1 Like