If you’ve been keeping up with Unity’s feature roadmap or the beta program, then you
already know that there are a ton of exciting features planned for Unity in 2018.
But the one feature that I'm personally really excited for is the new implementation of ECS.
If aren't sure what that is, or you'd like to learn more about it, then this is the video for you.
Let’s start things off with a formal definition.
ECS stands for “Entity-Component-System”.
Entity-Component-System is a design pattern consisting of, you guessed it, entities, components, and systems
An entity is a collection of components.
Entities are usually implemented as barebones objects
consisting of nothing more than a unique ID.
A component is a data container.
Components contain one or more value fields that relate to one aspect of an entity.
A system operates on a collection of entities that are made up of a specific subset of components.
They define your game’s behavior, and are the only objects the actually contain logic.
Let’s take a look at a high level example.
Here’s a diagram containing the components for an entity that I’ve decided to call
“Player”.
But it isn’t this entity’s name that makes it function as the player’s avatar.
Rather, it’s the player entity's components, and the systems that act on those components,
that give it that functionality.
For instance, player has a view component.
Well, if we added a render system to our game, whose job it was to draw any entities that
contained a view component, then we’d be able to see our player and other entities
on the screen.
And if we added another system, called input system, that acted on entities with a physics
and input component, then we could actually begin to control the player entity.
T hat’s basically how Entity-Component-Systems work.
Your logic lives in systems that define behaviour for entities that contain only the components
that those systems care about.
This is just as true for a system that operates on a single entity as it is for one that iterates
over hundreds of entities.
It’s definitely an interesting approach to architecting your game code.
And so far, game code is actually all we’ve really focused on.
But one of the coolest things about Unity ECS is that systems are eventually going to be
used for every aspect of Unity’s life cycle.
Game code, editor code, asset pipeline code, and engine code will alI utilize ECS.
And that’s insane because it means that one day we’ll have control over almost every aspect
of Unity.
Don’t like the rendering engine?
Replace Unity’s rendering system with your own!
Want to implement your own custom physics simulations?
Add your own physics system on top of Unity’s.
Need to support plugins for your game?
Hook into Unity’s asset pipeline system, and give it that functionality.
Now that would be a pretty big change for Unity.
Which leads us to an important question that you may already be asking yourself.
How performant is Unity ECS?
Well, believe it or not, performance is actually one of the the biggest driving forces behind
all of these changes.
So much so that the creators have gone as far as to promise performance by default.
But what does that actually mean?
The idea is to make it incredibly simple to write efficient machine code for all platforms.
Unity ECS makes this possible through a few key features.
The first is an optimized data layout.
When you write your code using pure Unity ECS, your component data is guaranteed to
be stored in memory linearly.
This means that your systems will access entity components in the most optimal way possible.
Data access just doesn’t get much faster than that.
The second is multithreaded code.
Systems in pure Unity ECS are implemented as jobs, and are ran by Unity’s new C# job
system.
If you aren’t familiar with the C# job system, let’s just say that it allows you to write
multithreaded code in a safe and simple way.
With very little effort, all of your systems will run in parallel and utilize all of the
cores in your processor.
The third and final feature is Unity’s new Burst compiler.
The Burst compiler was designed to compile C# job code in the most optimized way possible.
It’s so powerful that some demo ECS code compiled using Burst has almost reached the
theoretical limit of performance, instantiating 100,000 entities in only 10 milliseconds.
If that wasn’t impressive enough, check out this demo created for Unite Austin 2017,
that showcases just how powerful Unity ECS can be.
You’re looking at a massive battle simulation consisting of 100,000 individual units.
It’s running in realtime at 60 frames per second.
I mean just look at that.
Really impressive stuff.
Be sure to check the description of this video for a link to this project’s GitHub repository.
Unity ECS is currently still in beta, and won’t be production ready for some time.
But that doesn’t mean you can’t get a head start.
As of the filming of this video, Unity’s C# Job System is available in the latest beta
build of the Unity editor.
And Unity ECS is available to those who have signed up for the technical preview.
I’ll personally be covering the development of both of these awesome features, so make
sure you subscribe with notifications on to get the latest in depth news and tutorials.
If you enjoyed this video, please a like and comment letting me know what you thought.
And to chat more about Unity, come hang out with our growing community of Unity game devs
on the Infallible Code public Discord server.
I'll see ya there, and I'll see you in the next video.
Thank you to all of my patrons. And a huge shoutout to Richard Stanz,
rStar, and Yakov.