HN giới thiệu: Mã nguồn mở hóa engine game của tôi

 (github.com/moddio)
2 điểm bởi GN⁺ 2023-12-22 | 1 bình luận | Chia sẻ qua WhatsApp

Engine game Moddio 2

  • Moddio là một engine game ưu tiên chế độ nhiều người chơi.
  • Tích hợp sẵn mã mạng có máy chủ toàn quyền, nội suy snapshot và tính năng hiệu chỉnh phía máy khách.
  • Hỗ trợ hơn 50 người chơi đồng thời hoặc hơn 300 đối tượng chuyển động trên một VM 5 USD/tháng.

Bản demo

  • Bao gồm sẵn: engine vật lý Box2D, mã mạng có máy chủ toàn quyền, hệ thống kho đồ và vật phẩm, thuộc tính tích hợp sẵn (HP, năng lượng, v.v.) và tốc độ hồi, hệ thống hội thoại, cửa hàng, điều khiển đơn vị, đạn và di chuyển đơn vị có dự đoán phía máy khách, AI đơn vị và tìm đường A*, điều khiển trên di động, v.v.

Cách chạy game

  • Cần Node 18 trở lên.
  • Sau khi thiết lập kho lưu trữ, chuyển đến thư mục /src, đổi tên game-sample.json thành game.json, rồi quay lại thư mục gốc và chạy máy chủ.
  • Giờ bạn có thể chơi game tại http://localhost:80.

Cách tạo game mới từ đầu

  • Game Moddio được tạo và chỉnh sửa bằng trình biên tập game Moddio do https://www.modd.io cung cấp.
  • Sau khi tạo game, bạn có thể xuất game.json để dùng cho bản cài đặt cục bộ.
  • Đổi tên JSON game đã xuất thành game.json và chuyển nó vào thư mục ./src.

Cách đóng góp

  • Moddio hoàn toàn miễn phí và mã nguồn mở theo giấy phép MIT.
  • Để tìm hiểu cách trở thành người đóng góp, hãy truy cập trang hướng dẫn đóng góp.

Ghi công

  • Có sử dụng Isogenic game engine, Phaser, PlanckJS, uWebsocket, Box2D, tài nguyên Kenney, Hero Icons, v.v.

Ý kiến của GN⁺

  • Engine game Moddio chuyên biệt cho phát triển game nhiều người chơi và cung cấp các tính năng mạnh mẽ để hỗ trợ số lượng lớn người chơi với chi phí thấp.
  • Đây là mã nguồn mở và liên tục phát triển nhờ đóng góp của cộng đồng, nên cũng dễ tiếp cận với các kỹ sư phần mềm mới vào nghề.
  • Tích hợp sẵn nhiều tính năng cần thiết cho phát triển game, giúp nhà phát triển có môi trường để nhanh chóng tạo nguyên mẫu và thử nghiệm.

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-22
Ý kiến trên Hacker News

  • Trên màn hình đăng ký của ứng dụng Android, họ yêu cầu nhập tên người dùng và mật khẩu Google vào một chỗ trông như biểu mẫu web bên trong ứng dụng, nhưng người dùng không có cách nào biết ứng dụng có đang nhìn lén mật khẩu hay không
    Thường thì có vẻ ứng dụng dùng luồng chuyển sang màn hình đăng nhập rồi quay lại, nên tôi tò mò không biết việc triển khai mẫu đó có khó không. Cũng tò mò liệu đây có phải vấn đề do hỗ trợ đa nền tảng không

    • Về nguyên tắc thì không phải việc quá khó. Khi làm việc với các hãng xe, chúng tôi phải để người dùng đăng nhập bằng tài khoản OEM; trên lý thuyết thì tất cả đều tuân thủ quy định, nhưng thực tế thì nhiều phần không hoạt động và việc sửa cũng mất nhiều thời gian
      Tuy nhiên cách nói ở trên thực sự không nên xảy ra, và tôi tưởng Google đã cấm rồi
    • Cái này gọi là OAuth 2.0, và nếu dùng thứ như Okta thì triển khai khá đơn giản

  • Khiến người dùng chấp nhận một game engine chưa bao giờ là việc dễ, đặc biệt nếu đó là mã nguồn đóng thì càng khó hơn
    Nhìn gallery game trên trang web thì có vẻ họ đã làm khá tốt cho đến nay; tôi tò mò không biết đó là do vài người bạn làm ra hay có một cộng đồng khá sôi động

    • Sự kết hợp giữa tính năng tốt, dễ học và rào cản gia nhập thấp có thể đi được khá xa
      Hãy nghĩ tới một cấu trúc mà chỉ cần bỏ vài ngày, hoặc thậm chí vài giờ một cách casual, cũng có thể tạo ra kết quả có ý nghĩa. Cứ nhớ lại Flash là được
    • Có một cộng đồng sôi động và mỗi ngày họ tạo 150~300 game mới
      Việc rào cản gia nhập thấp cho cả nhà phát triển game lẫn người chơi chắc chắn có ích. Không cần tải xuống hay đăng ký

  • Chỉ nhìn tiêu đề thì tôi không nghĩ đây là modd.io. Đây là một framework/nền tảng phổ biến dùng để tạo game IO

    • Tôi chơi khá nhiều game và trước đây cũng từng bán game, nhưng chưa từng nghe thuật ngữ đó. Game IO là gì?

  • Tôi đã vào thử một server Brains và tò mò trải nghiệm với khoảng 50 người chơi ra sao. Chuyển động hơi giật cục như có thể dự đoán với WebSocket, và vì tôi cũng đang làm thứ tương tự nên cũng tò mò về nén mạng
    Tôi không chắc chỉ nén LZ-string có đủ không. Với 50 người chơi, nó dùng khoảng 20KB mỗi giây, trong khi Warzone với 150 người chỉ dùng khoảng 48KB mỗi giây. Nếu không phải dữ liệu không giới hạn, chi phí băng thông cloud có thể khá đáng kể
    Việc buffer byte đã nén trông như 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼 cũng thú vị. Tôi không biết kết quả nén LZ-string vốn có trông như vậy không, nhưng nhìn khá lạ
    Dù sao thì để giảm chi phí tiềm ẩn, phần networking còn nhiều chỗ có thể cải thiện. Toàn bộ dự án rất ấn tượng và được làm rất tốt

    • Với WebSocket của chúng tôi, chuyển động khá chặt chẽ: https://gooberdash.winterpixel.io/
      Điểm cốt lõi là dự đoán phía client và thuật toán networking rollback. Trạng thái game của chúng tôi ở 30Hz khoảng 1KB nên thường nằm gọn trong một packet đơn, vì vậy WebSocket cũng không quá tệ. Tất nhiên một giao thức không bảo đảm tin cậy vẫn tốt hơn
    • Bạn có thể giải thích thêm phần “chuyển động hơi giật cục như có thể dự đoán với WebSocket” không? Tôi đã chơi vài “game IO” và trừ một số người chơi có độ trễ cao thỉnh thoảng xuất hiện, chúng trông khá mượt
      Vài tháng trước tôi có thử nghiệm WebSockets một chút, và theo tôi hiểu thì việc dùng TCP cho giao tiếp nhạy cảm với độ trễ như game có khá nhiều nhược điểm. Header TCP lớn hơn UDP hơn 2 lần, có các packet điều khiển bổ sung, và việc gửi dữ liệu mới bị trì hoãn trong khi dữ liệu cũ được truyền lại. WebSockets cũng hoạt động trên TCP nên có cùng nhược điểm
      Dù vậy người ta vẫn nói TCP bảo đảm việc gửi thông điệp WebSocket, nhưng tôi đã có thể tái hiện mất packet. Cuối cùng thì nhược điểm vẫn còn, và nếu thực sự cần bảo đảm gửi đến thì bạn phải tự xây thêm gì đó bên trên; mà nếu vậy thì có lẽ ngay từ đầu cũng có thể chỉ xây những thông điệp cần thiết như thế trên UDP
      Ngoài việc từng vọc qua networking một chút, tôi gần như không có kiến thức và kinh nghiệm, nên hãy đọc với lưu ý đó
    • Ký tự CJK chiếm một phần rất lớn trong các ký tự Unicode có thể in được. [1] Hai khối lớn nhất bao gồm U+3400~U+4DBF, U+4E00~U+9FFF
      Chuỗi đó được giải mã thành \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c
      [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs

  • Cách chắc chắn để không bao giờ hoàn thành game là bắt đầu bằng việc viết engine
    Tự làm công nghệ của riêng mình là hoàn toàn có thể, nhưng ở mỗi bước, công nghệ đó nên được điều chỉnh cho dự án của bạn chứ không phải thành một nền tảng game đa dụng

    • Mình nên bắt đầu viết blog thôi!
      Ở đây “bắt đầu viết blog” nghĩa là tạo một blog engine mới hoàn toàn từ đầu
    • Bạn có thể giải thích thêm đang nói tới phần nào của modd.io không? Ý bạn là đó là sản phẩm của một nỗ lực làm game thất bại à?
    • Phần lớn những người dùng engine có lẽ ngay từ đầu không hẳn muốn làm game, mà thật ra là những người muốn làm engine

  • Tôi từng thấy các backend multiplayer dựa trên Node.js cuối cùng chậm như bò khi số lượng kết nối tăng lên. Tò mò là các bạn đã giải quyết vấn đề này như thế nào
    Trong trường hợp như vậy, liệu một lựa chọn thay thế như Go có tốt hơn không?

    • Tôi không rõ vì sao lại như vậy. Xét về kết nối thì nhờ event loop của Node, việc I/O bị chặn ở phần request/response HTTP có lẽ không phải là vấn đề
      Backend cũng không có vẻ sẽ phải làm các tác vụ tính toán vật lý nặng thay cho frontend
    • Chúng tôi dùng uWebSockets(https://github.com/uNetworking/uWebSockets). Nó được viết bằng C nhưng có interface dùng được trong NodeJS
      Trong các thử nghiệm đơn giản, hiệu năng của nó tốt hơn nhiều so với các thư viện WebSocket phổ biến khác vốn nhanh chóng chậm lại
    • Trong hầu hết game .io, tôi nghĩ nút thắt sẽ là I/O. Tên thể loại xuất phát từ top-level domain, nhưng trông cũng giống một cách chơi chữ
      Vì vậy Node có vẻ là một lựa chọn tốt
    • Khả năng mở rộng có thể là một yếu tố thực tế cần cân nhắc, đặc biệt khi số lượng kết nối lớn. Trong trường hợp của chúng tôi, chúng tôi đã tối ưu backend để xử lý hiệu quả một lượng khá lớn kết nối đồng thời
      Mỗi game bị giới hạn tối đa 64 người, nhưng khi thử nghiệm tới hơn 100 kết nối, chúng tôi không thấy vấn đề hiệu năng nào. Mỗi game chạy trong một container tách biệt

  • Tôi tò mò về động lực tạo ra engine mới
    Nhìn README thì thấy có sẵn những thứ khá cụ thể như hệ thống vũ khí (cận chiến/đạn bay), cửa hàng, projectile dự đoán phía client và di chuyển unit
    Tôi thắc mắc vì sao lại nhúng những thứ này vào engine, thay vì làm thành plugin có thể sao chép. Tất nhiên nhiều game không cần các tính năng như vậy; vậy đây là game engine? Hay là engine cho FPS/RPG/thể loại cụ thể nào đó?
    Tôi không ghét công nghệ này, nhưng vẫn còn câu hỏi “tại sao?”. Nó dùng để làm gì? Vì sao nên dùng cái này thay vì Three.js và server tự viết?

    • Cảm ơn câu hỏi. Chúng tôi đã chủ ý quyết định làm engine theo hướng có quan điểm rõ ràng hơn so với các lựa chọn module hóa khác, vì muốn phát triển game multiplayer 2D cực nhanh
      Ví dụ, chúng tôi đã làm một MMORPG đơn giản trong 2 giờ: https://www.youtube.com/watch?v=GZVsxkALR5U
      Tôi cho rằng có sự đánh đổi giữa mức độ dễ dùng và khả năng tùy biến. Chúng tôi chọn vế trước để thu hẹp khoảng cách giữa game multiplayer, vốn nổi tiếng là khó làm, và các nhà phát triển game casual
    • “Nó dùng để làm gì?”
      Có vẻ không dành cho bạn, mà dành cho những người muốn làm những game cụ thể kiểu đó. Không phải engine nào cũng cần phải đa dụng

  • Tôi có vài dự án sở thích có vẻ rất hợp với cái này. Tôi biết code, nhưng khi làm dự án hobby có những lúc tôi không muốn tập trung đến mức đó, nên low-code và trình chỉnh sửa tương tác có vẻ rất tốt cho developer làm vì sở thích
    Cá nhân tôi mong chờ nhất phần bản đồ và tạo thế giới. Có vẻ cách tốt nhất là export game ra JSON, chỉnh sửa bằng chương trình rồi import lại; không biết có đúng không
    Tuy nhiên cũng hơi ngợp. World tutorial chưa chỉnh sửa đã là JSON 3.500 dòng, nên có nhiều thứ phải hiểu
    Cách đầu tiên tôi nghĩ tới là cố tình chỉnh sửa trong editor rồi xem JSON thay đổi ra sao. Tôi cũng cần tìm một JSON diff viewer tốt. Làm vậy có lẽ sẽ giúp tìm được phần mình muốn đụng tới. Asset và tile bản đồ chắc tôi sẽ gom bằng trình chỉnh sửa tương tác
    Tôi tò mò liệu cách tiếp cận này có hợp lý không, và có công cụ nào hữu ích không

    • Chúng tôi không khuyến nghị chỉnh sửa JSON trực tiếp. Nó khá khó đọc và phình to. modd.io có các action cho phép chỉnh sửa bản đồ trực tiếp
      Một creator trong cộng đồng của chúng tôi đang dùng ChatGPT để tạo bản đồ động. Anh ấy đang làm game trốn tìm, gửi prompt yêu cầu tạo JSON bản đồ 2D và tải bản đồ đó mỗi khi bắt đầu vòng mới. Game chưa công khai nên khó chia sẻ
      Ngoài ra, một thành viên cộng đồng khác đang làm interpreter cho JSON game của chúng tôi. Ví dụ: https://pypi.org/project/pymodd/

  • Thật vui khi thấy có thêm những dự án open-source như thế này. Ngạc nhiên là nó còn chưa tới 100 sao GitHub

    • Đừng hiểu lầm, tôi hỏi vì thật sự tò mò. Vì sao việc có dưới 100 sao GitHub lại đáng ngạc nhiên?
    • Có lẽ vì nó vừa mới được công bố