mcpField
E
ecs-design

ecs-design

github.com/christopher-bussDevelopment882 installsUpdated 5w ago
Repository

About ecs-design

ecs-design is a design-guidance skill for jecs in Roblox. It helps developers make ECS decisions about components, entities, systems, queries, and archetypes using a columnar-database mental model.

Key features

  1. 01Columnar-database ECS model
  2. 02Component granularity guidance
  3. 03Entity and relationship decisions
  4. 04Query and system design
  5. 05Archetype fragmentation guidance

Use cases

  1. 01Choosing whether data belongs in an entity
  2. 02Splitting or combining components
  3. 03Designing queries and system responsibilities

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/christopher-buss/skills --skill ecs-design

After installing, type/ecs-designin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

GENERATION.md
references/
best-practices-components.md
best-practices-entities.md
best-practices-systems.md
core-database-model.md
core-query-design.md

Details

From the project README

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

Comments

Markdown supported