Bevy 0.12 - motor de jogos orientado a dados feito em Rust

• O renderizador agora oferece suporte opcional a Deferred Rendering, permitindo escolher o caminho forward ou deferred por material e definir o padrão global com DefaultOpaqueRendererMethod
• Apps ou plugins Bevy existentes precisam verificar o procedimento de migração no Guia de Migração de 0.11 para 0.12
• O Bevy Asset V2 oferece pré-processamento de assets, configuração baseada em arquivos .meta, vários AssetSource, eventos de carregamento de dependências recursivas, I/O assíncrono de assets e handles aprimorados
• O pré-processamento de assets é ativado com AssetPlugin { mode: AssetMode::Processed } e a feature Cargo bevy/asset_processor, mas no momento ainda não é recomendado para a maioria dos casos de uso
• No Android, o app não trava mais ao ser suspenso, interrompe a execução do sistema até ser retomado e fornece os eventos ApplicationLifetime::Suspended e ApplicationLifetime::Resumed
• StandardMaterial recebeu specular_transmission, diffuse_transmission, thickness, ior, attenuation_color e attenuation_distance, permitindo representar materiais translúcidos como vidro, água, plástico, folhas e papel
• O loader glTF agora oferece suporte às extensões KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume e KHR_materials_emissive_strength, além de poder importar um segundo mapa UV em TEXCOORD1 ou UV1
• O batching/instancing automático de draw commands agora é possível, e entidades com o mesmo material e mesh podem ser agrupadas atualmente, com exclusão via componente NoAutomaticBatching
• As sombras passaram a usar PCF Shadow Filtering, oferecendo sombras mais suaves em DirectionalLight e SpotLight; o método padrão é ShadowMapFilter::Castano13
• O ECS ganhou one-shot systems, que podem ser registrados e executados quando necessário via SystemId, mas sem suporte a exclusive system, systems para system piping, autochamada ou avaliação paralela
• FixedTime foi removido, e Time agora retorna valores apropriados ao contexto também em FixedUpdate, evitando a “death spiral” em que o acúmulo excessivo de FixedUpdate fazia o app travar
• No AnimationPlayer, set_elapsed foi substituído por seek_to, stop_repeating por set_repeat(RepeatAnimation::Never), e elapsed agora retorna o tempo real decorrido sem influência da velocidade da animação
• O import de shaders do Bevy mudou para uma sintaxe no estilo Rust, com suporte a #import bevy_pbr::forward_io::VertexOutput, imports múltiplos com chaves, imports por caminho parcial e caminhos totalmente qualificados
• Na UI, UiMaterial permite usar shaders de material customizados em nós de interface, e o componente Outline adiciona contornos a nós sem ocupar espaço no layout
• A integração de acessibilidade recebeu o recurso ManageAccessibilityUpdates, que permite interromper a atualização automática da árvore de acessibilidade do engine quando o valor é false

[GN⁺]

Comentários do Hacker News

• O Bevy é completamente diferente na forma de fazer jogos quando comparado a motores tradicionais como Unity ou Godot
  Como tudo é feito em código Rust, sem UI nem scripting, ele fica mais próximo de libGDX ou Cocos2D-x. Ainda assim, por usar ECS e Rust, o estilo de programação muda bastante de novo, então na prática parece estar na própria ilha
  Eu gostaria de ver jogos indie de sucesso feitos com Bevy, mas a maioria dos desenvolvedores de jogos provavelmente prefere ferramentas tradicionais que já aprendeu a usar e que também vê ao redor. A interseção entre quem quer fazer jogos e também prefere Rust não parece tão grande e, mesmo dentro dela, muita gente deve escolher ferramentas com mais confiança e material acumulado em vez de investir bastante tempo e esforço para aprender um motor novo e experimental
  Pessoalmente, acho que o Bevy precisa de uma IDE e linguagem de scripting baseadas em Bevy e Rust. Isso não elimina a barreira de esforço grande para começar um projeto novo, mas pode torná-lo bem mais familiar para novos usuários sem experiência com Rust e que se sentem intimidados por começar diante de uma parede de código. É um contraste com Unity ou Godot, onde dá para fazer um protótipo bem básico no canvas em poucas horas
  Pelo que entendo, os desenvolvedores são contra uma linguagem de scripting, mas hot reload e depuração mais profunda são necessários, e não acho que isso seja fácil de fazer de forma eficaz só com Rust. Muitos desenvolvedores de jogos também podem se sentir sobrecarregados por Rust e pelo borrow checker. Dito isso, no momento não há tempo, recursos nem disposição para implementar isso diretamente

  • Pela estrutura do Bevy, não é comum bater de frente com o borrow checker. Componentes e recursos em geral usam tipos com ownership, e com Query e Ref dá para lidar com isso sem grandes preocupações
    Mexi um pouco no Bevy e, olhando o repositório, encontrei zero anotações de lifetime
  • No desenvolvimento de jogos, o que mais consumia tempo era gestão de assets e, em muitos casos, programação vinha em segundo. Motores como o Bevy tentam reduzir o tempo gasto corrigindo bugs, mas, se o pipeline de assets for fraco, esse ganho se perde do lado dos assets
    Uma linguagem de scripting ajudaria um pouco, mas quem usa Bevy hoje tende a ser muito técnico e muitas vezes nem trabalha como designer em tempo integral, então não parece haver uma demanda tão urgente
    Tenho expectativa sobre o impacto da comunidade Rust no desenvolvimento de jogos e gostaria de contribuir algum dia, mas, por enquanto, pelos motivos citados, vou manter meu pipeline em C++/C#. Vou aprender Rust em paralelo e, quando as ferramentas amadurecerem, posso considerar em projetos futuros
    Hot reload muitas vezes é uma solução temporária usada quando o tempo de compilação começa a ficar difícil de suportar. Se a média for 4 segundos e uma recompilação completa levar uns 20 segundos, diminui a necessidade de investir muitos recursos em evitar compilações completas
    Ainda assim, ouvi dizer que Rust em geral tem tempos de compilação mais longos, então a necessidade de scripting ou hot reload pode aparecer mais cedo do que o esperado. Mesmo assim, projetos indie em andamento hoje provavelmente ainda não chegaram nessa barreira
  • A IDE já estava planejada há bastante tempo e, pelo que sei, é a prioridade máxima depois deste release
    Cart, o criador do Bevy, acredita que o Bevy deve ser Rust-first, e eu pessoalmente concordo. Isso não significa que não dê para criar plugins para várias linguagens de scripting, e de fato já existem alguns

• Sou o criador do Bevy e líder do projeto. Podem perguntar qualquer coisa

  • Estamos criando um app WASM relativamente grande para o porte da empresa usando Bevy, e a experiência com o motor tem sido muito boa
    O Bevy e a comunidade são excelentes. Precisávamos resolver alguns tickets e foi muito fácil encontrar um dos contribuidores principais, patrociná-lo e levar a solicitação até o fim. Um exemplo foi morph targets
    O Carter está construindo algo realmente importante e há um ótimo impulso por trás disso. O Bevy facilita muito o deploy para a web e mais gente deveria dar uma olhada. A comunidade também é boa e é fácil pedir ajuda
  • A documentação é limitada, o que desanima a entrada. O livro do Bevy pode ser lido em poucos minutos e, quando você trava, o material de consulta acaba rápido
    Quando a documentação vai melhorar? Pelas notas de release, o ideal seria haver várias páginas de documentação para cada recurso. Entendo que há muito trabalho e que a documentação completa talvez só seja possível depois de uma estabilização geral
  • Como desenvolvedor de jogos por hobby, se eu começasse um projeto novo, provavelmente usaria Bevy. Parece um bom meio-termo entre Love e Godot: mais robusto que Love, mas não tão voltado a iniciantes quanto Godot
    Até que ponto o Bevy é um motor opinionated? Tenho curiosidade se já foi preciso fazer concessões entre funcionalidades e acessibilidade para desenvolvedores
    Que tipo de projeto seria o mais ideal para o Bevy hoje?
  • Tenho curiosidade sobre as vantagens e desvantagens de escrever jogos com Rust e Bevy em comparação com outras linguagens. Em especial, queria ouvir sobre desempenho, segurança e velocidade de desenvolvimento
  • Quando poderemos ver recursos que permitam sistemas dinâmicos e scripting Bevy de primeira classe?
    Existem alguns plugins de scripting e parece que no momento o foco está principalmente em rhai, mas a sensação é que falta suporte adequado do Bevy, o que acaba travando tudo
    Seja o foco atual do Bevy jogos só em Rust ou não, existe demanda por scripting e já há gente correndo atrás de soluções de terceiros. Não espero scripting oficial do Bevy agora, mas acho que o Bevy precisa aceitar a base necessária para que crates de terceiros possam funcionar

• O texto diz que renderização diferida não suporta MSAA, mas isso só é verdade numa implementação ingênua
  Por exemplo, no pré-passe é possível criar uma máscara de stencil para pixels complexos e usar rejeição hierárquica antecipada de stencil para executar um passe por amostra nos pixels complexos e um passe por pixel nos demais. O aproveitamento das lanes SIMD não é perfeito
  Também dá para ter um passe que processe a máscara de pixels complexos e reúna um buffer de coordenadas (x, y, sample), permitindo depois aproveitamento perfeito das lanes SIMD em um único passe de compute shader híbrido por pixel/por amostra

  • Interessante. Já pensei nisso antes, mas supus que seria lento demais. Fico curioso se você conhece algum título lançado que use essa técnica

• Faz um tempo que estou fazendo um jogo com Bevy. Dá para ver o código e também fazer perguntas
  https://ant.care/
  https://github.com/MeoMix/symbiants
  Até agora, a principal dificuldade tem sido que o sistema de UI é verboso demais para criar widgets com conforto, então mudei para egui, mas acho que dentro de um ano devo voltar para o Bevy nativo. O egui também tem limitações grandes
  Não há muito suporte para relações de pai/filho, e a estrutura do ECS meio que desencoraja isso até certo ponto. Colar um rótulo em um sprite e fazer com que, ao mover/rotacionar o sprite, o rótulo acompanhe só a posição sem acompanhar a rotação foi mais difícil do que eu esperava
  A persistência de entidades entre sessões não tem suporte nativo. Entity serve para unicidade no lado do cliente, e recriar com facilidade relações pai/filho salvas também não acontece automaticamente
  Ainda não há suporte para paralelismo em WASM, mas a arquitetura do Bevy é claramente pensada para deixar a ordem dos sistemas flexível e assim ganhar desempenho com paralelização de tarefas
  Consultas espaciais parecem entrar em conflito com os objetivos do ECS. Quando você quer buscar por valor de Position, em vez de por tipo — isto é, se a entidade tem Position — acaba surgindo muito cache auxiliar que precisa ser sincronizado com o mecanismo de consultas
  Quando você altera o mundo com commands, as mudanças ficam adiadas para serem processadas em lote por questão de desempenho; se há muito comportamento adiado, fica difícil criar sistemas que modifiquem o mundo de forma ativa. Então você acaba chamando apply_deferred com frequência e usando comandos customizados para resolver condições de corrida
  O WASM no Android, especialmente na combinação Pixel 6 + Chrome, não funciona no momento, mas isso é um problema de dependência de nível inferior e deve ser corrigido no Bevy 13
  O lado bom é que a combinação de engine em Rust com jogo em Rust é muito boa de trabalhar, e Rust+WASM quase não passa a sensação de que a tecnologia está atrapalhando. Quando sua cabeça começa a pensar no estilo ECS, é difícil voltar atrás, e isso é muito flexível. Talvez flexível até demais
  A comunidade é ativa, então é fácil encontrar gente para discutir problemas, e embora não haja tanta documentação, há muitos exemplos. Também existe bastante otimismo em relação ao futuro, o ritmo de desenvolvimento é rápido e cada release avança bastante em várias preocupações principais

  • Só como observação, ant.care não funciona no iPhone. Testei tanto no Safari quanto no Firefox, e o site recarrega de novo em loop infinito depois de um tempo

• As notas de release são excelentes
  Para desenvolvedores experientes de jogos/engines, algumas partes podem parecer introdutórias demais, mas para quem não vive nesse mundo o tempo todo, o equilíbrio entre explicar as mudanças e contextualizar os temas ficou muito bom

• Vi a piada de que existem 5 jogos escritos em Rust, mas 50 engines de jogo em Rust
  Será que existe uma lista de jogos feitos com Bevy?

  • Bastante coisa
    Tiny Glade (https://pouncelight.games/tiny-glade) é bem popular e aparece muito nas redes sociais. Usa Bevy ECS / Bevy App e um renderizador customizado. https://store.steampowered.com/app/2198150/Tiny_Glade/
    tunnet (https://puzzled-squid.itch.io/tunnet), Noumenal (https://noumenal.app/) e Foresight Mining (https://www.foresightmining.com/) também existem. Foresight Mining é um software “CAD” de mineração e emprega vários desenvolvedores de Bevy
    Axie Infinity: Homeland (https://app.axieinfinity.com/games/homeland-alpha/) usa Bevy ECS e Unity. Shifting Chamber (https://maciekglowka.itch.io/shifting-chamber) e Hytopia (https://hytopia.com/) também
    Titleless Comfy City Builder (https://twitter.com/i_am_feenster/status/1710714877231186323), Molecoole (https://store.steampowered.com/app/1792170/Molecoole/) e Titleless industrial revolution builder (https://twitter.com/ElmoSampedro/status/1684920884811698176) também
    Jarl Game (https://twitter.com/jarl_game) é um jogo no estilo Dwarf Fortress com uma iluminação dinâmica muito bonita
    A tag “bevy” no itch.io tem centenas de jogos: https://itch.io/games/tag-bevy
    O canal #showcase no Discord do Bevy também é bem movimentado

• Todo framework começa prometendo implementar algo mais tradicional de forma simples, limpa e rápida, mas faltam recursos chamativos
  Aí vai correndo atrás dos recursos, vira o mesmo monstro complexo, e esse ciclo se repete

  • Faz sentido se você olhar o ciclo de vida de projetos de software de forma ampla, mas isso se aplica a praticamente qualquer afirmação sobre simplicidade ou facilidade de uso em software, então não parece uma crítica especialmente útil
    A conclusão soa como “todo software simples que adiciona recursos está condenado ao fracasso”, o que é um pouco dramático
    Fico curioso se há alguma ideia ou preocupação concreta sobre a arquitetura do Bevy ou sobre a forma como ele adiciona recursos. Estamos fazendo o máximo para evitar esse destino
  • Não discordo totalmente, mas o Bevy tem uma força que a maioria dos frameworks não tem: modularidade. Não é só um conceito, é uma modularidade que já provou funcionar bem na prática
    Tiny Glade usa bevy_ecs, mas não usa nada do crate de renderização do Bevy. Eu mesmo tenho alguns PRs em andamento para implementar caminhos de renderização alternativos, como ray tracing ou renderização GPU-driven com meshlets+visibility buffer, e quase nada dentro do Bevy precisa mudar
    Do ponto de vista do usuário, também quase nada muda. Você adiciona FeatureFooPlugin ao app e usa algo como FooComponent, e funciona
    Crates ou plugins individuais podem ficar inchados, mas o Bevy como um todo deve ficar bem. O usuário pode simplesmente ignorar esses plugins e usar outra coisa que se encaixe melhor no seu caso
    Além disso, isso é uma game engine. Por definição, é um monstro inchado e complexo, e vai absorvendo todo tipo de recurso porque pode ser útil para algum jogo. A questão central é como esse inchaço de recursos afeta a usabilidade. Se há 1000 recursos, mas você não precisa interagir com a maioria deles, então está tudo bem
  • Acho que a questão é se o projeto está disposto a manter a API simples, limpa e rápida rompendo com o passado quando necessário
    É verdade que isso é mais fácil em projetos novos, que não precisam se preocupar com compatibilidade retroativa. Pelo que vi do Bevy, há uma cultura forte de exigir uma boa experiência para o usuário e de reduzir a superfície da API. Talvez isso também seja efeito do empacotamento do Rust, mas vejo com bons olhos o fato de serem bem ativos em cortar com o passado para atingir esse objetivo
    O bom do cargo é que, mesmo que você decida depender do Bevy, não precisa ficar perseguindo um alvo móvel caso versões futuras quebrem compatibilidade. Você pode simplesmente ficar na sua versão. Ainda assim, eles também fornecem guias para facilitar a migração para a mais recente. Pelo menos essa foi minha experiência mexendo um pouco com o Bevy

• Ao atualizar da 0.10 para a 0.11, precisei fazer bastante mudança no app, mas desta vez compilou de primeira

• Bevy é uma das game engines de que mais gosto, especialmente para projetos grandes. O pré-processamento do Asset V2 e os arquivos .meta parecem muito úteis
  Também estou no aguardo do suporte a lightmaps em versões futuras

• Estava vendo os exemplos web e fui olhar a seção de UI, e parece que tudo é tratado dentro do canvas
  Dá para fazer a UI em DOM no lugar disso e conectá-la ao WASM?

  • Dá, e eu já vi isso sendo feito. Você só precisa criar uma forma de trocar informações entre a UI e o Bevy
    Do lado do Rust, ou seja, do WASM, há opções como web_sys, e do lado do JavaScript também dá para chamar funções do WASM, então há várias possibilidades