What types of ECS Examples would you like to see?

So I just finished going through all the ECS videos and I remember Mike Acton telling us to request example projects that would best explain the ECS system to us. It cant be too simple or too obtuse. More over its been a while since we've had an official unity demo.
So I am inviting you guys to post your suggestions.

I personally would like to see a demo that shows any of the following systems
Mecanim ECS interaction/communication
If you have multiple npc's they'd most likely be in different states. eg one could be interacting with an object while another idles. Would we just be changing gross state in the update while animation state machine does the main churn?

ECS menu system
Mike actually stated slow UI as a justification for ECS in the talk. I cannot envisage how this would even work (Architecture).

AI system.
This one might be complex but i think it would show off the system the most. AI has a lot of dependencies and does not update every frame. Lots of communication also. I suggest a state machine system but, an "if-else" ai would not be a good way to do this.
A simple state machine like the plug-able one used in the tanks tutorial from.

Ultimately we could re-purpose the old stealth demo or Angry bots

 

I'd like to see something along the lines of a behavior tree in ECS. Struggling to think of how you would go about that, but it is so much more useful for AI than a basic state machine.

 

You might have to copy the Service based implementation from UE4. It is probably the only way to maintain performance without redundant tree traversals. Especially since most of the examples did not have branching code.

Sensory updates can be threaded and fed to a blackboard, it will mean tedious code of writing to a blackboard after every ComponentSystem update if note and requests/deferred retrieval of data not currently present. Different ComponentSystems for each sensor as the logic is mostly consistent.
It would probably be the same for event communication between objects. populating lists of messages/commands after ComponentSystem updates and resolving them at the end of frame or beginning of the next.

Reading from blackboards or Animation Parameter might also happen frequently as we prepare our jobs based on the state. I doubt placing the whole blackboard would be good for cache.

The irregularity of AI update would mean we probably have to spread updates for each agent across many frames like the particle system example from gdc

Code (CSharp):

1. foreach agent in agentList
2. if timeSinceLastUpdate > n
3.    aiUpdateQueue.(agent)

For utility systems i am at a total loss. 1 system per consideration or per action?

 

Using a shader to animate the shark in the ECS Demo was a disappointing cheat

 

Hello ! I'd love to see some 2D in pure ECS. Should I use MeshInstanceRenderer or a system using DrawTexture onPostRender ?

I'm not sure how to work with Mecanim :
- use an Animator to copy Animator Controllers data into an ECS Animator at start
- use multiple Animators to modify and store controllers states in every entities

I read somewhere Animator was already working with a jobified pattern. Should I rebuild the wheel or go for hybrid ?

Based on the pure ECS exemple, I'm going with this for now :

Spoiler: SpriteInstanceRenderer.cs

Code (CSharp):

1. using System;
2. using Unity.Entities;
3. using UnityEngine;
4.  
5. namespace Playtest.Rendering
6. {
7.     [Serializable]
8.     public struct SpriteInstanceRenderer : ISharedComponentData
9.     {
10.         public Texture2D sprite;
11.         public Material material;
12.     }
13.  
14.     public class SpriteInstanceRendererComponent : SharedComponentDataWrapper<SpriteInstanceRenderer> { }
15. }

Spoiler: SpriteInstanceRendererSystem.cs

Code (CSharp):

1. using System.Collections.Generic;
2. using Unity.Entities;
3. using Unity.Mathematics;
4. using Unity.Transforms2D;
5. using UnityEngine;
6. using UnityEngine.Experimental.PlayerLoop;
7.  
8. namespace Playtest.Rendering
9. {
10.     [ExecuteInEditMode]
11.     public class SpriteInstanceRendererSystem : ComponentSystem
12.     {
13.         List<SpriteInstanceRenderer> m_CacheduniqueRendererTypes = new List<SpriteInstanceRenderer>(10);
14.         ComponentGroup m_InstanceRendererGroup;
15.  
16.         protected override void OnCreateManager(int capacity)
17.         {
18.             m_InstanceRendererGroup = GetComponentGroup(ComponentType.Create<SpriteInstanceRenderer>(), ComponentType.Create<Position2D>());
19.         }
20.  
21.         protected override void OnUpdate()
22.         {
23.             Camera.onPostRender = null;
24.  
25.             EntityManager.GetAllUniqueSharedComponentDatas(m_CacheduniqueRendererTypes);
26.  
27.             Camera.onPostRender += (Camera camera) =>
28.             {
29.                 GL.PushMatrix();
30.                 GL.LoadPixelMatrix(0, Screen.width, 0, Screen.height);
31.             };
32.  
33.             for (int i = 0; i != m_CacheduniqueRendererTypes.Count; i++)
34.             {
35.                 var renderer = m_CacheduniqueRendererTypes[i];
36.                 m_InstanceRendererGroup.SetFilter(renderer);
37.                 var positions = m_InstanceRendererGroup.GetComponentDataArray<Position2D>();
38.  
39.                 for (int j = 0; j != positions.Length; j++)
40.                 {
41.                     float2 position = positions[j].Value;
42.                     Camera.onPostRender += (Camera camera) =>
43.                     {
44.                         Graphics.DrawTexture(
45.                         new Rect(position.x,
46.                                 position.y + renderer.sprite.height,
47.                                 renderer.sprite.width,
48.                                 -renderer.sprite.height),
49.                         renderer.sprite,
50.                         renderer.material);
51.                     };
52.                 }
53.             }
54.  
55.             Camera.onPostRender += (Camera camera) =>
56.             {
57.                 GL.PopMatrix();
58.             };
59.  
60.             m_CacheduniqueRendererTypes.Clear();
61.         }
62.     }
63. }

I'll try this today :

Spoiler: InstanceAnimatorSystem.cs

Code (CSharp):

1. using System.Collections.Generic;
2. using Unity.Entities;
3. using UnityEngine;
4. using UnityEngine.Experimental.PlayerLoop;
5.  
6. namespace Playtest.Rendering
7. {
8.     [ExecuteInEditMode]
9.     public class InstanceAnimatorSystem : ComponentSystem
10.     {
11.         Animator animator = new Animator();
12.         List<InstanceAnimator> m_CacheduniqueAnimatorTypes = new List<InstanceAnimator>(10);
13.         ComponentGroup m_InstanceAnimatorGroup;
14.  
15.         protected override void OnCreateManager(int capacity)
16.         {
17.             m_InstanceAnimatorGroup = GetComponentGroup(ComponentType.Create<InstanceAnimator>(), ComponentType.Create<SpriteInstanceRenderer>());
18.  
19.             // 1) Copy every Animator Controllers data from m_InstanceAnimatorGroup into Entities using an Animator
20.         }
21.  
22.         protected override void OnUpdate()
23.         {
24.             // 2) Get the actual state from every Entities and set the SpriteInstanceRenderer Texture2D value
25.         }
26.     }
27. }

 

Please, guys, go very easy on us noobs. I have really tried 3 hours of understanding the ECS architecture. Even though I got the idea (at least that's what I want to think) when it comes to implementing it I crumble. I mean wtf is bootstrap scripts NewGame method! Who calls it? Is it magical? How the hell PlayerLook is assigned to that script?! (Don't answer those questions, what I am trying to say it is too complex for my delicate old brain).

So my ideas of examples:

From very empty project ->

1. A project where we create an entity cube. Turning an empty gameobject into Cube with ECS. Meshrenderer component?

2. A project where we create an entity cube. From thin air. No gameObject.

3. Now let's make the cube turns around itself. No input no nothing but ECS style.

4. Let's spawn 1000 of the above cubes in a line. Still turning. ECS style.

5. Delete those 1000 cubes, spawn those cubes in 5 different positions where we assign their positions by using the editor (for example with empty gameobjects) so I will learn how to tie inspector to ECS.

6. Let's create a Sphere. From thin air. No gameObject. ECS style.

7. Let's get the user input and make the ball roll (with transform first - I mean teleport it around)

8. Let's make the ball roll with Physix (Now we learn to connect our Rigidbody to ECS?! is this a thing?)

9. Let's turn this into a roll a ball tutorial at the end.

So now I know 2 systems of movement (transportation,physix), 2 systems of spawning (w/ GO and without GO), assigning values from GOs to entities (spawn places), 1 system of user input, 1 system of constant movement (rolling of cubes) and I guess some more.

Edit: After like 4 hours, I could move a cube and turn it with Hybrid ECS (where cube is still a GO). Then I tried to delve back in to pure ECS samples (Get cocky I guess). Simple rotation killed me. I understand I need to add Transform matrix or it won't instantiate anything. Then I spawned some balls into the middle with the Unity spawn script (mind you I failed lots as I think pure entity has its own laws, some components are must have). I tried to move stuff with my old script. But mo... Now they are an entity so they refused to move. I really suspect it is something about TransformMatrix component... Though why is it that way? I think there are lots of missing but basic stuff that is not yet in documents. (Again I am not writing these for immediate answers but as a struggling coder's journey so to show required tutorial level)

 

SUGGESTION:

Particles as ECS Example

From what I know, in my simple mind, particle systems are the best for showing an ECS in action.

The Systems influence particle behaviour, randomisation, customisation, and events activating further Systems to perform more logic/processing upon the properties within the components of the particles.

The Components make up various properties of ever more complex particles.

The Entities are the unique IDs of each particle.

 

In one of the unite talks there was a particle system. It's the one before Mick Acton's
Components are the Data
Systems are the logic/behaviour



Particles as ECS

 

Suggestion:
Raycasting an Entity

I've got the raycast command working and its raycasting normal monobehaviours with colliders but can't implement a way to detect the raycast on an entity

 

can we download this as an example?

 

No. Most of the code is up there you can recreate it. /good learning experience. I might give it a go

Seems a bit too simplistic considering he explains how batched raycasts work in the GDC talks.
I'll search for it

 

1) How to work with big data sets. e.g. Minecraft-like world. Is every block an entity? How many entities are too many? Or should all blocks be in an array on one entity or on chunk entities?

2) General best practices guide would be nice.

3) A tutorial series would be great.

 

You'd want to make chunks into entities and have a ChunkSystem that "renders" the whole thing with data from Chunk datacomponent or something. I've tested 100,000 entities (cubes) with instanced material and I got around 30fps avg on my old Radeon 7670m (frame rates dropped as more cubes entered the view) you can get the project here

 

I am talking about Entities created via EntityManager.CreateEntity()

 

Once you've given it a go you'll have almost half the knowledge required to speculate on its value as a learning experience

 

We do a lot of real world data simulation & visualisation with Unity rather than write games. So we read in sometimes very large data sets and need to move, rotate items according to 'scalable real' time. So i would much welcome examples of 'lerping' moves and rotating over several frames. Also event driven job scheduling.

 

Right now I'm trying to convert https://assetstore.unity.com/packages/essentials/tutorial-projects/2d-roguelike-29825

Using ECS (not using the job system) and Tilemap.
It's not easy when new to ECS...

Would love to see someone do that.

I think it's a good exercise, and I choose this one also because it has been done with Entitas (https://github.com/JamesMcMahon/entitas-2d-roguelike) which can give some pointers.

But Entitas has ReactiveSystem, and that's where I'm blocking right now, it's really hard to work with just an Update cycle.

 

@Ziboo My friends over at Brazil are starting a little roguelike project. I'm suggesting them to use ECS and Unity's tile map, they are currently only starting to learn both. So would be great if there would be an example like this, I would send it to them. Maybe I can help you out at least with ideas if I won't be able to dedicate much time. Maybe I can help you figure out how to get around not having the reactive systems (should be easy). I would definitely learn a thing or two in the process.

 

@illinar Hey thanks for the offer. I'm just playing with it. Not sure I will continue or not, I'm not sure the ECS is mature enough to handle something like that, maybe wait a little bit, I'll see.
But honestly, just trying, without Events on entities or component changed, it's kind of a nightmare, you pretty much have to do a system for every little things... which is very time consuming

 

a couple of stuff I'd want to see (both related to what I'm working now):

- a classic turn-based board/card game (like poker/spades/bridge...), for which the state is naturally centralized
- montecarlo simulation (specifically, how can I stop the simulation from outside the job / after a certain time)

right now our AI spawns a managed thread, if I can get at least the safety of the job system it would be great

 

That is way beyond the scope sorry. It should be about managing your game objects and how to communicate between them

 

How so?

 

Like how you map common patterns to ECS. Like showing how to make a behavior tree or state machine.

Or pretty much anything that isn't simply an ideal example. Ie NOT let's do one thing 10k times.

I'll give an example of something that is currently painful with ECS.

My ai's have steering logic that does a number of checks in a circular pattern around the ai. Not just simple LOS but also for each angle checks distance to nearest enemies along the line, etc.. It scores each angle against the last and at the end returns the best.

The solution to that kind of thing is you have to break up the logic into multiple steps. IMO we actually need some good canned abstractions for that because it's going to be very common. And most people are going to struggle and create a mess of it.

It's not sexy, it doesn't show off how fast ECS is. But it's ultimately much more useful then showing how to make something dead simple run fast.

 

I'll make my requests more abstract, then:

1. stuff with many "singleton" specialized entities, each one doing a different thing. like for a UI (you once said UI is one of the best scenario for ECS), each button probably wants to do a different things, and it exists once in the scene.
   • i.e. you have a 'Button<X>Component'/'Button<X>System' for each different button in your scene (goodbye data locality)? dump a "mega-switch" in your system that does everything (goodbye code locality)? or is there a proper pattern for that...
2. how to pack jobs when you want to control iterations based on something external? i.e. instead of "do this 1000 times" you have "do this repeatedly for the next 3 seconds", or "do this until condition X"
   • you can do a fixed number of iterations per-frame, then check in the main thread, but it will have holes (if the device is too fast) or block the main thread (if it's too slow) (or lose a frame if you check isCompleted and the job is at 999/1000)
   • will I need to write need a custom "NativeSemaphore" that can be set on the main thread after schedule and read in the jobs? or you will provide something similar for this use case? or there is something else?

 

I would also personally like to see a statemachine example with the ECS.

 

How about an A* pathfinding example on a large 3D grid?

 

OK. Until ECS is clearly documented top to bottom. and until its done with a very clear setup(like what we normally use)...I'm just going to ignore it for now.

Maybe come back to it after a couple of years when its matured.


What wrecks me, is the Bracky tutorial I watched.

Has Rotator script on each cube. ok well enough.
Normally in each of the rotators, we tell it to rotate on update.
that will rotate each one with that script right?

ECS got a script on EACH GAMEOBJECT.
That script gets all entities and rotates them on update.
And it won't work if you just put the script on 1 or even just a game manager.
Each GO/Entity, has to have the script that finds all entities and rotates each of them in a Foreach loop.

Wait wat? How tf is that any better performance or even code wise? Redundant af for one thing.

like 4x the code and work that we would normally do. And thats just with a simple rotation example.

I can only imagine the coding hell for enemies that spawn and receive damage from player or even multiple players.

Also...does it work with object pooling...or is that just out the window?

 

1. I think you misunderstood ECS somewhere along the way. You don't need a script on each Entity. Entity by itself is just a simple struct, nothing to "attach" a script to.
2. ECS is not meant to make coding simpler. Its going to be longer (in my case 2-3 times the normal lines of code vs MonoBehaviours). But with that extra effort comes great performance benefits.
3. With pure ECS you don't need object pooling. Spawing 10,000 agents in my navmesh demo takes less than 0.1 seconds. 100,000 takes a bit over a second.

 

You should probably take the time to revisit all the information that's been released on ECS so far, and perhaps even study some of the concepts behind the pattern (outside the scope of Unity). It's clear you don't fully grasp how it is structured or designed to work. The tradeoffs favor performance and code modularity.

Firstly, you are not required to write ECS. In fact, I reckon most people will end up just downloading "ECS" assets from the asset store that abstracts complex/expensive systems away from hobbyists/indies. Also, how it works is exactly the opposite of what you mentioned. Having a script on each GameObject is how Unity CURRENTLY works with monobehaviors(there are workarounds but it is not pretty). ECS goes in the opposite direction. It is mainly about structuring your data in CPU-cache friendly manner, and operating on that data in a functional style (with dependency injection sugar to help write it imperatively). The mental model for an ECS based system is not far from functional reactive programming. I think that even mentioning object pooling is a sign that you need to dig a bit deeper. Similar to other functional approaches, all ComponentData are structs, which means everything is copy by value and mostly wont escape onto the heap. For long lived items we have Native Collections. I think this is a great move for Unity, and it deserves a bit more of your time to study and understand. Cheers!

 

I would like to see networking with one world for client and another world for server.

 

I know we don't HAVE to use it, i never said anything about that.

Thats how I thought it would work. Yet every example I see, Brackey's included, puts the ECS code on each of the GO just like mono.

Every way I can find and think of to just use a manager script to control all entities...still looks like mono with extra steps.


So I will wait until there is more documentation out on how to use it before I try it anymore.

 

It gets funner:

I've seen a Unity presentation bragging about the performance improvements on a scale of 10x or more, but their standard Unity implementation didn't use any caching of transforms.

 

I want to see fixed updated system of transforms interact with updated ones.

 

I think the slogan they are going for moving forward is "Performance by Default" using the new entity system. Like I briefly touched upon, you can still "optimize" certain things with the current Unity. For example, you can add a bunch of game objects and manually reference their components and omit the monobehaviour Update() function (which is reflected and gets expensive to call on large scale). Things like this will give you some performance but is very unwieldy. In fact, we do just that with our game. We have one single MonoBehaviour with it's Update() as a master game loop and call our own references to other systems/objects inside of that update.

Likewise, you can do a bunch of little things to cache transforms, object pooling, etc... the list goes on. Those are not, by default, easy to reason about and take advantage of. By changing the way we write, we get most of those things for free. Again, it's a trade off and maybe not for everyone.

 

A* pathfinding algorithm implementation in pure ECS. Would be a nice learning experience.

 

I would like to see examples of Using NavMeshAgent with ECS (hybrid)

It would be nice to see how things like inventory should be implemented a specially in situations where there would be more than one. It is impossible to group by component value so I would have to iterate over all elements. If there is a small number of them I could just create some tag components, but what if I would like to create an RPG and the enemies would have some loot after killing an enemy I would like to see what he has. So I would have to loop over all components with the defined set of components and ownership component that stores an entity of defeated enemy?

 

The navmesh demo i did can be used for hybrid

https://forum.unity.com/threads/100-000-entities-traversing-navmesh.534526/

 

3D grid as in spaceships flying through space?

 

I probably meant 2D... And in the recent version of examples, they have implemented some spacialized data querying in that dungeon generation example, which really was mostly the point of my suggestions.

 

Yes, I get all that. But the real world realities of Unity paced rollouts means that teaching the ways to reference and speed up things NOW is going to be needed for (perhaps) years to come, whilst they rebuild around ECS etc.

In the meantime, the most basic of "optimisations", caching the transforms in a demo that moves transforms, isn't done, and the claim is "ECS FTW!", despite needing intricate knowledge to do simple things.

The difference, in usability, right now, is sort of like doing Hello World with classes in C++ and building your own OpenGL text renderer, versus using one line of BASIC.

10 Print "Hello World"

 

Astar is good for certain things but 2D pathfinding in large open spaces that doesn't change much are better implemented via navmesh.

A good candidate for astar is for vehicle pathfinding on dynamic road tiles that can be added and removed. Kind of like transport tycoon. I'll be implementing that particular usecase in ECS soonish and will share the code.

 

I think a good example would be something where you have simulation and presentation worlds, and have the simulation world running while the presentation world is rendering.

 

I didn't see the demo in question. But If the point is to show A, then doing have a dozen other things just gets in the way of understanding A.

Demo's showing the migration path should not be going to lengths showing how to optimize other stuff. The whole point of GameObjectEntity is to allow you to migrate over to a proper ECS system where the optimization approaches can be very different.

Bottom line is if you are making games competitively, or you work as a Unity developer, you better learn this stuff. Or get left behind. Your choice. Hobbyists fine, take your time.

 

What are you talking about?

The speech had nothing to do with teaching how to use ECS, it was selling Unity, on the promise and potential of ECS, and claiming its future performance to be astonishingly better than using Unity of now.

Here, judge for yourself:

 

@Deeeds

What is your point though?

Are you saying Unities ECS examples are bad, their documentation is bad, etc? Everyone will agree that it is immature and has lots of room for improvement. They choose to make it available early and pointed out that this is for the more involved to mess around with as they go along. If you want to use it for production - don't. If you want start getting used to it....your choice.

If your point is to say data driven design (ECS aim), parallel processing(Jobs), advanced compilation (burst) is not bringing the promised speed gains, I don't understand what you are trying to say. If it is about 7x, 10x, 20x...well, it depends on the actual situation...

In the end, as always it boils down to what get's the job done in a satisfactory way and ECS is likely not the "best" solution to everything.

 

An ECS should be good.

DOD should be great.

There's no need to hobble the current horse to paint this picture in a faux competition.

To pick a type of test (for a demo) that deliberately picks on a weakness of the "old" Unity, while picking something ECS & DOD are uniquely well equipped to handle, by its nature, is deceptive. It looks a lot like they went looking for the worst for the old, best for new scenario.

But why? Why do we need to be sold on this? There's no extra cost to users, and it's not ready.

To then make things worse, by using the worst way to use the old way, that's deliberate disingenuousness, and handicapping.

That's two of the points.

Another is the irony of claiming "performance by default" and not demonstrating the gains available (in the old way) by making a couple of very easy changes. It was an ideal opportunity to pinpoint, present and teach easy performance gains, for the now, to users who'll be suffering until ECS is ready and cleansed of bugs, documented and easy to use.

Which is an unknown time frame.

 

Hi there, I am not planning to argue on this. It is likely a fair point that their mono example was not speed optimized and I am not sure if the point of the example was purely about speed or showing a common way of doing things in the different mono / hybrid / pure way. Likely they got carried away a bit in their excitement?

The test project i used to look into the new ecs/job/burst things was a pixel collision and the speed gains were massive and I would say my ecs version still has room for improvement as I am new to it and know Of some optimization items already. The main gains here are not from ecs though, but parallel processing and burst (editor only so far)

The best is in my view to have a concrete problem that is cpu heavy and then see how to optimize it with the current tools (there are many good articles on the subject in the mono world, also from unity) and with the new tools.

Only trust your own benchmarks.

 

I think the key takeaway with ECS is the direction Unity as an engine is heading towards in the future. You're right, they can continue to optimize the current Unity with magical, under the hood stuff (I think I read/heard somewhere that something similar to jobs has been working for internal systems for a while). But as with all abstractions, inevitably, it covers too broad of a spectrum and becomes too generic or unoptimized for more specific uses cases. I personally like that they are taking the "open up more of the lower level stuff" approach, as it makes Unity a viable engine for more high performance requiring games. The flip side would be continually upgrading the current components, but my guess is that stuff (such as the colliders) are pretty much as optimized as they can be at this point, and games will benefit more from being able to reach into other cores/thread for parallel processing.

You can still use the Job system with the monobehaviour style code by the way, but you wont get all the benefits of cache lines and Burst's SIMD optimizations, which, in theory, is a great match for each other. I really don't think Unity was deliberately being disingenuous with the comparisons. What exactly do they have to gain by doing so? It's not like they are comparing synthetic benchmarks to a competitors engine. If you are saying they are just trying to validate their jobs or toot their own horns, I think that might be a bit presumptuous. I have a feeling you just think their resources are better spent elsewhere, but it is my opinion that the unity team is better equipped to make that decision.

 

Pixel collisions is an excellent idea for usage of this. Bravo! Fun, too!!!

Do you have any bookmarked links to any good articles on optimising the current Unity ways?

 

You would be more happy if Unity go back their lair and they develop this whole new systems in silence and one day they just come out and ship the entire new system?
What would you gain from that behavior?

I can tell you: nothing.

What can you gain from the current behavior?

A lot:
- you can learn as you (and they) go
- you can actually influence their decisions
- you can ask for things to develop/support, or you can have information, why they decide to certain way
- you can ask for clarification on things like the rest of us do on these forums
- you can see what will come in the (near?) future

I think it is not fair to ask them to be silent about their work and it is very counterproductive .

Also, if you can't see the difference between these new systems and the Monobehaviour-way, just try to build the Nordeous demo on the Monobehaviour/gameobject way. Let's see how you move around 60.000 minions, animate them and make them attack each other. It does not have to be graphically cool or advanced, just build it. You can use any optimizations you want as long as it uses gameobjects, monobehaviour(s) and don't use ECS, Jobs or Burst at all.