ecs-design

Use when designing components, systems, or entity structures for jecs in Roblox. Use when deciding if data should be one component or multiple, when archetype transitions seem expensive, or when choosing entity members vs relationships.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "ecs-design" with this command: npx skills add christopher-buss/skills/christopher-buss-skills-ecs-design

ECS Design Principles

Design guidance for jecs in Roblox.

Core Mental Model

Think of ECS as a columnar database:

DatabaseECS
TableArchetype (unique component combination)
ColumnComponent type
RowEntity
QuerySystem iteration

Design question: "Would I create a separate database column for this?"

Core References

TopicDescriptionReference
Database ModelECS as columnar database, normalization, fragmentationcore-database-model
Query DesignMulti-entity queries, constraint decomposition, traversalcore-query-design

Best Practices

TopicDescriptionReference
Component DesignGranularity decisions, when to split/combine, tags vs databest-practices-components
System DesignSingle responsibility, avoiding work, ordering, data flowbest-practices-systems
Entity DesignWhen to create entities, lazy creation, scaling patternsbest-practices-entities

Quick Decision Guide

QuestionAnswer
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

MistakeWhy it's badFix
Monolithic componentsCache waste, tight couplingSplit by access pattern
Over-atomic componentsQuery complexity, invalid statesCombine semantic units
Frequent add/remove on large entitiesCopies all component dataMutate data component instead
Relationships for every linkFragmentation without benefitUse entity members for forward-only
Cached query inside systemCreates new cache every frameCreate cached queries at module scope

Key Principles

  1. Components by access pattern — Group data that systems need together
  2. Archetype transitions copy data — Adding/removing components copies all data to new archetype; cheap on small entities, expensive on large ones
  3. Entity members vs relationships — Use entity members for forward lookup, relationships for reverse lookup or grouping
  4. Cache queries at module scope — Never call .cached() inside a system
  5. Filter in query — Use with/without, not code conditionals
  6. Fragmentation can help — Relationships enable efficient grouped queries
<!-- Source references: - https://github.com/SanderMertens/flecs/blob/master/docs/DesignWithFlecs.md - https://github.com/SanderMertens/ecs-faq -->

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

roblox-ts

No summary provided by upstream source.

Repository SourceNeeds Review
General

humanizer

No summary provided by upstream source.

Repository SourceNeeds Review
General

isentinel

No summary provided by upstream source.

Repository SourceNeeds Review
General

jest

No summary provided by upstream source.

Repository SourceNeeds Review