¡Bienvenidos a la wiki de Svelto.ECS!

Por favor, siéntete libre de modificar esta wiki si puedes agregarle más valor.

Svelto.ECS es el resultado de años de investigación y aplicación de los principios SOLID en el desarrollo de juegos. Es una de las muchas implementaciones del paradigma ECS disponible para C# con algunas características únicas y novedosas, introducidas para resolver los problemas intrínsecos que se derivan del patrón en sí.

Esta wiki no pretende sustituir los artículos escritos en el blog http://www.sebaslab.com/, sino que esta los complementa. Cualquiera que tenga un buen conocimiento sobre Svelto es libre de contribuir. Esta Wiki necesita tu ayuda para estar al día.

A simple vista

La forma más sencilla de probar las características fundamentales de Svelto.ECS es descargar el Ejemplo Vanilla y los Mini-Ejemplos (en inglés)

Desafortunadamente, no hay una manera simple de entender la teoría detrás de este código que podría parecer simple, pero confusa al mismo tiempo. Por lo tanto, la única forma de proceder es dedicar un tiempo a leer los artículos y probar los ejemplos proporcionados.

Nota: Es posible que los ejemplos estén desactualizados, comparados con las últimas actualizaciones de código y buenas prácticas.

Introducción

Últimamente he estado discutiendo Svelto.ECS ampliamente con varios programadores, más o menos experimentados. Recolecté muchos comentarios y tomé muchas notas que utilizaré como punto de partida para mis próximos artículos, donde hablaré más sobre la teoría y las buenas prácticas. Solo para dar un poco de spoiler, me di cuenta de que el mayor obstáculo al que se enfrentan los nuevos codificadores al comenzar a usar Svelto.ECS es el cambio de paradigma de programación. Es asombroso cuánto tengo que escribir para explicar los nuevos conceptos introducidos por Svelto.ECS en comparación con la pequeña cantidad de código escrito para desarrollar el framework. De hecho, si bien el framework en sí es muy simple (y ligero), aprender cómo pasar de la programación orientada a objetos, basada en herencia de clase o incluso al simple diseño basado en componentes de Unity, al diseño “nuevo” modular y desacoplado que Svelto.ECS te fuerza a usar, es lo que generalmente desalienta a las personas a adoptar el framework.

Al ser el framework ampliamente utilizado en Freejam, también noté que es gracias a mi disponibilidad continua para explicar los conceptos fundamentales que mis compañaros de trabajo tienen menos dificultades para adaptarse al flujo de trabajo. Aunque Svelto.ECS trata de ser lo más rígido posible, los malos hábitos son difíciles de morir, por lo que los usuarios tienden a abusar de la poca flexibilidad que queda para adaptar el framework a los paradigmas “antiguos” con los que se sienten cómodos. Esto puede causar una catástrofe debido a malentendidos o reinterpretación de los conceptos que están detrás de la lógica del framework. Es por eso que estoy comprometido a escribir tantos artículos como me sea posible, especialmente porque sé que el paradigma ECS es la mejor solución que encontré hasta ahora para escribir código eficiente y mantenible para grandes proyectos que se refactorizan y reforman varias veces a lo largo de los años. Tanto Robocraft, como Cardlife, son la prueba existente de lo que trato de demostrar.

No voy a hablar mucho sobre las teorías detrás del framework en este artículo, pero quiero recalcar lo que me llevó a abandonar el uso de un contenedor IoC y comenzar a utilizar exclusivamente un framework ECS: un contenedor IoC es una herramienta muy peligrosa si se usa sin la Inversión de Control en mente. Como posiblemente habrás leído en alguno de mis artículos anteriores, diferencio entre Inversión de Control de Creación y Inversión de Control de Flujo. La Inversión de Control de Flujo es básicamente el principio de Hollywood “No nos llames, nosotros le llamaremos”. Esto significa que las dependencias inyectadas nunca deberían de usarse directamente a través de métodos públicos, al hacerlo, solo estarí as usando un contenedor IoC como sustituto de cualquier otra forma de inyección global como singletons. Sin embargo, una vez que se utiliza un contenedor de IoC siguiendo el principio de IoC, principalmente se termina usando el patrón de estrategia repetidamente para inyectar managers que solo se utilizan para registrar las entidades a administrar. En un contexto real de Inversión de Control de Flujo, los managers siempre están a cargo de manejar las entidades. ¿Suena como de lo que trata el patrón ECS? Por supuesto que lo hace. A partir de este razonamiento, tomé el patrón ECS y lo convertí en un framework rígido, hasta el punto en que se puede considerar el usarlo como adoptar un nuevo paradigma de programación.

Raiz de composición (composition root)

Conceptos Básicos