Bevy 0.12 - Mesin game berbasis data yang dibuat dengan Rust

• Renderer kini mendukung Deferred Rendering secara opsional, dengan pilihan jalur forward atau deferred per material, dan nilai bawaan global dapat diatur melalui DefaultOpaqueRendererMethod
• Aplikasi atau plugin Bevy yang sudah ada perlu memeriksa prosedur migrasi melalui 0.11 to 0.12 Migration Guide
• Bevy Asset V2 mendukung prapemrosesan aset, konfigurasi berbasis file .meta, beberapa AssetSource, event pemuatan dependensi rekursif, I/O aset asinkron, dan handle yang ditingkatkan
• Prapemrosesan aset diaktifkan dengan AssetPlugin { mode: AssetMode::Processed } dan fitur Cargo bevy/asset_processor, tetapi saat ini masih belum direkomendasikan untuk sebagian besar kasus penggunaan
• Di Android, aplikasi tidak lagi crash saat ditangguhkan, menghentikan eksekusi sistem hingga dilanjutkan kembali, dan menyediakan event ApplicationLifetime::Suspended serta ApplicationLifetime::Resumed
• Pada StandardMaterial, ditambahkan specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance untuk mendukung ekspresi material tembus cahaya seperti kaca, air, plastik, daun, dan kertas
• Loader glTF kini mendukung ekstensi KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength, dan dapat mengimpor peta UV kedua TEXCOORD1 atau UV1
• Batching/instancing otomatis untuk draw command kini dimungkinkan, dan entitas dengan material serta mesh yang sama saat ini bisa dibatch; pengecualian dapat dilakukan dengan komponen NoAutomaticBatching
• Bayangan memperkenalkan PCF Shadow Filtering untuk mendukung bayangan yang lebih halus pada DirectionalLight dan SpotLight, dengan metode bawaan ShadowMapFilter::Castano13
• One-shot systems ditambahkan ke ECS, sehingga sistem dapat didaftarkan lalu dijalankan saat diperlukan dengan SystemId, tetapi tidak mendukung exclusive system, system untuk system piping, pemanggilan dirinya sendiri, atau evaluasi paralel
• FixedTime dihapus, dan Time kini mengembalikan nilai yang sesuai konteks juga di FixedUpdate, sekaligus mencegah “death spiral” saat FixedUpdate menumpuk berlebihan hingga aplikasi macet
• Di AnimationPlayer, set_elapsed diganti menjadi seek_to, stop_repeating diganti menjadi set_repeat(RepeatAnimation::Never), dan elapsed kini mengembalikan waktu berlalu aktual yang tidak dipengaruhi kecepatan animasi
• Import shader Bevy diubah ke sintaks bergaya Rust, mendukung #import bevy_pbr::forward_io::VertexOutput, multiple import dengan kurung kurawal, import jalur parsial, dan penggunaan jalur yang dituliskan lengkap
• UI kini dapat menggunakan shader material kustom pada node UI melalui UiMaterial, dan mendukung outline node yang tidak memakan ruang layout melalui komponen Outline
• Integrasi aksesibilitas menambahkan resource ManageAccessibilityUpdates, yang dapat menghentikan pembaruan otomatis pohon aksesibilitas oleh engine saat nilainya false

[GN⁺]

Opini Hacker News

• Dibandingkan dengan engine tradisional seperti Unity atau Godot, Bevy memiliki cara membuat game yang benar-benar berbeda
  Tanpa UI atau scripting, semuanya ditangani dengan kode Rust, sehingga lebih dekat ke libGDX atau Cocos2D-x. Namun karena memakai ECS dan Rust, cara menulis kodenya juga sangat berbeda, jadi rasanya seperti berada di pulau tersendiri
  Saya ingin melihat game indie yang sukses dibuat dengan Bevy, tetapi kebanyakan developer game kemungkinan lebih memilih alat tradisional yang sudah mereka pelajari dan juga dipakai orang-orang di sekitar mereka. Irisan antara orang yang ingin membuat game dan juga menyukai Rust tidak besar, dan bahkan di dalam kelompok itu, tampaknya banyak yang akan memilih alat yang sudah tepercaya dan punya banyak materi ketimbang menghabiskan banyak waktu dan tenaga untuk mempelajari engine baru yang masih eksperimental
  Secara pribadi, saya rasa Bevy membutuhkan IDE dan bahasa scripting berbasis Bevy dan Rust. Hambatan berupa perlunya usaha besar untuk memulai proyek baru memang tidak akan hilang, tetapi ini bisa membuatnya jauh lebih ramah bagi pengguna baru yang belum berpengalaman dengan Rust dan merasa terbebani jika harus memulai dari dinding kode. Ini kontras dengan cara kerja Unity atau Godot, yang memungkinkan membuat prototipe sangat dasar di kanvas dalam hitungan jam
  Saya tahu developernya menentang bahasa scripting, tetapi hot reload dan debugging yang lebih mendalam tetap dibutuhkan, dan menurut saya sulit melakukannya secara efektif hanya dengan Rust. Banyak developer game juga bisa kewalahan menghadapi Rust dan borrow checker. Namun saat ini tidak ada waktu, sumber daya, atau kemauan untuk mengimplementasikannya sendiri

  • Secara struktur, Bevy tidak sering membuat kita berhadapan langsung dengan borrow checker. Komponen dan resource umumnya memakai tipe yang dimiliki, dan bisa ditangani lewat Query dan Ref tanpa banyak kekhawatiran
    Saya sempat mencoba Bevy sedikit dan mengecek repositorinya; jumlah anotasi lifetime-nya 0
  • Dalam pengembangan game, yang paling banyak memakan waktu biasanya manajemen aset, lalu setelah itu pemrograman. Engine seperti Bevy berusaha mengurangi waktu perbaikan bug, tetapi jika pipeline aset-nya kurang, penghematan itu akan hilang di sisi aset
    Bahasa scripting mungkin sedikit membantu, tetapi orang-orang yang saat ini memakai Bevy cenderung sangat teknis dan sering kali bukan desainer penuh waktu, jadi permintaan yang mendesak tampaknya tidak terlalu besar
    Saya menantikan dampak komunitas Rust terhadap pengembangan game dan ingin berkontribusi suatu hari nanti, tetapi untuk sekarang saya berniat mempertahankan pipeline C++/C# karena alasan-alasan yang disebutkan. Rust akan saya pelajari dengan benar di samping, dan jika alatnya sudah matang, saya bisa mempertimbangkannya untuk proyek berikutnya
    Hot reload sering kali merupakan solusi sementara ketika waktu kompilasi mulai sulit ditanggung. Jika rata-ratanya sekitar 4 detik dan recompilation penuh sekitar 20 detik, kebutuhan untuk mencurahkan banyak sumber daya demi menghindari kompilasi penuh menjadi berkurang
    Namun saya dengar waktu kompilasi Rust secara umum lebih lama, jadi kebutuhan scripting atau hot reload bisa muncul lebih cepat dari perkiraan. Meski begitu, proyek-proyek indie yang sedang berjalan saat ini kemungkinan belum akan menyentuh hambatan itu
  • IDE sudah direncanakan sejak cukup lama, dan setahu saya menjadi prioritas utama setelah rilis ini
    Cart, pencipta Bevy, berpendapat bahwa Bevy harus mengutamakan Rust, dan secara pribadi saya setuju. Namun itu bukan berarti tidak bisa dibuat plugin untuk berbagai bahasa scripting; faktanya, sudah ada beberapa

• Saya pencipta Bevy sekaligus project lead. Silakan tanya apa saja

  • Kami sedang membuat aplikasi WASM yang cukup besar dibandingkan ukuran perusahaan dengan Bevy, dan pengalaman memakai engine-nya sangat baik
    Bevy dan komunitasnya luar biasa. Ada beberapa tiket yang perlu dikerjakan, dan sangat mudah menemukan salah satu kontributor inti, mensponsorinya, lalu mendorong permintaan itu sampai selesai. Contohnya morph target
    Carter sedang membangun sesuatu yang benar-benar penting, dan ada momentum yang bagus di belakangnya. Deploy Bevy ke web sangat mudah, dan lebih banyak orang patut melihatnya. Komunitasnya juga baik dan mudah meminta bantuan
  • Saya enggan masuk karena dokumentasinya terbatas. Buku Bevy bisa dibaca habis dalam beberapa menit, dan saat buntu, materi rujukan cepat habis
    Kapan dokumentasinya akan diperbaiki? Melihat catatan rilis, idealnya tiap fitur punya dokumentasi beberapa halaman. Saya paham itu pekerjaan besar, dan dokumentasi lengkap mungkin baru memungkinkan setelah stabilisasi
  • Sebagai developer game hobi, kalau memulai proyek baru, saya rasa saya akan memakai Bevy. Rasanya membagi posisi di tengah antara Love dan Godot dengan baik; lebih kokoh daripada Love, tetapi tidak seberorientasi pemula seperti Godot
    Seberapa opinionated Bevy sebagai engine? Saya penasaran apakah pernah harus berkompromi antara fitur dan aksesibilitas developer
    Proyek seperti apa yang paling ideal untuk Bevy saat ini?
  • Saya penasaran apa kelebihan dan kekurangan menulis game dengan Rust dan Bevy dibandingkan bahasa lain. Terutama dari sisi performa, keamanan, dan kecepatan pengembangan
  • Kapan kita bisa melihat fitur-fitur yang memungkinkan sistem dinamis dan scripting Bevy kelas satu?
    Ada beberapa plugin scripting, dan saat ini tampaknya fokusnya terutama pada rhai, tetapi rasanya terhambat karena kurangnya dukungan Bevy yang memadai
    Terlepas dari apakah fokus Bevy saat ini adalah game khusus Rust atau bukan, kebutuhan scripting tetap ada, dan sudah ada orang-orang yang sibuk mencari solusi pihak ketiga. Saya tidak berharap scripting resmi Bevy dalam waktu dekat, tetapi menurut saya Bevy perlu menerima fondasi agar crate pihak ketiga bisa bekerja

• Artikel tersebut mengatakan deferred rendering tidak mendukung MSAA, tetapi itu hanya benar untuk implementasi yang naif
  Misalnya, pada pre-pass kita bisa membuat stencil mask untuk piksel kompleks, lalu memakai hierarchical early stencil rejection untuk menjalankan pass per-sampel pada piksel kompleks dan pass per-piksel pada piksel lain. Pemanfaatan lane SIMD memang tidak sempurna
  Selain itu, jika ada pass yang memproses mask piksel kompleks dan mengumpulkan buffer koordinat (x, y, sample), maka pemanfaatan lane SIMD yang sempurna juga bisa dicapai kemudian dalam satu pass compute shader hibrida per-piksel/per-sampel

  • Menarik. Dulu saya pernah memikirkan ini, tetapi berasumsi akan terlalu lambat. Saya penasaran apakah Anda tahu judul yang dirilis dengan teknik itu

• Saya sudah cukup lama membuat game dengan Bevy. Kodenya juga bisa dilihat, dan boleh bertanya
  https://ant.care/
  https://github.com/MeoMix/symbiants
  Kesulitan sejauh ini adalah sistem UI-nya terlalu bertele-tele untuk membuat widget dengan nyaman, jadi saya beralih ke egui, tetapi sepertinya dalam setahun saya akan kembali ke Bevy native. egui juga punya batasan besar
  Dukungan relasi parent/child tidak banyak, dan ECS sampai batas tertentu punya struktur yang cenderung menghindarinya. Memberi label pada sprite, lalu saat sprite digeser/diputar membuat label hanya mengikuti posisi tanpa ikut berputar ternyata lebih sulit dari perkiraan
  Persistensi entity antar-sesi tidak didukung secara bawaan. Entity ditujukan untuk keunikan di sisi klien, dan membuat ulang relasi parent/child yang tersimpan dengan mudah juga tidak otomatis
  Belum ada dukungan paralelisme WASM, tetapi arsitektur Bevy banyak dirancang agar urutan sistem tetap fleksibel untuk mendapat keuntungan performa lewat paralelisasi pekerjaan
  Spatial query terasa bertabrakan dengan tujuan ECS. Ketika ingin mencari berdasarkan nilai Position, bukan berdasarkan tipe—yakni apakah entity memiliki Position—muncul banyak cache bantu yang harus disinkronkan dengan query engine
  Jika mengubah world dengan commands, perubahan itu ditunda agar bisa diproses secara batch demi performa. Namun jika banyak perilaku yang ditunda, sulit membuat sistem yang secara aktif mengubah world. Karena itu saya jadi sering memanggil apply_deferred, dan menggunakan command kustom untuk menyelesaikan race condition
  WASM di Android, khususnya kombinasi Pixel 6 dan Chrome, saat ini tidak berjalan, tetapi karena ini masalah dependensi turunan, rencananya akan diperbaiki di Bevy 13
  Kelebihannya adalah kombinasi engine Rust dan game Rust sangat enak dikerjakan, dan Rust+WASM juga hampir tidak terasa teknologinya menjadi penghambat. Begitu kepala mulai berpikir dengan gaya ECS, sulit untuk kembali, dan ini sangat fleksibel. Mungkin bahkan terlalu fleksibel
  Komunitasnya aktif sehingga mudah menemukan orang untuk diajak membahas masalah. Dokumentasinya tidak banyak, tetapi contohnya banyak. Optimisme terhadap masa depannya juga besar; laju pengembangannya cepat dan setiap rilis membuat kemajuan berarti pada kekhawatiran utama

  • Sebagai catatan, ant.care tidak berjalan di iPhone. Saya mengujinya di Safari dan Firefox; situs webnya dimuat ulang ke infinite loop setelah beberapa saat

• Catatan rilisnya sangat bagus
  Bagi developer game/engine berpengalaman, sebagian mungkin terlalu pemula, tetapi bagi orang yang tidak selalu berada di dunia itu, keseimbangan antara penjelasan perubahan dan uraian topiknya sangat baik

• Saya pernah melihat lelucon bahwa ada 5 game yang ditulis dengan Rust, tetapi ada 50 game engine
  Sebenarnya, apakah ada daftar game yang ditulis dengan Bevy?

  • Cukup banyak
    Tiny Glade (https://pouncelight.games/tiny-glade) sangat populer dan banyak terekspos di media sosial. Menggunakan Bevy ECS / Bevy App dan renderer kustom. https://store.steampowered.com/app/2198150/Tiny_Glade/
    Ada juga tunnet (https://puzzled-squid.itch.io/tunnet), Noumenal (https://noumenal.app/), dan Foresight Mining (https://www.foresightmining.com/). Foresight Mining adalah software “CAD” untuk penambangan dan mempekerjakan beberapa developer Bevy
    Axie Infinity: Homeland (https://app.axieinfinity.com/games/homeland-alpha/) menggunakan Bevy ECS dan Unity. Ada juga Shifting Chamber (https://maciekglowka.itch.io/shifting-chamber) dan Hytopia (https://hytopia.com/)
    Ada juga Titleless Comfy City Builder (https://twitter.com/i_am_feenster/status/1710714877231186323), Molecoole (https://store.steampowered.com/app/1792170/Molecoole/), dan Titleless industrial revolution builder (https://twitter.com/ElmoSampedro/status/1684920884811698176)
    Jarl Game (https://twitter.com/jarl_game) adalah game bergaya Dwarf Fortress dengan pencahayaan dinamis yang keren
    Ada ratusan game dengan tag “bevy” di itch.io: https://itch.io/games/tag-bevy
    Kanal #showcase di Discord Bevy juga sangat aktif

• Semua framework awalnya ingin mengimplementasikan sesuatu yang lebih konvensional dengan sederhana, rapi, dan cepat, tetapi biasanya kekurangan fitur-fitur mewah.
  Lalu, ketika mulai mengejar fitur, ia menjadi monster yang sama rumitnya, dan siklus itu berulang.

  • Secara garis besar, itu masuk akal untuk siklus hidup proyek perangkat lunak, tetapi karena bisa diterapkan begitu saja pada klaim apa pun tentang kesederhanaan atau kemudahan penggunaan perangkat lunak, menurut saya itu tidak terlihat sebagai kritik yang terlalu berguna.
    Kesimpulannya terdengar seperti “semua perangkat lunak yang mudah digunakan dan menambahkan fitur memang ditakdirkan gagal”, yang agak dramatis.
    Saya penasaran apakah ada pemikiran atau kekhawatiran spesifik tentang arsitektur Bevy atau cara penambahan fiturnya. Kami berusaha sebaik mungkin untuk menghindari nasib seperti itu.
  • Saya tidak sepenuhnya tidak setuju, tetapi Bevy punya keunggulan yang tidak dimiliki kebanyakan framework: modularitas. Bukan hanya konsep, melainkan modularitas yang terbukti benar-benar bekerja dengan baik.
    Tiny Glade memakai bevy_ecs, tetapi sama sekali tidak memakai crate rendering Bevy. Secara pribadi, saya juga punya beberapa PR yang sedang dikerjakan untuk mengimplementasikan jalur rendering alternatif, misalnya ray tracing atau rendering meshlet berbasis GPU + visibility buffer, dan bagian internal Bevy hampir tidak berubah.
    Dari sisi pengguna pun tidak banyak yang berubah. Tambahkan FeatureFooPlugin ke aplikasi dan gunakan sesuatu seperti FooComponent, maka semuanya berjalan.
    Crate atau plugin individual bisa saja membengkak, tetapi Bevy secara keseluruhan akan baik-baik saja. Pengguna bisa mengabaikan plugin semacam itu dan memakai hal lain yang lebih cocok untuk mereka.
    Selain itu, ini adalah game engine. Secara definisi, ia adalah monster yang bengkak dan rumit, dan karena bisa berguna untuk suatu game tertentu, ia akan menyerap segala macam fitur. Intinya adalah bagaimana pembengkakan fitur memengaruhi kegunaan. Kalau ada 1000 fitur tetapi Anda tidak perlu berinteraksi dengan sebagian besar di antaranya, itu sama sekali tidak masalah.
  • Menurut saya kuncinya adalah apakah proyek tersebut punya kemauan untuk memutus hubungan dengan masa lalu demi menjaga API tetap sederhana, rapi, dan cepat.
    Memang benar bahwa ini lebih mudah untuk proyek baru yang tidak perlu memikirkan kompatibilitas mundur. Dari yang saya lihat, Bevy punya budaya yang kuat untuk menuntut pengalaman penggunaan yang baik bagi pengguna dan mengurangi permukaan API. Mungkin ini berkat packaging Rust, tetapi saya memandang positif karena mereka cukup aktif memutus kompatibilitas lama demi tujuan itu.
    Hal bagus dari cargo adalah, meskipun Anda memutuskan bergantung pada Bevy, Anda tidak perlu mengejar target yang terus bergerak ketika versi masa depan melakukan breaking change. Cukup tetap di versi Anda sendiri. Meski begitu, mereka juga menyediakan panduan agar mudah pindah ke versi terbaru. Setidaknya begitulah pengalaman saya setelah sedikit mencoba Bevy.

• Saat naik dari 0.10 ke 0.11, aplikasi saya perlu cukup banyak perubahan, tetapi kali ini langsung berhasil dikompilasi.

• Bevy adalah salah satu game engine yang saya sukai, terutama untuk proyek besar. Prapemrosesan Asset V2 dan file .meta terlihat sangat berguna.
  Saya juga menantikan dukungan lightmap di rilis mendatang.

• Saat melihat contoh web, saya melihat bagian UI, dan tampaknya semuanya ditangani di dalam canvas.
  Apakah mungkin membuat UI dengan DOM sebagai gantinya lalu menghubungkannya ke WASM?

  • Bisa, dan saya pernah melihat kasus yang benar-benar melakukannya. Anda perlu membuat cara untuk mengirim dan menerima informasi antara UI dan Bevy.
    Di sisi Rust, yaitu WASM, ada cara seperti web_sys, dan di sisi JavaScript juga ada cara untuk memanggil fungsi WASM, jadi pilihannya cukup banyak.