It’s a complete Unity project. Just use the Unity Hub to open it up.
Note that certain temp folders need to be rebuilt when you first open the project. Just be patient the first time. It should launch much more quickly once Unity recreates those files.
It shouldn’t be, but there were a few things we did in this tutorial that weren’t optimized. Some of it where we bridged between the “classic” and ECS world.
Note that we didn’t use Jobs in this tutorial which is probably where you will see quite a boost versus just the ECS implementation. If switch out some of the components for the multi-threaded equivalents you should get quite a bit of extra FPS.
We didn’t introduce Jobs in this article to limit the scope, which was already quite large. But together, ECS-Jobs-Burst, should be way, way faster than classic.
It’s not an exact science but I measured performance by the amount of time while holding w and not shooting to get down to 60FPS.
On the non-ecs scene, it took about 80 seconds to get down to 60FPS
On the ECS scene, it took about 45 seconds to get down to 60FPS.
In other words, ECS cut efficiency in half.
As you mentioned, this code doesn’t use the burst compiler or the jobs system and of course the collision system is…simplistic.
It may also have something to do with Hybrid ECS - perhaps with Pure ECS (I did not test this), it would be faster. Perhaps converting a gameobject to a entity has some performance cost.
Nevertheless, it is interesting and I think important to note that using ECS w/o the Jobs or Burst system can have a negative impact on your game. I am currently wondering whether ECS should be used for things like projectiles, or item drops, etc. but not complex gameobjects like an RPG character unless you for some reason are creating a game with thousands of complex gameobjects.
What Unity version (and DOTS packages) are you guys using BTW? ECS shouldn’t be slower, but there is a lot of “classic” stuff in here that may be really inefficient when working with the ECS part of the demo.
It’s been about a year since I’ve looked at this but if I recall, the Shuriken particle systems did cause some slowdown. If you comment that out of the ECS project, it can run for quite a bit longer before it slows down. I only kept it in so the enemies didn’t just disappear with a whimper.
Also some other things, I think PostUpdateCommands.DestroyEntity is probably an older convention.
But most significant: the Bullet and EnemyDrone prefabs use ConvertToEntity scripts to convert from classic GameObject prefabs to ECS Entities. The newer, more acceptable way to handle conversion is to use the SubScene workflow.
I really haven’t had to time to look at this in a while but maybe when things slow down…
I used the same Unity version that the starting project was made in.
I heard someone say that entities may have some performance cost in the editor but not in the actual build. Not sure if that’s true. Didn’t the non-ecs and ecs scenes both use the shuriken particle system?
Not familiar with SubScenes yet - was going to dive into those next. Gotta rest my brain for a bit though.
Yes, ECS running in the Editor is slower than the build from my understanding.
The Non-ECS and ECS are NOT perfect side-by-side comparisons unfortunately. In the ECS version, we’re invoking the FXManager.Instance.CreationExplosion method from the DestructionSystem. Not sure if there is a performance penalty to spawning the “classic” ParticleSystem from the ECS System. Commenting those out for both ECS and non-ECS examples keeps both running above 280-300 fps on my laptop.
The ECS doesn’t beat the non-ECS by very much at all, but if you add Jobs and Burst, it should be much faster.
I was really enjoying this tutorial. But for me on 2020.2.0f1 the bullets would not render if they were converted over to entities. Any ideas what might be causing that? I tried a number of different things but could not get them to render. This is my first dive though into ECS.
Unfortunately I haven’t had much time to look at DOTS or refresh the tutorial and not sure if I will be able to for a while.
You can check out my YouTube channel for slightly more up-to-date videos but even those are a little behind at this point. Hopefully DOTS will settle down a little more this year.
.WithAll<MoveForward>() can be removed because you are already asking an entity that has a MoveForward component as it is already present in the parameters of the ForEach method. In fact, putting a component parameter inside the ForEach method works as filter.
Also, we find the same pattern below in the tutorial when you introduce the FacePlayerSystem (which is a good example to introduce Tags,WithAll,… notions btw)
After learning some UniTask async, I’m interested in Unity DOTS. Thanks for the tutorial!
However, seems like DOTS is really for advanced user in C#. The convert thing and a disappearing gameobject make me confused (too lazy to think abstract). Well, I will try to practice for the tutorial.
Another else is, how DOTS can support addressable? Where it needs to convert as entities and instantiate manually from asset reference, does it works?
DOTS and Addressables currently are not compatible. Sorry, in fact, a lot of stuff is not compatible with DOTS yet.
It’s probably a bit off from being production read (not this year, going to guess the next product life cycle). However, this is quite a different way of working, so it doesn’t hurt to get ready.
You certainly don’t NEED to learn ECS at this point. It’s not necessarily difficult – in fact, a lot of your methods become shorter when you switch to the workflow. But yes, it is a very different way of working. It’s usually for people who have very specific memory requirements (i.e. developing for consoles, where every iota of performance and very quick start up time is needed).