update
This commit is contained in:
parent
fd2cfaba66
commit
c620e6b14a
18 changed files with 543 additions and 4 deletions
|
|
@ -0,0 +1,69 @@
|
|||
# GitHub - SanderMertens/ecs-faq: Frequently asked questions about Entity Component Systems
|
||||
|
||||

|
||||
|
||||
## Metadata
|
||||
- Author: [[https://github.com/SanderMertens/]]
|
||||
- Full Title: GitHub - SanderMertens/ecs-faq: Frequently asked questions about Entity Component Systems
|
||||
- Category: #articles
|
||||
- Document Tags: [[dev]] [[dev/design-patterns]]
|
||||
- URL: https://github.com/SanderMertens/ecs-faq
|
||||
- Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=GitHub%20-%20SanderMertens/ecs-faq%3A%20Frequently%20asked%20questions%20about%20Entity%20Component%20Systems
|
||||
> [!tldr]
|
||||
> ECS promotes code reusability by separating data from behavior through entities, components, and systems. ECS is a design pattern that can be implemented in various ways with different tradeoffs. Reading existing ECS resources and experimenting with different approaches can help understand and implement ECS applications effectively.
|
||||
|
||||
## Highlights
|
||||
EC frameworks, as typically found in game engines, are similar to ECS in that they allow for the creation of entities and the composition of components. However, in an EC framework, components are classes that contain both data and behavior, and behavior is executed directly on the component. [View Highlight](https://read.readwise.io/read/01j91jpa60m0gseet7h0ve558p))
|
||||
|
||||
users have reported that once ECS "clicked", it made it easier to write, reuse and scale code. [View Highlight](https://read.readwise.io/read/01j91jreb2rx3n0s4kjegsf23p))
|
||||
|
||||
Because of its small set of concepts and rules, building a functional ECS is not hard. There are many benefits to building your own, like the freedom to add new features, and only building features that you really need. [View Highlight](https://read.readwise.io/read/01j91jvvay1c66e7124rbpvff6))
|
||||
|
||||
Things that ECS implementations are generally good at are querying and iterating sets of entities linearly, or dynamically changing components at runtime. Things that ECS implementations are generally not good at are queries or operations that require highly specialized data structures, such as binary trees or spatial structures. [View Highlight](https://read.readwise.io/read/01j91jx0jh2wn8xrhmzvycyf1w))
|
||||
|
||||
The reason for this is that behavior in an ECS is matched with a set of components, vs. for example being tightly coupled with a class in OOP. [View Highlight](https://read.readwise.io/read/01j91jzyev2345b36sy6aphze1))
|
||||
|
||||
new systems can be introduced at any stage of development, and will automatically get matched with any existing and new entities that have the right components. [View Highlight](https://read.readwise.io/read/01j91k0jc5vdz6zfysrwvfqezc))
|
||||
|
||||
This promotes a design where systems are developed as single-responsibility, small units of functionality that can be easily deployed across different projects. [View Highlight](https://read.readwise.io/read/01j91k0ypypatnzt77n85sdrer))
|
||||
|
||||
Designing an ECS application starts with creating the components (data structures) that contain the game data. Important things to take into account are:
|
||||
• How many instances of the data will exist
|
||||
• How often is data accessed
|
||||
• How often is the data mutated
|
||||
• When does data need to be accessed/mutated
|
||||
• Which data is accessed/mutated together
|
||||
• What is the cardinality of the data [View Highlight](https://read.readwise.io/read/01j91k30n38vyb492he5vej8b2))
|
||||
|
||||
It is good practice to design components and systems to have a single responsibility. This makes them easier to reuse across projects, and makes it easier to refactor code. [View Highlight](https://read.readwise.io/read/01j91k34bzgxsycjdsfxfj4jm1))
|
||||
|
||||
An archetype ECS stores entities in tables, where components are columns and entities are rows. Archetype implementations are fast to query and iterate. [View Highlight](https://read.readwise.io/read/01j91k41g8wnx5ahhg34x2jkn5))
|
||||
|
||||
A sparse set based ECS stores each component in its own sparse set which is has the entity id as key. Sparse set implementations allow for fast add/remove operations. [View Highlight](https://read.readwise.io/read/01j91k4e2nj4wk4x8qm0rcw1ea))
|
||||
|
||||
A bitset-based ECS stores components in arrays where the entity id is used as index, and uses a bitset to indicate if an entity has a specific component. [View Highlight](https://read.readwise.io/read/01j91k5v49vx19nff799nzy3ty))
|
||||
|
||||
A reactive ECS uses signals resulting from entity mutations to keep track of which entities match systems/queries. [View Highlight](https://read.readwise.io/read/01j91k649x535px14rzf4r5a85))
|
||||
|
||||
ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. [View Highlight](https://read.readwise.io/read/01j91htdgbpsyzgr1b0ddfa0ac))
|
||||
|
||||
ECS has the following characteristics:
|
||||
• It has entities, which are unique identifiers
|
||||
• It has components, which are plain datatypes without behavior
|
||||
• Entities can contain zero or more components
|
||||
• Entities can change components dynamically
|
||||
• It has systems, which are functions matched with entities that have a certain set of components. [View Highlight](https://read.readwise.io/read/01j91hvjdef0xbq6p44wgq4jrj))
|
||||
|
||||
A framework that lets you add "things" to entities, with a way to query for entities that have some things but not other things, is generally considered to be an ECS. [View Highlight](https://read.readwise.io/read/01j91hx4zdbfka8v3x211xs198))
|
||||
|
||||
• ECS can typically support larger numbers of game objects
|
||||
• ECS code tends to be more reusable
|
||||
• ECS code is easier to extend with new features
|
||||
• ECS allows for a more dynamic coding style [View Highlight](https://read.readwise.io/read/01j91hxszmzjc3mtrcwrg3m53x))
|
||||
|
||||
While ECS and OOP overlap, there are differences that impact how applications are designed:
|
||||
• Inheritance is a 1st class citizen in OOP, composition is a 1st class citizen in ECS.
|
||||
• OOP encourages encapsulation of data, ECS encourages exposed POD (plain old data) objects.
|
||||
• OOP colocates data with behavior, ECS separates data from behavior.
|
||||
• OOP Object instances are of a single static type, ECS entities can have multiple, dynamically changing components [View Highlight](https://read.readwise.io/read/01j91hzkqsfw0qdfg2e282zp3v))
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue