Bevy 0.12 - Motor de juegos basado en datos hecho con Rust

 (bevyengine.org)
2 puntos por GN⁺ 2023-11-05 | 1 comentarios | Compartir por WhatsApp
  • El renderizador ahora admite Deferred Rendering opcional, y permite elegir la ruta forward o deferred por material, además de establecer un valor predeterminado global con DefaultOpaqueRendererMethod
  • Las apps o plugins existentes de Bevy deben revisar el proceso de migración mediante la guía de migración de 0.11 a 0.12
  • Bevy Asset V2 agrega preprocesamiento de assets, configuración basada en archivos .meta, múltiples AssetSource, eventos de carga de dependencias recursivas, I/O asíncrono de assets y handles mejorados
  • El preprocesamiento de assets se activa con AssetPlugin { mode: AssetMode::Processed } y la feature de Cargo bevy/asset_processor, pero por ahora todavía no se recomienda para la mayoría de los casos de uso
  • En Android, la app ya no se bloquea al suspenderse; en su lugar, detiene la ejecución del sistema hasta que se reanuda, y ofrece los eventos ApplicationLifetime::Suspended y ApplicationLifetime::Resumed
  • Se añadieron specular_transmission, diffuse_transmission, thickness, ior, attenuation_color y attenuation_distance a StandardMaterial, lo que permite representar materiales translúcidos como vidrio, agua, plástico, hojas y papel
  • El cargador de glTF ahora soporta las extensiones KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume y KHR_materials_emissive_strength, y puede importar un segundo mapa UV como TEXCOORD1 o UV1
  • Ahora es posible el batching/instancing automático de draw commands, y actualmente se pueden agrupar entidades con el mismo material y mesh; también se pueden excluir con el componente NoAutomaticBatching
  • Las sombras incorporan PCF Shadow Filtering, con soporte para sombras más suaves en DirectionalLight y SpotLight; el método predeterminado es ShadowMapFilter::Castano13
  • Se añadieron one-shot systems al ECS, de modo que se puede registrar un sistema y ejecutarlo cuando se necesite mediante SystemId, aunque no soporta exclusive system, system para system piping, auto-invocación ni evaluación en paralelo
  • FixedTime fue eliminado y Time ahora devuelve valores acordes al contexto también en FixedUpdate, evitando además la “death spiral” en la que la acumulación excesiva de FixedUpdate congelaba la app
  • En AnimationPlayer, set_elapsed fue reemplazado por seek_to, stop_repeating por set_repeat(RepeatAnimation::Never), y elapsed ahora devuelve el tiempo real transcurrido sin verse afectado por la velocidad de la animación
  • El import de shaders en Bevy cambió a una sintaxis estilo Rust, con soporte para #import bevy_pbr::forward_io::VertexOutput, imports múltiples con llaves, imports de rutas parciales y uso de rutas completamente calificadas
  • En UI, UiMaterial permite usar shaders de material personalizados en nodos de UI, y el componente Outline permite contornos de nodos que no ocupan espacio en el layout
  • Se añadió el recurso ManageAccessibilityUpdates a la integración de accesibilidad, lo que permite detener la actualización automática del árbol de accesibilidad del motor cuando su valor es false

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-05
Opiniones de Hacker News

  • Comparado con motores tradicionales como Unity o Godot, Bevy tiene una forma completamente distinta de crear juegos.
    Maneja todo con código Rust, sin UI ni scripting, así que se parece más a libGDX o Cocos2D-x. Pero como usa ECS y Rust, la forma de programar también cambia mucho, por lo que en la práctica se siente como si estuviera en su propia isla.
    Me gustaría ver un juego indie exitoso hecho con Bevy, pero es probable que la mayoría de los desarrolladores de juegos prefieran herramientas tradicionales que ya aprendieron y que también usa la gente a su alrededor. La intersección entre quienes quieren crear juegos y además prefieren Rust no es grande, y aun dentro de ese grupo parece que muchos elegirán herramientas con confianza y material acumulados, antes que dedicar mucho tiempo y esfuerzo a aprender un motor nuevo y experimental.
    En lo personal, creo que Bevy necesita un IDE y un lenguaje de scripting basados en Bevy y Rust. No eliminaría la barrera de tener que dedicar mucho esfuerzo a un proyecto nuevo, pero podría resultar mucho más amigable para usuarios nuevos sin experiencia en Rust y a quienes les intimida empezar frente a un muro de código. Contrasta con Unity o Godot, donde puedes hacer un prototipo muy básico sobre un canvas en cuestión de horas.
    Entiendo que los desarrolladores están en contra de un lenguaje de scripting, pero creo que se necesitan hot reload y debugging más profundo, y que hacerlo de forma efectiva solo con Rust es difícil. Muchos desarrolladores de juegos también podrían sentirse abrumados por Rust y el borrow checker. Dicho eso, ahora no tengo el tiempo, los recursos ni la voluntad para implementarlo por mi cuenta.

    • Por la estructura de Bevy, no hay muchas situaciones en las que te topes directamente con el borrow checker. Los componentes y recursos en general usan tipos con ownership, y se pueden manejar mediante Query y Ref sin mayores preocupaciones.
      Probé un poco Bevy y revisé el repositorio; no encontré ninguna anotación de lifetime.
    • En desarrollo de juegos, lo que más tiempo consume suele ser la gestión de assets, y después muchas veces viene la programación. Un motor como Bevy intenta reducir el tiempo dedicado a corregir bugs, pero si le falta un pipeline de assets, ese ahorro se pierde del lado de los assets.
      Un lenguaje de scripting ayudaría un poco, pero quienes usan Bevy actualmente suelen tener un perfil muy técnico y muchas veces no son diseñadores de tiempo completo, así que no parece haber una demanda tan urgente.
      Me entusiasma el impacto que la comunidad de Rust podría tener en el desarrollo de juegos, y algún día me gustaría contribuir, pero por ahora pienso mantener mi pipeline de C++/C# por las razones mencionadas. Aprenderé Rust bien en paralelo, y cuando las herramientas maduren podría considerarlo para proyectos futuros.
      El hot reload muchas veces es un paliativo cuando los tiempos de compilación se vuelven difíciles de tolerar. Si el promedio es de 4 segundos y una recompilación completa ronda los 20 segundos, disminuye la necesidad de invertir muchos recursos en formas de evitar la compilación completa.
      Sin embargo, escuché que Rust en general tiene tiempos de compilación más largos, así que la necesidad de scripting o hot reload podría llegar antes de lo esperado. Aun así, es poco probable que los proyectos indie actuales en curso ya hayan llegado a esa barrera.
    • El IDE lleva bastante tiempo en los planes, y tengo entendido que es la máxima prioridad después de este lanzamiento.
      Cart, el creador de Bevy, considera que Bevy debe priorizar Rust, y personalmente estoy de acuerdo. Eso no significa que no se puedan crear plugins para varios lenguajes de scripting; de hecho, ya existen algunos.

  • Soy el creador de Bevy y líder del proyecto. Pueden preguntarme lo que quieran.

    • Estamos creando con Bevy una app WASM bastante grande para el tamaño de nuestra empresa, y la experiencia usando el motor ha sido muy buena.
      Bevy y su comunidad son excelentes. Necesitábamos trabajar en algunos tickets, y fue muy fácil encontrar a uno de los contribuidores principales, patrocinarlo e impulsar la solicitud hasta completarla. Por ejemplo, eso pasó con los morph targets.
      Carter está construyendo algo realmente importante, y hay un gran impulso detrás. Bevy hace que desplegar en la web sea muy fácil, y más gente debería echarle un vistazo. La comunidad también es buena y es fácil conseguir ayuda.
    • La documentación es limitada, así que me cuesta animarme a entrar. El libro de Bevy se lee completo en unos minutos, y cuando te trabas se acaban rápido los recursos de referencia.
      ¿Cuándo mejorará la documentación? Al ver las notas de lanzamiento, idealmente me gustaría que cada funcionalidad tuviera varias páginas de documentación. Entiendo que es mucho trabajo, y quizá la documentación completa solo sea posible después de la estabilización.
    • Como desarrollador de juegos por hobby, si empezara un proyecto nuevo creo que lo haría con Bevy. Se siente como un punto medio bien logrado entre Love y Godot: más sólido que Love, pero no tan orientado a principiantes como Godot.
      ¿Qué tan opinado es Bevy como motor? Me interesa saber si alguna vez tuvieron que hacer concesiones entre funcionalidades y accesibilidad para desarrolladores.
      ¿Qué tipo de proyecto es el más ideal para Bevy en este momento?
    • Me interesa saber qué ventajas y desventajas tiene escribir juegos con Rust y Bevy frente a otros lenguajes. En particular, quisiera oír sobre rendimiento, seguridad y velocidad de desarrollo.
    • ¿Cuándo podremos ver funcionalidades que permitan sistemas dinámicos y scripting de Bevy de primera clase?
      Hay algunos plugins de scripting y ahora parecen enfocarse principalmente en rhai, pero da la impresión de que están bloqueados por la falta de soporte adecuado en Bevy.
      Independientemente de si el enfoque actual de Bevy son o no los juegos solo en Rust, existe demanda de scripting, y ya hay gente ocupada buscando soluciones de terceros. No espero scripting oficial de Bevy de inmediato, pero creo que Bevy debería aceptar las bases para que los crates de terceros puedan funcionar.

  • El artículo dice que el renderizado diferido no soporta MSAA, pero eso solo es cierto en una implementación ingenua.
    Por ejemplo, se podría crear en un pre-pass una máscara de stencil para píxeles complejos y, usando rechazo temprano jerárquico de stencil, ejecutar un pass por muestra para los píxeles complejos y un pass por píxel para los demás. El aprovechamiento de los lanes SIMD no es perfecto.
    También se puede tener un pass que procese la máscara de píxeles complejos y reúna un buffer de coordenadas (x, y, sample); luego, en un único pass de compute shader híbrido por píxel/por muestra, también se puede lograr un aprovechamiento perfecto de los lanes SIMD.

    • Interesante. Hace tiempo pensé en esto, pero asumí que sería demasiado lento. Me pregunto si conoces algún título lanzado que use esa técnica.

  • Llevo un tiempo haciendo un juego con Bevy. Pueden ver el código y también hacer preguntas
    https://ant.care/
    https://github.com/MeoMix/symbiants
    Las dificultades hasta ahora son que el sistema de UI es demasiado verboso para crear widgets cómodamente, así que me cambié a egui, aunque creo que dentro de un año probablemente vuelva a Bevy nativo. egui también tiene limitaciones importantes
    No hay mucho soporte para relaciones padre/hijo, y ECS tiene una estructura que en cierto modo las desincentiva. Ponerle una etiqueta a un sprite y hacer que, al mover/rotar el sprite, la etiqueta solo siga la posición pero no la rotación resultó más difícil de lo esperado
    La persistencia de entidades entre sesiones no está soportada de forma predeterminada. Entity sirve para la unicidad del lado del cliente, y recrear fácilmente relaciones padre/hijo guardadas tampoco ocurre automáticamente
    Todavía no hay soporte para paralelismo en WASM, pero buena parte de la arquitectura de Bevy está diseñada para mantener flexible el orden de los sistemas y así obtener mejoras de rendimiento mediante la paralelización de tareas
    Las consultas espaciales se sienten en conflicto con los objetivos de ECS. Cuando uno quiere buscar por valor de Position, en vez de por tipo, es decir, por si una entidad tiene Position, terminan apareciendo muchas cachés auxiliares que hay que sincronizar con el motor de consultas
    Cuando se modifica el mundo con commands, los cambios se difieren para procesarlos por lotes por rendimiento, pero si hay mucho comportamiento diferido se vuelve difícil crear sistemas que cambien el mundo de forma activa. Por eso termino llamando a apply_deferred con frecuencia y usando comandos personalizados para resolver condiciones de carrera
    WASM en Android, especialmente la combinación Pixel 6 y Chrome, actualmente no funciona, pero es un problema de una dependencia subyacente y está previsto que se corrija en Bevy 13
    Lo bueno es que la combinación de un motor en Rust y un juego en Rust es muy agradable para trabajar, y Rust+WASM casi nunca se siente como si la tecnología te pusiera trabas. Una vez que la cabeza empieza a pensar al estilo ECS, es difícil volver atrás y resulta muy flexible. Quizá incluso demasiado flexible
    La comunidad es activa, así que es fácil encontrar gente con quien hablar de los problemas; no hay mucha documentación, pero sí muchos ejemplos. También hay mucho optimismo sobre el futuro, el desarrollo avanza rápido y cada release mejora bastante las principales preocupaciones

    • Como referencia, ant.care no funciona en iPhone. Lo probé tanto en Safari como en Firefox, y el sitio web se recarga en un bucle infinito después de un rato

  • Las notas de la versión son excelentes
    Para desarrolladores de juegos/motores con experiencia, algunas partes pueden ser demasiado introductorias, pero para alguien que no vive siempre en ese mundo, el equilibrio entre explicar los cambios y contextualizar los temas me pareció muy bueno

  • Vi un chiste de que hay 5 juegos escritos en Rust, pero 50 motores de juegos
    ¿Existe realmente una lista de juegos escritos con Bevy?

  • Todos los frameworks empiezan diciendo que van a implementar algo más tradicional de forma simple, limpia y rápida, pero les faltan las funciones vistosas.
    Luego, al ponerse al día con esas funciones, se convierten en monstruos igual de complejos, y el ciclo se repite.

    • Visto a grandes rasgos dentro del ciclo de vida de un proyecto de software, tiene sentido, pero como puede aplicarse tal cual a cualquier afirmación sobre la simplicidad o facilidad de uso del software, no me parece una crítica especialmente útil.
      La conclusión suena como “todo software fácil que agregue funciones está condenado”, lo cual es un poco dramático.
      Me da curiosidad si hay ideas o preocupaciones concretas sobre la arquitectura de Bevy o su forma de agregar funciones. Estamos haciendo todo lo posible para evitar ese destino.
    • No es que no esté de acuerdo, pero Bevy tiene una fortaleza que la mayoría de los frameworks no tiene: modularidad. No solo como concepto, sino una modularidad que se ha demostrado que funciona bien en la práctica.
      Tiny Glade usa bevy_ecs, pero no usa para nada los crates de renderizado de Bevy. Yo también tengo personalmente varios PR en curso para implementar rutas de renderizado alternativas, por ejemplo ray tracing o renderizado de meshlets impulsado por GPU + visibility buffer, y casi no cambian los internos de Bevy.
      Desde el punto de vista del usuario, tampoco cambia mucho. Agregas FeatureFooPlugin a la app, usas algo como FooComponent y funciona.
      Los crates o plugins individuales pueden hincharse, pero Bevy en su conjunto estará bien. Los usuarios pueden ignorar esos plugins y usar otra cosa que se ajuste mejor a sus necesidades.
      Además, esto es un motor de juegos. Por definición es un monstruo grande y complejo, y termina absorbiendo todo tipo de funciones porque pueden servir para algún juego. La clave es cómo afecta la proliferación de funciones a la usabilidad. Si hay 1000 funciones pero no necesitas interactuar con la mayoría, no hay ningún problema.
    • Creo que el punto clave es si el proyecto tiene la voluntad de romper con el pasado para mantener la API simple, limpia y rápida.
      Es cierto que es más fácil en proyectos nuevos que no tienen que preocuparse por la compatibilidad hacia atrás. Por lo que he visto de Bevy, tiene una cultura fuerte de exigir una buena experiencia para el usuario y reducir la superficie de la API. Quizá sea gracias al empaquetado de Rust, pero me parece bien que sea bastante activo a la hora de romper con el pasado para lograrlo.
      Lo bueno de cargo es que, aunque decidas depender de Bevy, si una versión futura rompe cosas no tienes que perseguir un objetivo en movimiento. Simplemente puedes quedarte en tu versión. Aun así, también ofrecen guías para facilitar la migración a la versión más reciente. Al menos esa fue mi experiencia tras haber usado un poco Bevy.

  • Al subir de 0.10 a 0.11 tuve que hacer bastantes cambios en la app, pero esta vez compiló de inmediato.

  • Bevy es uno de mis motores de juegos favoritos, especialmente para proyectos grandes. El preprocesamiento de Asset V2 y los archivos .meta parecen muy útiles.
    También espero con ganas el soporte de lightmaps en futuros lanzamientos.

  • Estaba viendo los ejemplos web y llegué a la sección de UI; parece que todo se maneja dentro del canvas.
    ¿Se podría construir la UI con el DOM en su lugar y conectarla a WASM?

    • Sí se puede, y de hecho he visto casos donde lo hicieron así. Hay que crear una forma de intercambiar información entre la UI y Bevy.
      Desde Rust, es decir del lado de WASM, hay opciones como web_sys, y desde JavaScript también se pueden llamar funciones de WASM, así que hay muchas alternativas.