I’m making a game that would benefit greatly from using ECS; GOAP AI, large number of complex and unique NPCs, and whatever else I have too ambitious an idea about. I’m still learning ECS, and trying to figure out how to make game mechanics I’ve previously made work inside of ECS (pure ECS or otherwise), I’m having a hard time figuring out how to proceed.
Is it better for a newcomer to start with ECS or with Object-Oriented Programming, under the assumption they would transition later if choosing the latter?
How difficult have you found translating game mechanics from OOP to ECS? Did they take you a long time, and how often did you find yourself getting stuck?
Transitioning is really hard right now. I would not recommend it. The main reason is that having half your logic in ECS and half in GameObjects gets really messy. That may change in the future.
Really, I would recommend starting out building very small games in ECS (think game jams) and work your way up bigger and bigger until you think you are ready to build your ambitious idea.
The way you use ECS currently requires you to know about the GameObject (aka OO) side of Unity - because they are used as authoring tools and as proxies when features are missing (animation, effects, audio, …). Plus ECS is conceptually simpler but has a steeper learning curve because of the special C# syntax, undercooked manuals, missing community (tutorials, …), …
I’d start by making a small game in good old MonoBehaviour land. Then take small steps into ECS.
If you want to use ECS, you have to start building with it because it just doesn’t jive with OOP and reference types. It’s way harder to port an OOP heavy code than to start using HPC# right away.
If you are new to these. Ignore ECS for now.
But write code in such way, that it is compatible with jobs and burst. Or at least most critical to performance systems.
You can store data in native collections, so you don’t even need ECS.
ECS is good, but it has steap learning curve, and will require at least year of expertise in burst, job an ECS alongside the C#, to be somehow proffoecent.
So to sum up the general consensus that I see for the questions I asked is:
Don’t try translating mechanics later, it’s not worth the effort, start from the beginning with it
No known examples of people trying to port mechanics from one to the other
I would ask about ways or thought patterns for making mechanics previously seen in OOP in ECS environments, but it sounds like that would circle back to the same answers. I think I would benefit greatly from seeing more examples of what people have done in ECS, but unfortunately with it being so new I can’t seem to find many examples/tutorials about the specific concepts I’d like to inquire about.
There’s some materials addressing converting from OOP to ECS, but I also feel like they should be used strictly for education rather than promoting a suggested workflow. ECS code is simply very different than what people are used to doing in GameObject land. In practice, converting really means a rewrite. (At least a partial one.)
Note that the code in the video is outdated, but thankfully they updated it on GitHub:
Very good way to get started. ECS really consists of lots of tools and concepts (SystemAPI, queries, buffers, various job types, lookups, command buffers…) that you need to actually play around with to understand how they work, interact with each other and what problems they solve.
In my experience, as it is often in programming, things get a lot less overwhelming once you actually start trying to get stuff done, rather than just trying to piece everything together in your head based on the docs and tutorials.
I have converted multiple systems from OOP to DOTS and with ECS. Some like IK, animation, utility AI, neural net, hex planets generator, to name few.
Also I write prototypes in OOP, before writing in DOTS, after validating the concept.
Thing is, most of code is not shared, which doesn’t bring much here to the table in terms of learning subjects.
But one thing I can say, performant conversions always take much more time. Code need to be well thought, to gain performance benefits of DOTS. ECS is not always best fit. And should be balanced, when and if to use it. Sometimes maybe just partially.
However, there is Unity DOTS repo on github, specifically aimed for training.
