ecs-design
1
总安装量
1
周安装量
#53329
全站排名
安装命令
npx skills add https://github.com/christopher-buss/skills --skill ecs-design
Agent 安装分布
kilo
1
amp
1
opencode
1
kimi-cli
1
codex
1
github-copilot
1
Skill 文档
ECS Design Principles
Design guidance for jecs in Roblox.
Core Mental Model
Think of ECS as a columnar database:
| Database | ECS |
|---|---|
| Table | Archetype (unique component combination) |
| Column | Component type |
| Row | Entity |
| Query | System iteration |
Design question: “Would I create a separate database column for this?”
Core References
| Topic | Description | Reference |
|---|---|---|
| Database Model | ECS as columnar database, normalization, fragmentation | core-database-model |
| Query Design | Multi-entity queries, constraint decomposition, traversal | core-query-design |
Best Practices
| Topic | Description | Reference |
|---|---|---|
| Component Design | Granularity decisions, when to split/combine, tags vs data | best-practices-components |
| System Design | Single responsibility, avoiding work, ordering, data flow | best-practices-systems |
| Entity Design | When to create entities, lazy creation, scaling patterns | best-practices-entities |
Quick Decision Guide
| Question | Answer |
|---|---|
| Should this be an entity? | Only if it needs per-instance state that changes over time |
| Split or combine? | “Is there a system that needs A but not B?” |
| Tag or data component? | Tags for stable classification (free to add/remove), data for state |
| Relationship or entity ref? | Relationship if reverse lookup needed, entity member otherwise |
| Is fragmentation bad? | Only if thousands of archetypes AND you query broadly |
| When does DOD matter? | Thousands of entities, per-frame, CPU-bound |
Common Mistakes
| Mistake | Why it’s bad | Fix |
|---|---|---|
| Monolithic components | Cache waste, tight coupling | Split by access pattern |
| Over-atomic components | Query complexity, invalid states | Combine semantic units |
| Frequent add/remove on large entities | Copies all component data | Mutate data component instead |
| Relationships for every link | Fragmentation without benefit | Use entity members for forward-only |
| Cached query inside system | Creates new cache every frame | Create cached queries at module scope |
Key Principles
- Components by access pattern â Group data that systems need together
- Archetype transitions copy data â Adding/removing components copies all data to new archetype; cheap on small entities, expensive on large ones
- Entity members vs relationships â Use entity members for forward lookup, relationships for reverse lookup or grouping
- Cache queries at module scope â Never call
.cached()inside a system - Filter in query â Use with/without, not code conditionals
- Fragmentation can help â Relationships enable efficient grouped queries