Question How can I maintain a professional codebase and system design while programming with ECS?

I am new to ECS and currently looking to use it for a lightweight RPG project with some relatively complex logic, such as battles and character skills. While I am not familiar with ECS, I understand that early-stage system design is crucial. Transitioning from an object-oriented design approach to ECS feels somewhat unfamiliar, as my background has primarily been object-oriented. I have a basic grasp of the concepts, but struggle with the finer details.
For instance, in a RPG featuring AI enemies, I am unsure about how many systems to design and how these systems should interact. I am seeking a clear guide on how to decompose these elements.

As another example, in UI logic, I used the Observer pattern to listen for data changes and update the UI in the object-oriented process. I'm uncertain if this approach applies to ECS and how to design it (e.g., displaying global variables like game progress on the UI).

Additionally, concerning specific details or tricks, such as the [RequireMatchingQueriesForUpdate] attribute that enhances program efficiency, I'm interested in learning how to master such details and tricks to elevate my programming skills to a standard engineering level. While I've attempted a linear reading of the API interface, the vast amount of content hasn't yielded noticeable results. Could you suggest a more effective learning path for addressing these uncertainties?

 

So first off, there's no general solution to your questions, and everyone is going to do it a bit differently.

With ECS, your first goal should be to solve each problem as specifically as possible, and only generalize once patterns emerge. This means that refactoring is part of the iteration process and not something you do when "you screwed up". As a consequence, you'll find over time that refactoring in ECS is a lot less painful than with OOP.

Before tackling a complex problem, you should start with simple games first. Game jams are great for this. You need to find out what is intuitive to your brain and build up some patterns you can rely on as starting points. For example, if I have a defined object, I like to make two components that describe that object called Stats and State. So GunStats and GunState or PlayerCharacterControllerStats and PlayerCharacterControllerState. Stats aren't meant to change at runtime, whereas state gets updated every frame. Only one system is allowed to write to state for a given archetype, but any system can read any of the components. I've found this pattern to be especially accessible to beginners as it is a very easy pattern to imitate. As the project evolves, I'll often break these apart further, splitting out an Outputs component and eventually breaking things apart into granular pieces.

The fastest way to learn is to just prototype with small-scope projects and work your way up to progressively more ambitious goals. Also, try to work with someone who has more experience so that you can ask lots of questions and discover the tricks they've already figured out.