Bevy 0.12 - Engine game hướng dữ liệu được viết bằng Rust

 (bevyengine.org)
2 điểm bởi GN⁺ 2023-11-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trình kết xuất hỗ trợ Deferred Rendering tùy chọn, có thể chọn đường dẫn forward hoặc deferred theo từng material và đặt giá trị mặc định toàn cục bằng DefaultOpaqueRendererMethod
  • Các ứng dụng hoặc plugin Bevy hiện có cần kiểm tra quy trình migration qua 0.11 to 0.12 Migration Guide
  • Bevy Asset V2 hỗ trợ tiền xử lý asset, cấu hình dựa trên tệp .meta, nhiều AssetSource, sự kiện tải phụ thuộc đệ quy, asset I/O bất đồng bộ và các handle được cải tiến
  • Tiền xử lý asset được kích hoạt bằng AssetPlugin { mode: AssetMode::Processed } và tính năng Cargo bevy/asset_processor, nhưng hiện vẫn chưa được khuyến nghị cho phần lớn trường hợp sử dụng
  • Trên Android, ứng dụng không còn bị crash khi bị tạm dừng, sẽ dừng chạy hệ thống cho đến khi tiếp tục và cung cấp các sự kiện ApplicationLifetime::Suspended và ApplicationLifetime::Resumed
  • StandardMaterial được bổ sung specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance, hỗ trợ biểu diễn các vật liệu truyền sáng như kính, nước, nhựa, lá cây và giấy
  • Trình tải glTF hỗ trợ các phần mở rộng KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength, và có thể nhập bản đồ UV thứ hai là TEXCOORD1 hoặc UV1
  • Tự động batching/instancing cho draw command đã khả dụng, hiện có thể gom nhóm các entity có cùng material và mesh, và có thể loại trừ bằng component NoAutomaticBatching
  • Bóng đổ áp dụng PCF Shadow Filtering, hỗ trợ bóng mượt hơn cho DirectionalLight và SpotLight, với phương thức mặc định là ShadowMapFilter::Castano13
  • ECS bổ sung one-shot systems, cho phép đăng ký system rồi chạy khi cần bằng SystemId, nhưng không hỗ trợ exclusive system, system dùng cho system piping, tự gọi chính nó hoặc đánh giá song song
  • FixedTime đã bị loại bỏ và Time sẽ trả về giá trị phù hợp theo ngữ cảnh cả trong FixedUpdate, đồng thời ngăn hiện tượng “death spiral” khiến ứng dụng bị treo do FixedUpdate tích lũy quá mức
  • Trong AnimationPlayer, set_elapsed được thay bằng seek_to, stop_repeating được thay bằng set_repeat(RepeatAnimation::Never), và elapsed trả về thời gian thực đã trôi qua, không bị ảnh hưởng bởi tốc độ animation
  • Cú pháp import shader của Bevy đã chuyển sang kiểu Rust, hỗ trợ #import bevy_pbr::forward_io::VertexOutput, import nhiều mục bằng dấu ngoặc nhọn, import đường dẫn bộ phận và sử dụng đường dẫn định danh đầy đủ
  • UI có thể dùng shader material tùy chỉnh trên node UI thông qua UiMaterial, và hỗ trợ viền ngoài cho node không chiếm không gian layout bằng component Outline
  • Tích hợp accessibility bổ sung resource ManageAccessibilityUpdates, cho phép dừng tự động cập nhật cây accessibility của engine khi giá trị là false

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-05
Ý kiến trên Hacker News

  • So với các engine truyền thống như Unity hay Godot, Bevy có cách làm game hoàn toàn khác
    Không có UI hay scripting, mọi thứ đều xử lý bằng mã Rust nên gần với libGDX hay Cocos2D-x hơn. Tuy nhiên vì dùng ECS và Rust nên cách viết code cũng khác đi rất nhiều, tạo cảm giác như nó gần như ở trên một hòn đảo riêng
    Tôi muốn thấy một game indie thành công làm bằng Bevy, nhưng nhiều khả năng phần lớn nhà phát triển game sẽ thích các công cụ truyền thống mà họ đã học và xung quanh cũng đang dùng hơn. Giao điểm giữa những người muốn làm game và cũng thích Rust không lớn, và ngay cả trong nhóm đó, có vẻ nhiều người sẽ chọn công cụ đã có độ tin cậy và tài liệu tích lũy hơn là bỏ ra rất nhiều thời gian và công sức để học một engine mới mang tính thử nghiệm
    Cá nhân tôi nghĩ Bevy cần một IDE và ngôn ngữ scripting dựa trên Bevy và Rust. Điều đó sẽ không xóa bỏ rào cản phải đầu tư nhiều công sức cho dự án mới, nhưng có thể khiến nó thân thiện hơn nhiều với người dùng mới không có kinh nghiệm Rust và thấy ngại khi phải bắt đầu từ một bức tường code. Điều này trái ngược với cách của Unity hay Godot, nơi bạn có thể tạo một prototype rất cơ bản trên canvas chỉ trong vài giờ
    Tôi biết các nhà phát triển phản đối ngôn ngữ scripting, nhưng hot reload và debugging sâu hơn là cần thiết, và tôi nghĩ chỉ với Rust thì khó làm hiệu quả. Nhiều nhà phát triển game cũng có thể bị choáng ngợp bởi Rust và borrow checker. Dù vậy hiện tại tôi không có thời gian, tài nguyên hay ý chí để tự triển khai

    • Về mặt cấu trúc, Bevy không có nhiều tình huống phải trực tiếp đối đầu với borrow checker. Component và resource nhìn chung dùng kiểu sở hữu, và có thể xử lý qua Query và Ref mà không phải lo lắng nhiều
      Tôi đã thử Bevy một chút và kiểm tra repository thì thấy không có annotation lifetime nào
    • Trong phát triển game, việc tốn thời gian nhất thường là quản lý asset, sau đó mới đến lập trình. Một engine như Bevy cố giảm thời gian sửa lỗi, nhưng nếu thiếu asset pipeline thì phần tiết kiệm đó lại bị mất ở phía asset
      Ngôn ngữ scripting có thể giúp được phần nào, nhưng những người đang dùng Bevy hiện nay thường rất thiên về kỹ thuật và nhiều khi không phải designer toàn thời gian, nên có vẻ nhu cầu cấp thiết không quá lớn
      Tôi kỳ vọng ảnh hưởng của cộng đồng Rust đối với phát triển game và muốn đóng góp vào một ngày nào đó, nhưng hiện tại vì những lý do đã nêu, tôi vẫn định duy trì pipeline C++/C#. Tôi sẽ học Rust cho tử tế ở bên cạnh, và khi công cụ trưởng thành hơn thì có thể cân nhắc cho các dự án sau
      Hot reload thường là giải pháp tạm thời khi thời gian biên dịch trở nên khó chịu. Nếu trung bình khoảng 4 giây, biên dịch lại toàn bộ khoảng 20 giây, thì nhu cầu bỏ nhiều tài nguyên vào các cách tránh biên dịch toàn bộ sẽ giảm đi
      Tuy nhiên tôi nghe nói Rust nhìn chung có thời gian biên dịch dài hơn, nên nhu cầu scripting hoặc hot reload có thể đến sớm hơn dự đoán. Dù vậy các dự án indie đang thực hiện hiện nay có lẽ vẫn chưa chạm tới rào cản đó
    • IDE đã nằm trong kế hoạch từ khá lâu, và tôi được biết đó là ưu tiên hàng đầu sau bản phát hành này
      Cart, người sáng lập Bevy, cho rằng Bevy nên ưu tiên Rust, và cá nhân tôi cũng đồng ý. Điều đó không có nghĩa là không thể tạo plugin cho nhiều ngôn ngữ scripting; thực tế đã có vài plugin như vậy

  • Tôi là người sáng lập Bevy và là trưởng dự án. Có thể hỏi tôi bất cứ điều gì

    • Chúng tôi đang làm một ứng dụng WASM khá lớn so với quy mô công ty bằng Bevy, và trải nghiệm dùng engine này rất tốt
      Bevy và cộng đồng của nó rất tuyệt. Chúng tôi cần xử lý một số ticket, và việc tìm một trong các contributor cốt lõi để tài trợ rồi thúc đẩy yêu cầu đến cùng là rất dễ. Ví dụ như morph target là một trường hợp như vậy
      Carter đang tạo ra một thứ thực sự quan trọng, và đằng sau nó có động lực phát triển rất tốt. Bevy triển khai lên web rất dễ, và đáng để nhiều người xem xét hơn. Cộng đồng cũng tốt và dễ tìm sự giúp đỡ
    • Tài liệu còn hạn chế nên tôi ngại bắt đầu. Bevy Book có thể đọc hết chỉ trong vài phút, và khi bị kẹt thì rất nhanh hết tài liệu để tham khảo
      Khi nào tài liệu sẽ được cải thiện? Nhìn vào release note, lý tưởng là mỗi tính năng nên có vài trang tài liệu. Tôi hiểu là có rất nhiều việc, và có thể tài liệu đầy đủ chỉ khả thi sau khi ổn định hơn
    • Với tư cách một lập trình viên game theo sở thích, nếu bắt đầu một dự án mới thì có lẽ tôi sẽ dùng Bevy. Nó có cảm giác chia khá tốt ở khoảng giữa Love và Godot: vững chắc hơn Love, nhưng không hướng đến người mới bắt đầu nhiều như Godot
      Bevy là một engine mang tính định hướng/opinionated đến mức nào? Tôi tò mò liệu đã từng có lúc phải đánh đổi giữa tính năng và khả năng tiếp cận với nhà phát triển chưa
      Hiện tại loại dự án lý tưởng nhất cho Bevy là gì?
    • Tôi tò mò khi viết game bằng Rust và Bevy thì có ưu nhược điểm gì so với các ngôn ngữ khác, đặc biệt về hiệu năng, an toàn và tốc độ phát triển
    • Khi nào chúng ta có thể thấy các tính năng cho phép hệ thống động và scripting Bevy hạng nhất?
      Có một số plugin scripting và hiện có vẻ chủ yếu tập trung vào rhai, nhưng cảm giác như đang bị chặn vì thiếu hỗ trợ Bevy phù hợp
      Dù trọng tâm hiện tại của Bevy có phải là game chỉ dùng Rust hay không, nhu cầu scripting vẫn tồn tại, và đã có những người bận rộn tìm giải pháp bên thứ ba. Tôi không kỳ vọng scripting Bevy chính thức ngay lập tức, nhưng tôi nghĩ Bevy nên chấp nhận nền tảng để các crate bên thứ ba có thể hoạt động

  • Bài viết nói rằng deferred rendering không hỗ trợ MSAA, nhưng điều đó chỉ đúng với cách triển khai ngây thơ
    Ví dụ, trong pre-pass có thể tạo stencil mask cho các pixel phức tạp, rồi dùng hierarchical early stencil rejection để chạy pass theo từng sample cho pixel phức tạp và pass theo từng pixel cho các pixel còn lại. Việc tận dụng SIMD lane sẽ không hoàn hảo
    Ngoài ra, nếu có một pass xử lý mask của pixel phức tạp và thu thập buffer tọa độ (x, y, sample), thì trong pass compute shader lai theo từng pixel/từng sample sau đó, cũng có thể tận dụng SIMD lane hoàn hảo

    • Thú vị thật. Trước đây tôi từng nghĩ đến điều này nhưng giả định nó sẽ quá chậm. Tôi tò mò không biết có tựa game đã phát hành nào dùng kỹ thuật đó không

  • Tôi đã làm game bằng Bevy được một thời gian. Có thể xem mã nguồn và cũng có thể đặt câu hỏi
    https://ant.care/
    https://github.com/MeoMix/symbiants
    Những khó khăn cho đến nay là hệ thống UI quá dài dòng để tạo widget một cách thoải mái nên tôi đã chuyển sang egui, nhưng có lẽ trong vòng 1 năm nữa tôi sẽ quay lại Bevy native. egui cũng có những hạn chế lớn
    Hỗ trợ quan hệ cha/con không nhiều, và ECS có cấu trúc phần nào không khuyến khích điều đó. Việc gắn nhãn cho sprite, rồi khi di chuyển/xoay sprite thì nhãn chỉ đi theo vị trí mà không xoay theo, khó hơn dự kiến
    Không có hỗ trợ mặc định cho việc duy trì entity qua các phiên. Entity dùng cho tính duy nhất phía client, và việc dễ dàng tái tạo lại các quan hệ cha/con đã lưu cũng không tự động
    Hiện vẫn chưa hỗ trợ tính song song WASM, nhưng kiến trúc Bevy được thiết kế khá nhiều để giữ thứ tự hệ thống linh hoạt nhằm đạt lợi ích hiệu năng thông qua song song hóa tác vụ
    Truy vấn không gian có cảm giác xung đột với mục tiêu của ECS. Khi muốn tìm theo giá trị Position thay vì theo kiểu, tức là entity có Position hay không, sẽ phát sinh nhiều cache phụ cần đồng bộ với engine truy vấn
    Khi thay đổi world bằng commands, thay đổi sẽ bị trì hoãn để được xử lý theo lô vì hiệu năng; nhưng nếu có nhiều hành vi trì hoãn thì khó tạo các system chủ động thay đổi world. Vì vậy tôi thường phải gọi apply_deferred, và dùng lệnh tùy chỉnh để giải quyết race condition
    WASM trên Android, đặc biệt tổ hợp Pixel 6 và Chrome, hiện không hoạt động, nhưng đây là vấn đề ở dependency bên dưới nên dự kiến sẽ được sửa trong Bevy 13
    Ưu điểm là tổ hợp engine Rust và game Rust rất dễ làm việc, và Rust+WASM cũng hầu như không có cảm giác bị công nghệ cản trở. Khi đầu óc bắt đầu nghĩ theo kiểu ECS thì rất khó quay lại, và nó cực kỳ linh hoạt. Có lẽ thậm chí là quá linh hoạt
    Cộng đồng sôi nổi nên dễ tìm người để trao đổi vấn đề; tài liệu không nhiều nhưng ví dụ thì nhiều. Mức độ lạc quan về tương lai cũng lớn, tốc độ phát triển nhanh và mỗi bản phát hành đều cải thiện đáng kể các mối lo chính

    • Nhân tiện, ant.care không chạy trên iPhone. Tôi đã thử trên cả Safari và Firefox, nhưng website tải lại sau một lúc trong một vòng lặp vô hạn

  • Ghi chú phát hành rất tuyệt
    Với các nhà phát triển game/engine có kinh nghiệm, một số phần có thể quá nhập môn, nhưng với người không thường xuyên ở trong thế giới đó thì sự cân bằng giữa giải thích thay đổi và diễn giải chủ đề là rất tốt

  • Tôi từng thấy câu đùa rằng game viết bằng Rust thì có 5 cái, còn game engine thì có 50 cái
    Thực sự có danh sách các game được viết bằng Bevy không?

  • Mọi framework ban đầu đều muốn triển khai một thứ gì đó truyền thống hơn theo cách đơn giản, gọn gàng và nhanh, nhưng lại thiếu các tính năng hào nhoáng.
    Rồi khi bắt kịp về tính năng, chúng lại trở thành những con quái vật phức tạp y như vậy, và vòng lặp đó tiếp diễn.

    • Nhìn rộng theo vòng đời của một dự án phần mềm thì điều này có lý, nhưng nó có thể áp dụng y nguyên cho bất kỳ tuyên bố nào về sự đơn giản hay dễ dùng của phần mềm, nên tôi không thấy đây là một phê bình đặc biệt hữu ích.
      Kết luận nghe như “mọi phần mềm dễ dùng mà thêm tính năng đều được định sẵn là sẽ hỏng”, hơi kịch tính.
      Tôi tò mò liệu có suy nghĩ hay lo ngại cụ thể nào về kiến trúc của Bevy hoặc cách nó thêm tính năng không. Chúng tôi đang cố hết sức để tránh số phận đó.
    • Không phải là tôi không đồng ý, nhưng Bevy có một điểm mạnh mà hầu hết framework không có: tính mô-đun. Không chỉ là khái niệm, mà là tính mô-đun đã được chứng minh là hoạt động tốt trong thực tế.
      Tiny Glade dùng bevy_ecs nhưng hoàn toàn không dùng crate render của Bevy. Cá nhân tôi cũng đang có vài PR về việc triển khai các đường render thay thế, chẳng hạn ray tracing hoặc render meshlet do GPU điều khiển + visibility buffer, mà nội bộ Bevy gần như không thay đổi.
      Với người dùng thì cũng không khác mấy. Thêm FeatureFooPlugin vào app và dùng những thứ như FooComponent là chạy.
      Từng crate hay plugin riêng lẻ có thể phình to, nhưng tổng thể Bevy sẽ ổn. Người dùng có thể bỏ qua các plugin đó và dùng thứ khác phù hợp với mình hơn.
      Ngoài ra đây là một game engine. Theo định nghĩa, nó là một con quái vật phình to và phức tạp, và vì có thể hữu ích cho một số game nào đó nên nó sẽ hấp thụ đủ loại tính năng. Điều cốt lõi là việc phình tính năng ảnh hưởng thế nào đến khả năng sử dụng. Dù có 1000 tính năng, nếu bạn không cần tương tác với phần lớn trong số đó thì hoàn toàn không sao.
    • Tôi nghĩ điểm mấu chốt là dự án có sẵn sàng đoạn tuyệt với quá khứ để giữ API đơn giản, gọn gàng và nhanh hay không.
      Đúng là các dự án mới không cần bận tâm đến tương thích ngược thì dễ hơn. Bevy mà tôi thấy có văn hóa mạnh về việc đòi hỏi trải nghiệm tốt cho người dùng và giảm bề mặt API. Có thể là nhờ hệ thống đóng gói của Rust, nhưng tôi đánh giá cao việc họ khá chủ động cắt đứt với quá khứ vì mục tiêu này.
      Điểm hay của cargo là dù bạn quyết định phụ thuộc vào Bevy, ngay cả khi phiên bản tương lai gây breaking change, bạn cũng không cần phải chạy theo một mục tiêu luôn di động. Chỉ cần ở lại phiên bản của mình là được. Dù vậy họ cũng cung cấp hướng dẫn để giúp chuyển lên bản mới dễ hơn. Ít nhất đó là trải nghiệm của tôi sau khi dùng thử Bevy một chút.

  • Khi nâng từ 0.10 lên 0.11, app của tôi cần khá nhiều thay đổi, nhưng lần này thì compile ngay lập tức.

  • Bevy là một trong những game engine tôi thích, đặc biệt cho các dự án lớn. Tiền xử lý Asset V2 và các file .meta trông rất hữu ích.
    Tôi cũng mong chờ hỗ trợ lightmap trong các bản phát hành sắp tới.

  • Khi xem các ví dụ web, tôi nhìn qua phần UI và có vẻ như tất cả đều được xử lý bên trong canvas.
    Có thể thay vào đó tạo UI bằng DOM rồi nối với WASM không?

    • Có thể, và tôi từng thấy trường hợp thực sự làm như vậy. Bạn cần tạo một cách để trao đổi thông tin giữa UI và Bevy.
      Ở phía Rust, tức WASM, có các cách như web_sys; còn ở phía JavaScript cũng có cách gọi các hàm WASM, nên có khá nhiều lựa chọn.