When I heard that Unity was building a new ECS architecture, I didn't think much of it. In general, I've been underwhelmed by Unity's API and overall architectural design, since it has always placed clear emphasis on ergonomics and usability over performance and correctness[1]. As such, my expectation of a Unity ECS was that it would likely give up many of the benefits of an ECS architecture in order to be as user-friendly as possible.

Recently, though, I've been looking into the specifics of the upcoming changes, and I've been pleasantly surprised by what I've seen so far: A "performance by default" mentality, a truly data-oriented architecture, an emphasis on correctness in the face of heavy multi-threading, all while allowing developers to use a high-level language like C#. While I'd love to talk more about all the ways in which this makes me genuinely excited as a professional Unity developer, I want to talk instead about how this makes me excited as a Rust game developer.

For my personal game development project, I've been using the Amethyst game engine. Amethyst is a Rust game engine that uses a data-oriented ECS architecture to allow for highly performant, highly parallel game code. The ECS architecture is a natural fit for Rust game development, as Rust's semantics make high performance data transformations easy without sacrificing memory safety. Amethyst has been fun to use so far, and most of the issues that I've run into have been due to the project being relatively early in development, all the rough edges to be expected from a young piece of software. That said, there has been one issue that has the potential to stick around even as Amethyst becomes more polished: I don't know how to work with an ECS architecture.

While I wouldn't consider myself to be a strong adherent to object-oriented programming, it's hard to deny that object-oriented design is considered the default in my industry. This is especially true for Unity development, where C#'s design as a programming language heavily pushes developers towards object-oriented programming (to say nothing of how Unity's API design effectively requires it).

As such, the shift to an ECS architecture for my personal projects has been a difficult one: I can figure out how to do simple things, but I often find myself unsure how to correctly structure more complex parts of my game. Even when I'm able to make things work, I can't shake the feeling that I'm hacking things together rather than doing it "the right way".

This lack of understanding of ECS design patterns is why I'm excited by the prospect of Unity bringing ECS design into the mainstream. As Unity's new ECS functionality begins to see widespread usage, we'll see discussion in the game development community about how to best structure game code, what patterns can be followed to accomplish common goals, and how to best address common pain points that arise from using an ECS architecture.

I see two major benefits to this:

First, the new ECS design patterns and learning coming from the Unity community will directly benefit Amethyst developers because they will be, for the most part, directly applicable to Amethyst games[2]. This is hugely beneficial because the Unity community is substantially larger than the Amethyst community, so it's going to be able to figure things out much more quickly than the Amethyst community would be able to on its own.

The second benefit is that this will lower the barrier to entry for developers looking to get started with Amethyst. Right now, a Unity developer who's interested in trying Amethyst will have to contend not only with learning Rust, but will also find that they can't use any of the object-oriented design patterns that they're used to using in Unity. But once Unity developers are used to an ECS structure, learning Amethyst becomes a much easier process.

While it's going to be a while before I'm likely to use Unity's new ECS for my professional work, I'm already excited to see what changes it brings to the game development community. This shift is going to be a big one, but it promises to benefit both the Unity developer community and the Amethyst community, which is very exciting to me as someone who relies on both engines. I'm excited to see what the future brings.

  1. Don't get me wrong, I appreciate how Unity's design makes it very friendly to new developers, and I'll always believe that Unity's greatest contribution to the game development industry has been the way that it lowered the barrier to entry for game development. But as a professional Unity developer, I constantly have to struggle against Unity's design in order to make my games run well or to avoid making them buggy, which has eroded a lot of the good will that Unity earned in making a user-friendly game engine. ↩︎

  2. I've been surprised to see just how similar Unity's ECS is to specs, the ECS library that powers Amethyst. Check out this gist for an example comparing the two APIs. ↩︎