ECS Unity Evolution


Have y’all checked out what is going on with Unity?

They are moving to a “pure” ECS system, making parallel processing and cache locality a lot easier.

Here is a video giving an overview:
Here is a page that has a lot more detail and other vids:



Heh, that sounds pretty cool. I haven’t used unity in a few years but I’ll definitely check that out. Thanks for the link!


Watched the vid, that’s actually pretty slick. I used to say that I liked their component architecture but that I’d wished they’d taken it further than they did. Looks like they’re actually doing a full separation of attributes and components which I definitely like. I know you could do it under the old system but it was always a pain to do (too many classes, too many attached components etc). I always thought it was funny how ECS taken to it’s extreme just gives you functional programming with all the overhead of OOP, but for game code it’s great.


I would not really say that this is functional programming(in the more modern sense; minimization of mutable state), more like data driven programming.


I wish that skookum was available to more engines so that we could play with the various engines in skookum mode. There seems to be a “sage” advice, particularly in the unity community, that one should never or hardly ever use coroutines, it is sad. When you consider a talk like this one: it should be clear(in a muddy sense =)) that coroutines are an amazing abstraction that should be taken full advantage of.


SkookumScript could be added into other engines and that is the eventual goal. There has been interest in integrating SkookumScript into Unity3D, Amazon Lumberyard, EA’s Frostbite, Ogre3D and others. Bandwith is the main reason we’ve stuck with UE4 so far – and UE4’s AAA pedigree and all-around awesomeness.

Coroutines in SkookumScript are different than coroutines in most other languages which need to use additional syntax such as yeild. We just used the name “coroutine” since it was the closest pre-existing computer science term to what Sk uses. We have often wondered if we should use a different term so that the downsides of traditional coroutines are not lumped in with Sk coroutines.

Sk coroutines are also similar to the async \ await mechanism used in some languages - every Sk coroutine definition starting with an underscore _ essentially has an implicit async and each Sk coroutine call essentially has an implicit await.

One of the key differences with the SkookumScript concurrency mechanism is that there are additional concurrent flow expressions such as sync, race and branch and other concurrent methods in List and other classes. SkookumScript also manages concurrency with Mind objects and internally has a concurrent call graph rather than a simplistic call stack as with most other languages.


This is an interesting post about how much performance Unity is achieving with their new tech: