Trình biên tập game phong cách Unity chạy trên WASM thuần

 (raverie-us.github.io)
2 điểm bởi GN⁺ 2023-09-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một game engine nhẹ hướng đến việc tái hiện trải nghiệm của Macromedia/Adobe Flash trước đây
  • Được thiết kế để hoạt động trên mọi nền tảng, với đích xuất duy nhất là WASM thuần
  • Sản phẩm đầu ra không bao gồm file thực thi hay glue code, v.v.; không dùng Emscripten
  • Danh sách import và export được định nghĩa rõ ràng trong PlatformCommunication.hpp
  • Cấu trúc dễ triển khai trên bất kỳ nền tảng nào, bao gồm cả trình duyệt

Tổng quan

  • Là một game engine nhẹ (light-weight), hướng đến việc tái hiện trải nghiệm của Macromedia/Adobe Flash trước đây

Kiến trúc

  • Được xây dựng để chạy trên mọi nền tảng, với mục tiêu đích xuất duy nhất là WASM thuần
  • Sản phẩm đầu ra không bao gồm file thực thi, glue code, v.v.; không sử dụng Emscripten
  • Danh sách import và export được định nghĩa gọn gàng trong PlatformCommunication.hpp, nên có thể triển khai dễ dàng trên bất kỳ nền tảng nào, bao gồm cả trình duyệt

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-27
Ý kiến trên Hacker News

  • Wow, đây là những người đã tạo ra Zero Engine phải không? Tôi từng dùng nó ở trại hè DigiPen từ rất lâu rồi, và lập trình bằng Zilch thật sự rất vui
    Tôi còn làm cả một AI chơi bản clone Galaga. Vì vụ Unity lần này, tôi đã tự hỏi Zero giờ ra sao, nên rất háo hức khi có vẻ nó sẽ hồi sinh

    • Hay quá! Zilch là thứ tôi đã nâng niu tạo ra, nên nghe bạn nói vậy tôi thật sự rất vui :D

  • Nhân tiện bổ sung một chút: trên một laptop cấu hình thấp rõ rệt có đồ họa tích hợp, nó chạy như một slideshow tuyệt đẹp khác
    Tôi cũng thử trên chiếc Mate 20 Pro cũ, và nó trông như bị kẹt ở “Downloading runtime”. Có vẻ không phải do 4G chập chờn, nên tôi cắm USB vào laptop, mở chrome://inspect để kiểm tra tab thì thấy lỗi Uncaught (in promise) Error: Needs OES_texture_float_linear to function. Dù sao thì việc có đáng làm một màn hình lỗi chỉ để báo rằng bạn không thể nghịch nó hay không lại là một câu hỏi mang tính triết học

  • Tôi thích ý tưởng này. Nhưng GPU và trình duyệt của tôi đang khóc vì độ trễ, và nó trông như một slideshow ấn tượng
    Sau vài lần thử, cuối cùng tôi mới chọn được quả cầu khởi đầu. Ban đầu tôi còn không chắc nó đã tải xong chưa. Tất nhiên tôi đang dùng Firefox trên Celeron 1.8GHz, GPU tích hợp, RAM 8GB, nên còn xa mới gọi là cấu hình cao

    • Không biết trên Chrome có chạy tốt hơn không. Có vẻ khá nhiều người gặp vấn đề với Firefox. Từ giờ tôi sẽ kiểm thử Firefox thường xuyên hơn
    • Nếu bạn có thể thử lại, một bản sửa vừa được triển khai giúp cải thiện đáng kể hiệu năng trên một số máy
      Vì đây là việc port một game engine native sang WASM, vấn đề nằm ở mã giới hạn tốc độ khung hình không hợp với API timing của trình duyệt: https://raverie-us.github.io/raverie-engine/
    • Tôi cũng có đúng trải nghiệm như vậy trên M2 Pro, và tôi cũng dùng Firefox
    • Họ vẫn còn sản xuất Celeron à?

  • Đoạn “engine của chúng tôi có một tính năng độc đáo gọi là Spaces, cho phép khởi tạo các world/level riêng biệt” theo tôi trông giống hệt những gì engine Godot làm[1]
    Engine đó cũng có target trình duyệt (WASM). [1]: https://godotengine.org/

    • Không chỉ có target WASM, nó còn có cả phiên bản web: https://editor.godotengine.org/
      Có vẻ đây không phải ưu tiên cao của dự án. Tôi thử sơ qua thì có vẻ chạy được :), nhưng chậm hơn chạy native
    • Tôi cũng không rõ nó khác scene của Unity thế nào

  • Tôi tự hỏi liệu có luồng phát triển WASM nào cho phép Web API của trình duyệt và WASM thuần tương tác với nhau mà không cần tầng JS, hoặc với chi phí thấp hay không
    Thỉnh thoảng tôi xem https://github.com/WebAssembly/proposals và thấy rất rối. Đề xuất import type có vẻ còn cách nhiều năm nữa, đề xuất GC gần như hoàn tất thì dành cho ngôn ngữ GC chứ dường như không dành cho trình duyệt↔WASM. Component model có vẻ xa với use case trình duyệt, JS String Builtins giúp chuỗi JS nhanh hơn nhưng không phải DOM. Tích hợp mô-đun ECMAScript biến mô-đun WASM thành ES module, nhưng Web API không phải ES module nên không giúp được gì. Nhìn các cuộc trao đổi của những người đóng góp, đôi lúc có vẻ việc cung cấp tính năng này không phải ưu tiên cũng chẳng nằm trong kế hoạch; với đa số, WASI và component model cho các mục đích như cloud, mã hóa có vẻ quan trọng hơn

    • Tôi cũng rất muốn điều này. Tôi muốn thấy một trình duyệt wasm thuần, nơi trang chỉ là WASM, còn “trình duyệt” cung cấp các platform import giống WASI
      Nhưng như bạn nói, có vẻ đó không phải ưu tiên của họ. Hy vọng một ngày nào đó sẽ làm được
    • Nhờ reference types, về mặt kỹ thuật đã có thể gọi trực tiếp API trình duyệt. Vì WASM có thể truyền và nhận đối tượng JavaScript
      Nếu import toàn bộ các Web API liên quan, bạn có thể truyền nguyên các đối tượng JS giữa các lệnh gọi API riêng lẻ, nên gần như không cần JS trung gian. Thực tế JS chỉ cần thiết lúc khởi tạo mô-đun WASM ban đầu
    • Vấn đề của WASM thuần là nó có thể dẫn đến một web đóng với quảng cáo không thể chặn
    • Tôi cho rằng ít nhất một phần đây là hướng mà đề xuất GC nhắm tới

  • Dự án rất hay. Có cách nào phóng to UI trên màn hình độ phân giải cao không?
    Trên màn hình 2:1, font chữ bị răng cưa. Nếu đặt zoom trình duyệt ở 50%, UI sắc nét hơn, nhưng mọi thứ lại quá nhỏ đến mức khó dùng

    • Gửi OP: cách sửa là đặt chiều rộng canvas thành window.innerWidth * window.devicePixelRatio, chiều cao thành window.innerHeight * window.devicePixelRatio
      Sau đó dùng CSS để phóng tối đa canvas lên màn hình là được
    • Tôi không hiểu tại sao không dùng engine render native của trình duyệt cho UI, hoặc ít nhất là SVG
      Như vậy sẽ rẻ hơn về tài nguyên (bộ nhớ, mạng, CPU), dễ hỗ trợ accessibility hơn, và render cũng dễ hơn

  • Trevor! Tôi thật sự thích môn tự chọn CS ở DigiPen về thiết kế ngôn ngữ lập trình thông qua ngữ pháp
    Khá nhiều sinh viên từng được dạy hiện đang làm ở Minecraft. Khi thiết kế API scripting cho Minecraft hiện nay, tôi đang tận dụng những nền tảng đã học khi đó và rất nhiều nội dung từ thời DigiPen. Rất vui khi thấy bạn vẫn đang làm những thứ tuyệt vời

    • Tôi rất vui vì nó hữu ích! Một ngày nào đó tôi sẽ lại đi dạy ;)
      Tôi cũng rất muốn xem giao diện scripting mà bạn đang làm. Trước đây tôi đã làm rất nhiều mod Minecraft, và luôn muốn có một dạng scripting động nào đó

  • Thật sự rất tuyệt. Rất vui khi thấy một sản phẩm dựa trên WASM thuần trong lĩnh vực này. Tuy vậy trên M1 Mac Pro của tôi nó khá giật

  • Tôi có một câu hỏi: cái này có chạy được trên NES không? Máy của tôi là mẫu nạp băng phía trước đã tân trang, linh kiện hầu hết là nguyên bản, nhưng tôi có gắn thêm ít RAM
    Tôi dán nó lên phía trên bằng súng bắn keo, sơn vỏ màu đỏ rồi gắn thêm vài món đồ chơi lính

    • Sao ý tưởng làm bộ chuyển đổi WASM > NES lại nghe có vẻ thật sự thú vị nhỉ…

  • Chỉ mở cảnh quả bóng mặc định thôi mà nó đã đánh rất mạnh vào Radeon Pro 560X của tôi trong môi trường gần 4K
    Chỉ xoay camera thôi cũng khiến tốc độ khung hình rất thấp. Có ai biết liệu có thể có vấn đề tối ưu WebGL không?

    • Trên Intel HD Graphics 620 của tôi thì chạy rất mượt. Đây là đồ họa tích hợp Intel thế hệ 7, khá cũ và chậm, nhưng khi chỉ xem cảnh quả bóng mặc định, tôi ngạc nhiên vì trên hệ thống của mình nó cực kỳ trơn tru. Tôi đang dùng Chrome
    • Nếu bạn có thể thử lại, một bản sửa vừa được triển khai giúp cải thiện đáng kể hiệu năng trên một số máy
      Vì đây là việc port một game engine native sang WASM, vấn đề nằm ở mã giới hạn tốc độ khung hình không hợp với API timing của trình duyệt: https://raverie-us.github.io/raverie-engine/
    • Nghe cũng có vẻ như máy không dùng card đồ họa rời. Các demo WebGL khác có chạy bình thường không?