Mesa redonda sobre diseño orientado a los datos: Respuestas a sus preguntas

En diciembre, organizamos una mesa redonda de creadores centrada en DOTS con Stunlock Studios (V Rising) y Sunblink Entertainment(HEROish, Hello Kitty Island Adventure). Invitamos a estos pioneros a que compartieran sus experiencias con la pila tecnológica orientada a datos (DOTS), mostraran las funciones y capacidades que la programación orientada a datos ha desbloqueado para sus juegos y vieran cómo están aprovechando la última tecnología del sistema de componentes de entidades (ECS) en Unity 2022 LTS.

La sesión de preguntas y respuestas estuvo muy animada, con muchas preguntas perspicaces del público, tantas que no pudimos responderlas todas en directo. Para continuar, pedimos a Joe Valenzuela, director de ingeniería de software de Unity, y a Rasmus Höök, director técnico de Stunlock Studios, que respondieran a algunas de nuestras preguntas favoritas de la sesión. Descúbralos a continuación y vea el seminario web Maximice el potencial de su juego con un diseño orientado a los datos aquí.

"¿Es mejor empezar los nuevos proyectos con DOTS de inmediato o con GameObjects normales y luego optimizar el rendimiento pasando a ECS (ya sea puro o híbrido)?".

JOE VALENZUELA: ECS, DOTS y el diseño orientado a los datos (DOD) no se limitan a mejorar el rendimiento. También se trata de evitar la complejidad inherente al modelado de problemas mediante programación orientada a objetos (POO).

Cualquiera que pretenda crear un juego multijugador -en particular uno con un servidor autorizado y predicción del lado del cliente- debería considerar seriamente empezar con DOTS. Netcode for Entities ofrece un sistema realmente robusto y potente que se amplía y permite escribir código de juego sencillo.

Si no estás haciendo un juego multijugador, o simplemente estás creando prototipos y buscando probar cosas nuevas rápidamente, puede que quieras considerar aprovechar MonoBehaviour/GameObjects.

"¿Es posible crear un juego enteramente en el sistema DOTS, o DOTS sólo soporta el sistema GameObject?"

JOE VALENZUELA: No, probablemente necesitarás GameObjects en algún momento. Es algo en lo que estamos trabajando.

"¿Cuáles son las desventajas o los casos de uso en los que un desarrollador no debería utilizar DOTS?"

JOE VALENZUELA: Probablemente estés preguntando a la persona equivocada: ¡no se me ocurre ningún caso en el que preferiría utilizar algo distinto a DOTS en Unity! Pero si me tuerces el brazo, supongo que diré que los proyectos tradicionales basados en MonoBehaviour/GameObject realmente sobresalen cuando estás creando prototipos. Cuando se esperan cambios rápidos, no es necesario dedicar mucho tiempo a la elaboración de Bakers o al diseño de los datos. Es un área que esperamos racionalizar para DOTS en el futuro.

"Rasmus, ¿tienes algún consejo para formar ingenieros en programación orientada a datos?".

RASMUS HÖÖK: Creo que un buen comienzo es escribir un código lo más directo y sencillo posible para resolver el problema real que tienes. Adopta la mentalidad de un programador principiante y escribe código muy orientado a los resultados, cuyo objetivo es hacer que el código haga lo que tú quieres que haga. El objetivo inicial no debe ser escribir código reutilizable, crear abstracciones o lo que sea.

En el contexto de los primeros pasos con ECS, no pienses demasiado ni te pases con la ingeniería. Es preferible utilizar al principio componentes y sistemas más grandes en lugar de dividirlos en muchas piezas más pequeñas. Esto hará que su código sea más fácil de seguir. Sepárense más tarde, cuando tengan una razón para hacerlo. Sin duda, cometimos este error al principio.

Yo diría que una buena oportunidad para practicar la programación orientada a datos es cuando tienes algo que necesitas optimizar. Entonces tendrás un problema real con el que podrás experimentar y medir el resultado. También verá lo importante que es pensar en los datos.

"Oímos hablar mucho de DOTS para ampliar y crear juegos más ambiciosos, pero ¿hay ventajas en la reducción? ¿Como usar DOTS en un proyecto pequeño para apuntar a sistemas de gama baja?".

JOE VALENZUELA: El funcionamiento eficiente en sistemas de bajo consumo mejora la calidad del código de simulación que pueden ejecutar. También reduce los requisitos de batería de los dispositivos que funcionan con pilas, lo que aumenta el tiempo de funcionamiento y la salud general del sistema.

"Al pasar de SystemBase a ISystem, ¿cómo se gestionan las llamadas a código gestionado?".

JOE VALENZUELA: Técnicamente, no es necesario deshacerse de código gestionado para utilizar ISystem - código gestionado puede ser llamado desde ISystem. Sus datos gestionados no pueden ser almacenados en un ISystem directamente - para esto, usaría datos gestionados de componentes.

Sin embargo, si te estás preguntando: "¿Cómo elimino las llamadas a código gestionado de ISystem para poder utilizar Burst y obtener el mejor rendimiento de mi código?", la respuesta es... depende.

Si utiliza contenedores .NET, puede encontrar un sustituto adecuado en com.unity.collections. Si estás interactuando con una API gestionada de Unity y no hay una alternativa no gestionada, a veces ayuda dividir el trabajo en fases de "obtención de datos" y "proceso", en esta última es donde realizas tu procesamiento basado en ISystem.

"He leído en la documentación que ECS no es compatible con la arquitectura de escenas múltiples. Entonces, ¿cómo debe hacerse ese planteamiento utilizando ECS?".

JOE VALENZUELA: Nada en ECS impide la carga aditiva de múltiples escenas de Unity. Sin embargo, esas escenas no contendrán ningún dato ECS, sólo GameObjects con MonoBehaviours.

Usted puede crear cualquier número de sub-escenas, y cada una horneará la creación de GameObjects y datos MonoBehaviour en entidad compacta y datos de componentes que pueden ser cargados en tiempo de ejecución. Las subescenas pueden dividirse a su vez en secciones y cada una de ellas puede emitirse o recibirse según sea necesario.

"¿En qué [medida] afecta al determinismo de un proyecto el hecho de tener monoconductas híbridas/DOTS?".

JOE VALENZUELA: El determinismo no es un estado binario, y no garantizamos que cada detalle de ejecución sea idéntico entre ejecuciones. En general, la interoperabilidad híbrida a veces es necesaria para detalles de presentación como los sistemas de partículas o el audio, donde no es necesaria una reproducción perfecta por fotograma.

Para funciones como el juego predictivo, querrá que su simulación se ejecute en ECS.

¿Cómo se gestionan cientos de sistemas? ¿Se ejecutan todos todo el tiempo y simplemente no ejecutan la lógica cuando no hay entidades en la consulta? ¿O se activan contextualmente los sistemas en función del estado del juego?

JOE VALENZUELA: Para facilitar el desarrollo, hemos hecho que los sistemas se actualicen por defecto. La diferencia de rendimiento no es enorme, pero si realmente tiene cientos de sistemas, podría beneficiarse de hacer que se actualicen de forma latente llamando a RequireForUpdate o utilizando el atributo RequireMatchingQueriesForUpdate.

El modismo en ese caso es añadir un RequireForUpdate<Foo>() al sistema relevante, y usar Foo IComponentData en tus escenas como una especie de bandera para activar la actualización de esos sistemas.

"Tengo entendido que DOTS mejora el rendimiento en términos de manejo de grandes cantidades de datos durante el tiempo de ejecución, durante el juego (renderizado especialmente, por lo que he oído). Sin embargo, también he oído que DOTS mejora el rendimiento de la producción en términos de facilitar cualquier refactorización necesaria. ¿Podría hablarnos un poco de cómo DOTS ayuda a la refactorización?".

JOE VALENZUELA: Desde mi punto de vista, uno de los grandes atractivos de DOTS, ECS y DoD en general es que hacen que el estado de la simulación sea más visible e inspeccionable. Si alguna vez ha intentado añadir pruebas a una biblioteca de programación orientada a objetos, es posible que se haya encontrado con el problema de tener que simular o instanciar una gran cantidad de funcionalidad para replicar el estado necesario para invocar una "simple" instancia de método. Con los sistemas de estilo DoD, casi siempre se puede representar un núcleo de transformación como una función independiente que convierte un tipo de valor en otro.

Esto es mucho más fácil de razonar, probar y paralelizar.

"En mi experiencia (de aficionado), encuentro que el DoD crea un acoplamiento estrecho entre los datos y la arquitectura, lo que provoca que los cambios en las estructuras de datos introduzcan un gran trabajo de refactorización. ¿Es ésta su experiencia? ¿Cómo gestionó o evitó este problema?".

RASMUS HÖÖK: Según nuestra experiencia, cuando cambiamos los datos normalmente tenemos que alterar el código que los utiliza, incluso antes de utilizar ECS. Así que no hemos sufrido más de lo acostumbrado.

JOE VALENZUELA: No creo que este sea un problema fundamental del DoD o incluso de nuestro ECS, al menos tal y como ha evolucionado con el tiempo.

Por un lado, el método tradicional para romper el acoplamiento estrecho en la programación orientada a objetos suele consistir en crear funciones orientadas a instancias y jerarquías de clases. Aunque en teoría está bien, este tipo de abstracción es una de las primeras cosas que desaparecen en la programación de alto rendimiento.

No hay nada que le impida escribir funciones de utilidad en un ECS. Si bien es cierto que en nuestro ECS hay que volver a visitar los sistemas cuando se cambia el contrato de datos para consultas específicas, eso puede ser una señal de que se están consultando los datos de forma dispersa. ¿Está transformando repetidamente los datos de los componentes? ¿Puede reescribirse para reducir el número de mutaciones por fotograma? ¿Lectura repetida de los datos de los componentes? Tal vez usted puede izar en una estructura de datos inmutable temprano en el marco.

Por último, creo que es seguro decir que el DoD, o al menos ECS, hace mucho más explícito el estado del problema. Eso no es negativo: Esa es una compensación diferente. Prefiero razonar sobre un acoplamiento estrecho mientras refactorizo que sobre uno débil o implícito.

"¿Funciona bien el ECS/OOP para juegos para móviles, o puedes recomendar este enfoque para un proyecto de juegos para móviles? ¿Algún riesgo o consideración?"

JOE VALENZUELA: Varios clientes han utilizado con éxito ECS en sus juegos para móviles. Echa un vistazo a esta charla de la GDC para ver cómo Sunblink Entertainment lo utilizó para HEROish.

"¿Cómo hiciste para establecer contactos con V Rising? ¿Utilizaste Netcode for Entities u otro framework?".

RASMUS HÖÖK: Creamos nuestro propio marco. Empezamos a utilizar DOTS para la producción muy pronto y éramos conscientes de los riesgos de hacerlo. Para eliminar tantos riesgos como pudiéramos, intentamos confiar en el menor número posible de paquetes e instalamos los nuestros propios cuando era posible. Siempre hemos hecho juegos multijugador y siempre hemos utilizado nuestras propias soluciones, así que nos sentíamos cómodos haciéndolo nosotros mismos.

"¿Es ECS lo suficientemente estable para la producción? Hemos estado luchando con él durante los últimos meses con un prototipo y no estamos seguros de si eran dolores de crecimiento a medida que aprendemos o si no está del todo listo para esforzarse por un proyecto de producción ECS puro ".

RASMUS HÖÖK: Diría que es lo bastante estable para la producción, pero le faltan funciones que muchos desarrolladores de juegos darían por sentadas. Nuestro código de juego es puro ECS en V Rising, pero las cosas de presentación, tales como personajes animados, efectos de partículas, y la interfaz de usuario, están todos usando GameObjects. Siendo realistas, creo que un enfoque híbrido es lo mejor para la mayoría de los equipos que inician un proyecto hoy en día.

Hicimos V Rising utilizando un enfoque unidireccional. Usamos ECS puro para empujar datos sólo a GameObjects, nunca al revés. Por ejemplo, guardamos el estado de un personaje en datos ECS - entrada, velocidad, etc., que decidirán el estado de locomoción, y qué animación debe estar activa y en qué momento y velocidad. Entonces nos aseguramos de que el animador del GameObject está en ese estado. El estado en que se encuentre el animador nunca afecta a la jugabilidad. Creo que esta separación simplifica globalmente el juego.

JOE VALENZUELA: ECS está listo para la producción y lo utilizan clientes de todo el mundo, pero aún nos queda mucho camino por recorrer hasta que la experiencia sea tan fluida como nos gustaría. Esté atento a las novedades y gracias por utilizar DOTS.

Haga realidad su ambicioso juego con DOTS, que le permite crear juegos escalables de alto rendimiento y experiencias inolvidables. Consigue las últimas funciones con Unity 2022 LTS y prueba la última tecnología en Unity 6 Preview.