Note that this question has nothing to do with performance and multi-threading! Note that this question has nothing to do with performance and multi-threading! Note that this question has nothing to do with performance and multi-threading! I would like to ask you for your thoughts on game architecture. The conclusions of searching this kind of problem on Google are all vague, saying that this kind of separation is more modular, decoupled, maintainable, etc. But there is no comparison between ECS design and classic unity design examples. It's all a description of what others say, without any actual examples. In classic Unity, for example, if I create an enemy movement MonoBehaviour component, I can mount it to all enemies, and if I want to change it, I only need to change it once. In ECS, an enemy movement system is established to manipulate all enemies, and if you want to change it, you only need to change it once. Both of these need to be changed once. I don’t understand why ECS is more modular than classic Unity in terms of architectural thinking. Can you give me a practical example? In the past few days, I have carefully read the blog of the ECS paradigm definer: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog- development-part-1/ he said the entity system meant I could implement the complex latency hiding and prediction techniques with minimal interference with the coding of all the rest of the game systems. When you've got 20+ programmers on a team, You really don't want to be placing yourself in a position where you're going to have to redesign code for all of them just to make it “network friendly”. But with classic Unity, similar functions can also be achieved. For example, you only need to attach a "NetworkTransform" to the gameobject, and then the network code does not need to interfere with the main game logic. Classic Unity also uses the component pattern to reduce cross-cutting concerns. So in ECS, separate behavior from components. How is it better than classic Unity? What is the philosophy behind it? what is the reason?Are there any real examples to illustrate? In other words, how is ECS's method of traversing "entities" relying on "systems" better than traditional OOP? OOP divides the game into individual game objects, and then lets them communicate with each other. Is this method really not suitable for game programming?