ECS orientado a datos: propiedad de los datos e iteración antes que las etiquetas de arquitectura

Partir del trabajo real

Una arquitectura entidad-componente-sistema (ECS) resulta útil cuando facilita organizar los datos y el procesamiento del juego. La etiqueta por sí sola no promete velocidad ni simplicidad. Empieza por una operación que se ejecute con frecuencia: identifica qué campos lee, cuáles escribe y qué entidades la necesitan realmente.

Identidad, datos y sistemas

Las entidades aportan la identidad, los componentes asocian datos a las entidades y los sistemas operan sobre combinaciones seleccionadas de componentes. Flecs documenta estos roles y los sistemas basados en consultas. [1] El almacenamiento por arquetipos agrupa conjuntos de componentes coincidentes; Unity Entities guarda esos datos en chunks, y los cambios estructurales pueden mover entidades de un grupo a otro. [2] Otras estrategias de almacenamiento de ECS implican compromisos distintos.

Ejemplo resuelto

Consideremos, a modo de ilustración, una actualización de 20000 chispas en movimiento. Cada una requiere una posición y una velocidad de tres componentes, y cada componente se representa con un float de 4-byte. La carga útil del movimiento es 20000 × 6 × 4 = 480000 bytes.

Un registro monolítico hipotético de 128 bytes por chispa ocuparía 2560000 bytes, incluidos campos no relacionados. Estos cálculos de carga útil no demuestran el tráfico real de cache ni una mejora de velocidad: la alineación, el padding, la ocupación de los chunks y los patrones de acceso siguen influyendo. Lo que justifican es comprobar si el bucle crítico puede recorrer arrays compactos de Position y Velocity sin seguir punteros por objeto.

Define el sistema de integración de modo que lea Velocity y escriba Position. Un sistema de ciclo de vida se encarga de la expiración. Encola las eliminaciones para un límite de cambios estructurales documentado, en lugar de invalidar el recorrido en curso. El renderizado puede leer las posiciones resultantes una vez que se complete la dependencia necesaria.

Flujo de trabajo práctico

Antes de planificar trabajo en paralelo, traza qué lee y qué escribe cada sistema. Dos sistemas que escriben el mismo componente requieren un orden o una partición segura. Los handles estables de entidad deben sobrevivir a los movimientos del almacenamiento; las direcciones de componentes guardadas en cache quizá no. Especifica cuándo hay que refrescar las consultas y las referencias.

Mantén los campos de alta frecuencia cerca de la operación que los usa y separa los datos voluminosos y poco frecuentes cuando las mediciones lo respalden. Examina el número de arquetipos, la ocupación de los chunks, el coste de los cambios estructurales y las búsquedas aleatorias. Una relación entre entidades que salta repetidamente a un almacenamiento no relacionado puede dominar una actualización que, por lo demás, sería lineal.

Compromisos y validación

Añadir y quitar componentes no es gratis en todos los ECS. Muchas combinaciones diminutas de componentes pueden fragmentar la carga de trabajo, mientras que un componente gigante puede hacer que sistemas sin relación toquen datos de más. Elige la granularidad según la propiedad de los datos y el acceso medido, no según una regla que dicte que cada escalar merece su propio componente.

Compara escenas representativas con comportamiento idéntico e incluye creación, destrucción y transiciones. Inspecciona el coste total del fotograma y la memoria, no solo el mejor bucle interno. Un juego pequeño con objetos muy individuales puede usar con razonable acierto objetos convencionales junto con una simulación masiva gestionada por el ECS.

Fuentes

[1] Flecs quickstart — Sander Mertens y colaboradores de Flecs.

[2] Archetype concepts — documentación de Unity Entities.