Released with Unreal Engine 5, Epic introduced as a plugin a feature called Mass. It’s intended as a solution for introducing ECS(Entity Component System) style code into the engine as a first-class feature supported by Epic themselves.

Apologies for all the upcoming Mass puns. I massively couldn't help myself.

This page is going to be an introduction to Mass, providing both the context around its creation and a shortlist of links to help find good references and links to my other pages covering Mass.

TLDR for those mentally converting ECS to Mass:

• Entity -> Entity
• Component -> Fragment
• System -> Processor
• Table -> Archetype

Links

Here are my other blog posts about Mass, because it’s my website so I get to go first.

The UE version that the blog post is referencing will be updated and specified in the page itself btw, in case I make another version to keep things up to date and the previous version’s information isn’t lost to time.

• Mass Entities
• Mass Fragments & Tags (Components)
• Mass Traits & Entity Templates
• Mass Processors (Systems)
• Mass Archetypes (Tables)
• Mass Actor's
• Debugging Mass
• Mass's Networking Overview

Official Documentation

Loading video…

Loading video…

Unofficial Documentation

Repositories and Projects

Here are some available Repositories and Projects that are helpful in showcasing Mass usage in different ways. Or just a related project that isn’t Mass but helpful to be aware of.

Context

To answer that question requires context that is nearly two decades of information condensed in a short few sentences, so be aware there are a lot more details I’m leaving out just to explain the Why.

Why would Epic add ECS to Unreal?

The way the engine is architected is using an Actor + Components system;

• Actors are containers for Components, and are the only placeable thing in the world. So if its in the world it is an actor.
• Components are containers for logic and functionality in a modular way.

Now this has worked great since the 90s for a few reasons:

• It’s simple to design with and allows for inheritance.
• You can rearchitect core systems in a modular fashion if used appropriately.
• It scales an ok to fair amount.
• Performance can be great but with a lot of work.

Those last two reasons I want to lock in on, SCALE and PERFORMANCE. It’s worked great for what used to be AAA-sized teams and budgets, but the AAA of yester-year is different from today. AAA used to be between 50-150 teams, now that means 100+ minimum and thousands of developers.

It’s buckling under the weight of that scale. Many developers that pay a lot of money to Epic for direct support regarding problems they encounter at this scale have been complaining that the engine can’t handle this measure of scale. Even Epic has admitted that without very specific modifications they make for Fortnite, it can’t scale to that degree. They’ve introduced a bunch of tools and features to alleviate it(even rolling their own physics engine called Chaos) but none of it is truly solving the problem is the scale of all these different components interacting with each other. It got so bad that they started allowing the engine to render meshes without needing an actor or component that developers can implement themselves in C++ to draw meshes for better performance.

Regarding performance, for a while it was serviceable with actors and components and combining a hybrid of data-oriented and inheritance, but it always ended up favoring inheritance at the end of the day sadly. But games have gotten larger and more detailed, and as a result, the process of actually spawning simple objects can be a heavy task and thrashes the CPU with ton’s of cache misses.

Cache misses are when the code requests data from the CPU cache but we find that it's not stored in the cache so we end up having to go fetch the data from memory which is slower and then we can do the read/write operation. This is commonly referred to as CPU thrashing.

For more details you can read GeekForGeeks's Blog post on Cache Misses

Typically a more data-oriented approach was more performant but required more tooling and more effort just to make the UX friendly to designers and artists and not just engineers.

So why didn't Epic rewrite Unreal Engine 5 to just use ECS internally?

It’s not that simple, there are two main factors with that:

• Licensees
• The Effort Involved

Licensees

Licensees are developers paying for direct support from Epic and have licensing deals with them for being able to use and release products made using Unreal Engine.

If Epic just decided to rewrite something that negatively affected a licensee, and they provided no path for adoption/migration, Epic would probably receive some lawsuits that would probably bankrupt the company since they’re paying for their direct support.

While yes, each major engine version (Unreal 4, 5, and at the time of writing recently 6) has its own license agreement, some may have agreements written that were supposed to cover that transition between major versions.

The Effort Involved

Epic not only makes Unreal Engine but they have a little game they support using the engine called Fortnite and surprisingly makes more money than the engine for them(can you tell I’m being sarcastic?). Making those changes into Fortnite is a little bit easier, but there is a lot of code written in Fortnite around the Actor/Component paradigm. And that itself is a MASSIVE amount of work. If they wanted to introduce a fully ECS game then it would have to first be rolled into Fortnite as the test bed and that requires rewritting the engine and the game entirely.

Then there’s the process of integrating it into the shared version of the engine that everybody else gets, which is… a process…

Introducing ECS

ECS(Entity Component System) is a paradigm that focuses on a fully data-oriented approach for both reading and writing data. You can find tons of resources online talking about ECS and how it generally works and tons of repositories as well implementing it.

As a result of how the data is accessed, the cache miss rate drops dramatically, which brings significant performance increases. Components of the same type are stored densely and iterated in order, so access is prefetch-friendly and each cache line gets used to its full width. Misses don’t disappear, the data still has to be pulled in from memory the first time you touch it, but you pay far fewer of them per object processed than you would chase pointers between Actors and Components.

Depending on the scale of the project it may be easier to write code for as well due to how the data is easier to organize in memory, rewrite, and modify. The main drawback is that the UX needs to be very specifically built with ECS in mind to give designers and artists the flexibility they need to achieve their goals.

• Some things are just really really hard to express in a way where you do everything once at a specific point in the frame… gameplay logic with lots of inter-dependant communication is somewhat difficult to do in a nice way without making some sacrifices (which might be a good thing).
• ECS stuff is often not really helpful for either perf or organization when you have a low count of something… It’s good to consider if it really matters at all to express something in a query if there are like 1 of them.
• Debugging an ECS issue is a bit more difficult than a simple uobject sometimes due to things being just integers… Mass is REALLY good in this area compared to most though (one could argue in some situations it’s more simple but I would say generally it’s painful to step through while debugging compared to a simple OOP code object).

-Megafunk

It organizes everything into three main separate camps:

• Entities: ID’s for a contextual object that will hold data. So it’s not a container but its like an Actor.
• Components: Data(and maybe some functionality for setting/reading that data for utility). It is intended to just hold variables and thats it.
• Systems: Functionality, this literally doesn’t hold data and just executes code.

Here is a simple example of an Apple falling from a tree using ECS:

• Entity: The apple instance as a whole.
• Components: The physics state of the apple, the rendered state of the apple, the gameplay state of the apple like nutrition or something.
• System: Handles updating the physics state of the apple falling from the tree, updating the rendered state of the apple, modifying gameplay state regarding the apple.

This is what Mass is but in Epic’s Unreal flavor since the engine currently is built around actors and is adding this ECS paradigm.

The future of Mass

At the time of writing Epic announced UE6 and that they were deprecating Actors and Components in favor of Scene Graph which is to be built off of Mass when looking at the source code. This is a MASSIVE paradigm shift and refactor of a core part of the engine, I recommend learning Mass on this basis alone to have a better understanding of how to write code in this paradigm if you’ve been working with Actors/Components for the past 10-20 years.

My personal opinion of this is positive. This is because I’ve seen the problems that Actors/Components can bring when trying to fix performance problems with them and very much welcome Scene Graph since it allows a better implementation of parenting objects to each other at both design time and runtime.