Core, công nghệ mới mang tính thử nghiệm để tạo video game

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

  • coreCore là gì

    • coreCore là một phương pháp mang tính thử nghiệm để tạo video game dưới dạng công cụ và engine làm game Action-RPG, cùng với trình biên tập thuộc tính
    • Sử dụng một hệ thống component đơn giản, trong đó component là vector clojure có dạng [keyword value]
    • Nhiều entity khác nhau được cấu thành từ các map clojure
    • Các side effect trong game được xử lý bằng component như [:tx/foo param], có cấu trúc tương tự datomic
    • Toàn bộ trạng thái game được lưu trong một atom duy nhất tên là app/state, và các entity cũng tồn tại dưới dạng atom bên trong atom chính
    • Toàn bộ nội dung của ứng dụng được lưu trong resources/properties.edn, được kiểm tra bằng malli-schemas và có thể chỉnh sửa qua GUI

  • Ảnh chụp màn hình

  • Cách bắt đầu phát triển

    • Nhập lệnh sau:
      • lein dev
    • Ứng dụng sẽ khởi chạy và đồng thời thực hiện các tác vụ sau:
      • Khởi động máy chủ NREPL
      • Khi thoát ứng dụng (ESC ở menu chính), clojure.tools.namespace sẽ làm mới các tệp đã thay đổi và khởi động lại ứng dụng
      • Nếu xảy ra lỗi, không cần khởi động lại JVM; chỉ cần sửa lỗi và gọi dev-loop/restart!
      • Có thể dùng bằng cách gán lệnh sau vào phím F5 trong VIM: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Giấy phép mã nguồn

    • Được cung cấp theo giấy phép MIT

  • Giấy phép tài sản

Tóm tắt của GN⁺

  • coreCore là công cụ giúp tạo game Action-RPG dễ dàng hơn bằng cách dùng hệ thống component đơn giản để quản lý trạng thái game
  • Toàn bộ trạng thái game được lưu trong một atom duy nhất và có thể chỉnh sửa thuộc tính qua GUI, rất hữu ích cho nhà phát triển
  • Được phát hành theo giấy phép MIT, nhưng các tài sản đi kèm là độc quyền
  • Những công cụ có chức năng tương tự gồm có RPG Maker, Unity, v.v.

Bài viết liên quan

1 bình luận

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

  • Hay đấy. Tôi chưa từng phát hành game nào, nhưng luôn thích xem những cách tiếp cận khác nhau trong phát triển game
    Cho đến nay, Bevy ban đầu thì có vẻ tốt nhưng có nhiều vấn đề trong triển khai và có thể trở nên lộn xộn; còn Unity thì cách dùng gameobject và component dạng kết hợp là thực dụng nhất, engine không cản trở và dễ tránh spaghetti
    Tôi không thích Godot. Hệ phân cấp hướng đối tượng tệ, ngôn ngữ tích hợp không hay, và “signals” vốn nhằm giảm spaghetti lại làm nó tăng thêm. Pygame khá tốt cho các dự án nhỏ, và bạn có thể tự đặt các lớp hướng đối tượng hoặc hàm lên trên nền tảng thủ tục
    Tôi không biết Clojure, nhưng việc thử triển khai theo hướng hàm trong một lĩnh vực thường có vẻ rất hợp với hướng đối tượng là điều thú vị

    • Với tư cách là một nhà phát triển game chuyên nghiệp đã làm sản phẩm thực tế bằng cả Unity lẫn Godot, tôi hoàn toàn khó đồng ý với đánh giá về Godot và Unity
      Signals của Godot là một bước tiến lớn so với sự thiếu mô-đun của các lớp tích hợp trong Unity. Godot và Unity về cơ bản có cùng mô hình scene/node/component, nhưng tôi cho rằng Godot làm tốt hơn
      Điểm mạnh của Unity là renderer 3D, PhysX tích hợp, backend il2cpp cho C#, profiler, hiệu năng chạy tổng thể và hỗ trợ console. Ngược lại, thiết kế của Godot gắn kết hơn; còn Unity từ khoảng năm 2018 có cảm giác bị tách ra theo 10 hướng khác nhau
    • Tôi không phải nhà phát triển game, nhưng thiết kế hướng đối tượng của Godot thuộc loại khá tốt trong những thứ tôi từng dùng
      Dạo này tôi làm C++ embedded nên không dùng hướng đối tượng nhiều, nhưng tôi học lập trình bằng C# nên khá quen với kế thừa
    • Godot rất tuyệt, và tôi nghĩ khoảng 5 năm nữa nó sẽ trở thành Blender của việc làm game. Phiên bản 4 đủ dùng trong thực chiến và có thể gánh hầu hết dự án indie
      Những mảng Unity vượt trội là cấp “Triple I” và “Double A”, vì các tính năng 3D/hiệu năng, công cụ và add-on tốt hơn. Với dự án AAA thì cả hai đều không phải lựa chọn tối ưu
      Với game 2D và 3D đơn giản, giờ tôi không thấy lý do gì để dùng Unity nữa; có lẽ Godot sẽ dần vượt lên và thị phần Unity sẽ đều đặn giảm
    • Là nhà phát triển thương mại, trước đây tôi dùng Unity và giờ dùng Godot. Tôi đồng cảm với phê bình về GD Script và signals, và tôi tránh bằng cách dùng xử lý sự kiện C#
      Điều khó chịu nhất là các node và những thứ trong editor không rõ là bug hay tính năng; nó cho cảm giác rất mạnh rằng ban đầu được làm cho các dự án “nhỏ”
      Vì vậy tôi hầu như không dùng editor ngoài việc dựng scene và thiết lập sơ bộ hệ phân cấp. Công cụ thường dùng của tôi là Emacs+C# LSP, debug bằng VS Code, và chỉnh scene tree bằng Godot editor
    • Tôi đã dùng Godot khá nghiêm túc và cũng có lý do để không thích nó, nhưng tôi không nghĩ GDScript là lý do đó
      Về cơ bản nó là Python được thêm ngữ nghĩa slot/emit và tích hợp với editor, nên lại khá ổn. Việc để nó nằm trong ngôn ngữ vẫn tốt hơn so với build system, metadata, và các cách tích hợp phức tạp bằng file cấu hình bên ngoài

  • Nói là có thể làm cho phát triển game đơn giản hơn, rồi lại ném ra hàng loạt thuật ngữ chuyên môn như Clojure vectors, datomics, atoms, transactions, malli schemas. Ai giải thích giúp được không?

    • Nếu viết lại phần giới thiệu cho rõ hơn, Core là một công cụ thử nghiệm nhằm đơn giản hóa việc tạo game action RPG
      Nó biểu diễn các yếu tố và thuộc tính của game bằng các cấu trúc dữ liệu đơn giản, lưu toàn bộ trạng thái game trong một container duy nhất (app/state) để dễ quản lý và cập nhật
      Ngoài ra, nó cung cấp GUI để chỉnh sửa nội dung game được lưu trong một file duy nhất (resources/properties.edn), giúp người không lập trình cũng dễ tiếp cận hơn; đồng thời dùng schema Malli để kiểm chứng dữ liệu, nhằm giữ tính nhất quán của nội dung và giảm lỗi
    • Công bằng mà nói, họ chỉ đang đặt câu hỏi liệu phát triển game có thể trở nên đơn giản hơn không. Câu trả lời có lẽ nhiều khả năng là “không”
    • Câu bắt buộc phải có: “đơn giản không đồng nghĩa với dễ”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector về cơ bản gần giống list. Atom là một tham chiếu có thể thay đổi trỏ tới cấu trúc dữ liệu bất biến, có thể xem như một con trỏ với ngữ nghĩa cập nhật cụ thể
      Transaction giống transaction cơ sở dữ liệu: thay đổi nhiều cấu trúc dữ liệu cùng lúc, nhưng chỉ commit khi mọi thao tác thành công; nếu thất bại thì rollback hoặc thử lại
      Malli schema là cách kiểm tra kiểu trong ngôn ngữ kiểu động, còn Datomic là một triển khai cơ sở dữ liệu phi SQL dựa trên cấu trúc dữ liệu bất biến, không ghi đè phá hủy thay đổi mà chỉ thêm vào, nhờ đó có thể tua lại bất kỳ thời điểm nào trong quá khứ
    • Ngôn ngữ Clojure có mô hình quản lý trạng thái tích hợp sẵn, và dự án này là một nỗ lực áp dụng mô hình đó vào phát triển game
      Tôi nghĩ cách tốt nhất để học mô hình này là xem bài nói “Are we there yet” của Rich Hickey, người tạo ra Clojure
    • Clojure vector là cấu trúc dữ liệu tích hợp của ngôn ngữ và trông như [1 2 3]
      Tôi dùng nó để cấu thành các side effect như [:tx/foo 3], và gọi chúng là transaction tương tự Datomic. Ở đây :tx/foo là keyword, định danh duy nhất hành vi của component

  • Nói thật, tôi nghĩ dự án này thực tế đã thất bại. Nó là một mớ hỗn loạn bị thiết kế quá mức và không có cấu trúc rõ ràng
    Vấn đề lớn nhất là hoàn toàn không có đặc tả. Có thể vì họ không tạo câu chuyện cho game, hoặc thậm chí nghĩ game không cần câu chuyện. Vì vậy họ chỉ thấy viết code bằng Clojure vui nên đã code điên cuồng

    • Công bằng mà nhìn, trong số các dự án thành công cũng có rất nhiều thứ là mớ hỗn loạn bị thiết kế quá mức và không có cấu trúc rõ ràng
      Việc thử làm điều gì đó thú vị là tốt, và đây là lĩnh vực nhiều người quan tâm
    • Chỉ riêng việc thừa nhận rằng đây đơn giản là một sở thích thú vị, và có thể nó không đơn giản như đã tuyên bố, đã là đi trước rất nhiều người rồi. Hy vọng bạn đã học được nhiều từ dự án

  • Với tư cách là một nhà phát triển game, GitHub này trông khá buồn cười. Nó gần như là một bản nhại của kiểu tự đắm chìm học thuật mà các nhà phát triển game ghét. Những ảnh chụp màn hình xấu xí còn là nét chấm phá hoàn hảo

    • Vậy chẳng phải nó không hợp với trang này sao? Hacker News nhìn chung là nơi nói về những ý tưởng mới thú vị, chứ không chỉ nói về các cải tiến tăng dần của C++ và Unity
      Tôi có thể nghĩ ra vài game xuất phát từ kiểu tự đắm chìm học thuật kỳ quặc như vậy. Jonathan Blow ở bình luận anh em cũng thế, và ngay khi thấy dự án này tôi đã nghĩ đến Braid
      Procedural generation trước đây cũng từng là chủ đề tháp ngà, và mọi tiến bộ trong đồ họa 3D ban đầu đều bắt đầu từ những bài báo hội nghị hoàn toàn phi thực tế. Nhiều thứ hiện là chủ lưu trong game từng là ý tưởng học thuật ngách
    • Tôi không nghĩ ảnh chụp màn hình “xấu”, nhưng đồng ý rằng README gần như vô dụng về mặt chức năng. Không có tài liệu, không có ví dụ, cũng không giải thích vì sao nên dùng
      Nó thất bại ngay ở bước cơ bản là truyền đạt mình làm gì
    • Tạo ra thứ kích thích trí tuệ cũng có giá trị. Dù bạn dành 100 giờ để tạo ra các datomic kiểu Clojure và chỉ tạo được 1 giờ nội dung màn chơi, thì 1 giờ vẫn lớn hơn 0 giờ
      Nếu vì chán mà rốt cuộc bạn chẳng làm gì cả, thì đây lại là có lợi. Nó giống với logic Jonathan Blow dùng Jai trong phát triển indie
    • Dù sao cũng có ghi là thử nghiệm mà

  • Khá bất ngờ là kho này có ít tài liệu như vậy mà vẫn tạo ra nhiều thảo luận. Nhìn vào code thì nó giống một project hơn là game engine
    property editor thì thú vị, nhưng bài này có vẻ được upvote vì tiêu đề hơn là vì nội dung

  • Hay đấy. Thấy một developer phát triển game bằng Clojure như tôi thì thật vui. Đôi khi đúng là tự làm khó mình hơn :)
    Hiện tôi đang phát triển một game bắn súng TPS multiplayer 3D bằng Clojure. Nếu quan tâm thì demo ở đây: https://prototype-game.pages.dev
    Tôi cũng sẽ sớm đăng bài blog về hành trình phát triển

    • Khoảnh khắc nhiều người bước vào một không gian ảo, chạy nhảy ngay tại chỗ và dùng chat trong game là một trong những cảnh tôi thích nhất trên Internet

  • Tôi thích Clojure, nhưng một ngôn ngữ hàm dùng cấu trúc dữ liệu bất biến chẳng phải là lựa chọn hơi lạ cho phát triển video game sao?

    • Hoàn toàn khả thi, và có những đánh đổi thú vị
      Đây là các bài viết tôi thích liên quan đến phát triển game theo phong cách hàm:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • Cảm giác khá tự nhiên. Vì Clojure chạy trên JVM nên dự án này bên trong dùng libgdx, có thể triển khai lên mọi nền tảng và hệ sinh thái thư viện cũng lớn
      Phần còn lại thì với Lisp gần như có thể làm bất cứ thứ gì. Nhờ cách Clojure xử lý cấu trúc dữ liệu bất biến và hệ thống protocol tuyệt vời (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...), tôi đã có thể dễ dàng chia toàn bộ game thành các component riêng biệt
    • Tim Sweeney dường như cũng đang đặt cược theo hướng đó với Verse trong UEFN. Verse gần với việc làm cho Haskell dễ tiếp cận hơn
    • Cũng không lạ đến thế. Game AA hay AAA tiếp theo chắc sẽ không dùng nó, nhưng tính bất biến cũng thường xuất hiện trong các lĩnh vực rất tương tác như reducer của React hay Redux
      Clojure có tiềm năng hiệu năng tốt hơn Ruby hay Python, và cả hai ngôn ngữ kia đều đã từng được dùng trong game indie thương mại thực tế
    • Lập trình hàm gần như còn chưa được thử nghiệm đúng nghĩa trong phát triển game. Ngành phát triển game và giới học thuật chưa giao thoa đủ nhiều
      Các studio dĩ nhiên thường né rủi ro và chuộng các chiến lược quen thuộc như hướng đối tượng hoặc dùng ECS cho các cụm thực thể lớn
      Cá nhân tôi nghĩ lập trình hàm có thể phù hợp, nhưng trước tiên cần tìm ra kiến trúc giải quyết được các vấn đề phát triển game thực tế. Nên bắt đầu bằng các thử nghiệm nhỏ, và game jam rất hợp cho việc này

  • Đã có một nền tảng tạo game thương mại tên là Core chạy trên Unreal Engine 4
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Có vẻ họ chọn tên không khéo. Tên này đã được dùng trong lĩnh vực này rồi: https://www.coregames.com/create

    • Tôi cũng nghĩ ngay đến điều đó đầu tiên. Đặc biệt là bên đó tạo game ngay bên trong game, nên cũng có thể xem là một cách “mới” để viết game

  • Sẽ rất thú vị nếu phân tích dữ liệu về “thời gian/độ phức tạp bỏ vào game engine” và “độ phức tạp/độ thú vị của game tạo ra”
    Với tư cách là một nhà phát triển game, tôi dự đoán lợi nhuận từ các game mới sinh ra từ hệ thống template/engine đơn giản sẽ là một đường cong log suy giảm
    Nói cách khác, càng làm máy dập bánh quy tốt hơn, sự đa dạng của bánh quy càng giảm