Data-oriented design roundtable: Your questions, answered

In December, we hosted a DOTS-focused creator roundtable with Stunlock Studios (V Rising) and Sunblink Entertainment (HEROish, Hello Kitty Island Adventure). We invited these early adopters to share their experiences using the Data-oriented Technology Stack (DOTS), show what features and capabilities data-oriented programming has unlocked for their games, and see how they’re leveraging the latest Entity Component System (ECS) tech in Unity 2022 LTS.

The Q&A was on fire during the webinar, with many insightful questions from the audience – so many that we couldn’t get to them all live. To follow up, we asked Joe Valenzuela, director, software engineering at Unity, and Rasmus Höök, technical director at Stunlock Studios, to answer some of our favorite questions from the session. Check them out below, and catch the Maximize your game’s potential with data-oriented design webinar on demand here.

“Is it better to start new projects with DOTS right away or with regular GameObjects and then optimize performance by moving to ECS (either pure or hybrid)?”

JOE VALENZUELA: ECS, DOTS, and data-oriented design (DOD) isn’t just about better performance. It’s also about avoiding the complexity inherent when you model problems using object-oriented programming (OOP).

Anyone intending to make a multiplayer game – particularly one with an authoritative server and client-side prediction – should seriously consider starting with DOTS. Netcode for Entities offers a really robust, powerful system that scales up and allows you to write straightforward gameplay code.

If you’re not making a multiplayer game, or you are just prototyping and looking to try out new things quickly, you might want to consider leveraging MonoBehaviour/GameObjects.

“Is it possible to create a game entirely on the DOTS system, or does DOTS only support the GameObject system?”

JOE VALENZUELA: No, you’re probably going to need some GameObjects at some point. It’s something we’re working on.

“What are disadvantages or use cases where a developer shouldn’t use DOTS?”

JOE VALENZUELA: You’re probably asking the wrong person – I can’t think of a case where I’d prefer to use something other than DOTS in Unity! But if you twisted my arm, I guess I’ll say that traditional MonoBehaviour/GameObject-based projects really excel when you’re prototyping. When you’re expecting rapid changes, you don’t want to necessarily spend a lot of time making Bakers or designing your data. It’s an area we hope to streamline for DOTS in the future.

“Rasmus, do you have any advice for ramping up engineers on data-oriented programming?”

RASMUS HÖÖK: I think a good start is to just write as straightforward and simple code as you can to solve the actual problem you have. Kind of get into the mindset of a beginner programmer and write very result-oriented code, where the goal is to make the code do what you want it to. The initial goal should not be about writing reusable code, creating abstractions or whatever.

In the context of getting started with ECS, don’t overthink or overengineer. Rather, use larger components and bigger systems at first instead of splitting them up in many smaller pieces. This will make your code easier to follow. Split up later when you have a reason to. We definitely made this error early on.

I’d say a good opportunity to practice data-oriented programming is when you have something you need to optimize. Then you have an actual problem you can experiment with and measure your result. You will also see how important thinking about data is.

“We hear a lot about DOTS being used to scale up and build more ambitious games, but are there benefits to scaling down? Like using DOTS in a small project to target lower-end systems?”

JOE VALENZUELA: Efficient operation on low-power systems improves the quality of the simulation code they can run. It also reduces the battery requirements for battery-operated devices, leading to longer running time and overall system health.

“When switching from SystemBase to ISystem, how do you deal with the calls to managed code?”

JOE VALENZUELA: Technically, you don’t need to get rid of managed code to use ISystem – managed code can be called from ISystem. Its managed data can’t be stored in an ISystem directly – for this, I would use managed component data.

However, if you’re asking, “How do I excise the calls to managed code from ISystem so I can use Burst and get the best performance out of my code?” the answer is… it depends. 

If you’re using .NET containers, you might find a suitable replacement in com.unity.collections. If you’re interfacing with a managed Unity API and there isn’t an unmanaged alternative, sometimes it helps to split the work into “fetch data” and “process” phases, the latter of which is where you do your ISystem-based processing.

“I've read in documentation that ECS is not compatible with multiple scene architecture. So how should that approach be done using ECS?”

JOE VALENZUELA: Nothing in ECS precludes additively loading multiple Unity scenes. However, those scenes will not contain any ECS data, only GameObjects with MonoBehaviours.

You can author any number of subscenes, and each will bake the authoring GameObjects and MonoBehaviour data into compact entity and component data that can be loaded at runtime. Subscenes can be further split into sections and each section can be streamed in or out as needed.

“How [much] does having hybrid monobehaviours/DOTS affect determinism in a project?”

JOE VALENZUELA: Determinism is not a binary state, and we don’t guarantee that every execution detail is identical between runs. Generally, hybrid interoperability is sometimes needed for presentation details like particle systems or audio, where a perfect per-frame reproduction isn’t necessary.

For features like predictive gameplay, you’ll want your simulation running in ECS.

How do you manage hundreds of systems? Do they all run all the time and just not execute logic when there are no entities in the query? Or do you contextually activate systems based on game state?

JOE VALENZUELA: For ease of development, we’ve made systems update by default. The difference in performance isn’t huge, but if you truly have hundreds of systems, you might benefit from making them latent update by calling RequireForUpdate or using the RequireMatchingQueriesForUpdate attribute.

The idiom in that case is to add a RequireForUpdate<Foo>() to the relevant system, and use Foo IComponentData in your scenes as a sort of flag to turn on the update of those systems.

“I understand that DOTS improves performance in terms of handling large amounts of data during runtime, during gameplay (rendering especially, from what I’ve heard). However, I’ve also heard DOTS improves production performance in terms of easing any refactoring needed. Could you speak a little on how DOTS helps refactoring?”

JOE VALENZUELA: A big appeal of DOTS, ECS, and DoD in general from my perspective is that it makes more of your simulation state visible and inspectable. If you’ve ever tried to add tests for an OOP library, you may have run into the problem where you end up having to mock or instantiate a huge amount of functionality in order to replicate the state necessary to invoke a “simple” method instance. With DoD style systems, you can almost always represent a transformation kernel as a standalone function that turns one value type into another.

This is hugely easier to reason about, to test, and to parallelize.

“In my (amateur) experience, I find that DoD creates tight coupling between the data and the architecture, causing changes to data structures to introduce large refactoring work. Is this your experience? How did you handle or avoid this problem?”

RASMUS HÖÖK: In our experience, when changing the data we usually have to alter the code that’s using it, even before using ECS. So we haven’t suffered more than what we’re used to!

JOE VALENZUELA: I don’t think this is a fundamental problem of DoD or even our ECS, at least as it’s evolved over time.

For one thing, the traditional method of breaking tight coupling in OOP is typically to make instance-oriented functions and class hierarchies. While that’s nice in theory, that kind of abstraction is one of the first things to go in performance programming.

There’s nothing preventing you from writing utility functions in an ECS. While it’s true in our ECS you have to revisit systems when you change the data contract for specific queries, that can be a sign that you’re querying data in a scattered fashion. Are you repeatedly transforming component data? Can that be rewritten to reduce the number of mutations per frame? Repeatedly reading component data? Maybe you can hoist it into an immutable data structure early in the frame.

Lastly, I think it’s safe to say DoD, or at least ECS, does make a lot more of the problem state explicit. That’s not a negative: That’s a different tradeoff. I much prefer reasoning about a tight coupling while refactoring than a loose or implied one.

“Does the ECS/OOP work well for mobile games, or can you recommend this approach for a mobile game project? Any risks or considerations?”

JOE VALENZUELA: We’ve had multiple customers successfully use ECS in their mobile games. Check out this GDC talk to see how Sunblink Entertainment used it for HEROish.

“How did you go about networking V Rising? Did you use Netcode for Entities or another framework?”

RASMUS HÖÖK: We made our own framework. We started using DOTS for production very early and were aware of the risks of doing that. To eliminate as many risks as we could, we tried to rely on as few packages as possible and rolled our own when possible. We have always made multiplayer games and have always used our own solutions, so we were comfortable with doing it ourselves.

“Is ECS stable enough for production? We’ve been struggling with it for the past few months with a prototype and aren’t sure if those were growing pains as we learn or if it isn’t quite ready to strive for a pure ECS production project.”

RASMUS HÖÖK: I’d say it’s stable enough for production but it is lacking features that many game developers might take for granted. Our gameplay code is pure ECS in V Rising, but presentation stuff, such as animated characters, particle effects, and UI, are all using GameObjects. Realistically, I think a hybrid approach is the best way for most teams starting a project today.

We made V Rising using a one-way approach. We use pure ECS to only push data to GameObjects, never the other way around. For example, we keep the state of a character in ECS data – input, velocity, etc., that will decide the locomotion state, and what animation should be active and at what time and speed. Then we make sure the animator of the GameObject is in that state. Whatever state the animator is in never affects the gameplay. I think this separation overall simplifies the game.

JOE VALENZUELA: ECS is production-ready and used by customers worldwide, but we have a long way to go until the experience is as seamless as we’d like. Stay tuned for future developments – and thanks for using DOTS!

Make your ambitious game a reality with DOTS, which enables you to create scalable, high-performance games and unforgettable experiences. Get the latest features with Unity 2022 LTS