Unity3d ECS: Look Back

Over the last month, I have been learn and testing Unity’s new ECS programming structure. I have been working with both pure and hybrid version of the system. Based on my experience, with pure and hybrid ECS, Unity has stepped their game up and Unreal should be feeling real pressure from the company. However, I have to ask to who is ECS intended for?

Due to Unity’s start up and true Indie friendly term of use, Unity3d has been the goto game engine for many first timers, hobby/enthusiasts,and 2nd job game developers. The tools and features found in the 2018.1 release have made it easier to make great looking games in Unit3d. But for most of us, I believe, it is too early in your project to implementing an ECS based coding structure. In fact, I believe that using the ECS coding style from day one of development can lead to the fail of project. Two of the greatest things about Unity’s OOP monobehaviour GameObject approach, is the ability to rapid prototype and deploy code and the isolation of codes. When developing the AI code for and enemy npc, a programmer is initially more with the proper function of code and not how well it function. Over the course of a project, I have found that I can rewrite the same section of code 5 or 6 times. Each time I write a section of code, it is slightly better than the last.

Please understand that I am not saying ECS is not a much needed additional to the Unity platform. I will definitely will be using Unity ECS in Project Rebirth. As I see it, for small team and solo Indies, Unity ECS is intended as am optimization step. Developers should continue make games the way they were prior to the introduction of ECS. Once you are ready to refactor and optimize your code, that is when you want to implement the ECS coding style. There is little to no point in writing high level optimized code that does not make it into your finished project.