ビデオゲーム制作のための実験的新技術 Core

 (github.com/damn)
2 ポイント 投稿者 GN⁺ 2024-09-09 | 1件のコメント | WhatsAppで共有

  • coreCoreとは何か

    • coreCoreは、Action-RPGゲーム制作ツール兼エンジンであり、プロパティエディタの形でビデオゲームを記述する実験的な方法である
    • シンプルなコンポーネントシステムを使用し、コンポーネントは[keyword value]形式のclojureベクタである
    • さまざまなエンティティはclojureマップで構成される
    • ゲーム内の副作用は[:tx/foo param]のようなコンポーネントで処理され、これはdatomicの構造に似ている
    • ゲーム全体の状態はapp/stateという1つのatomに保存され、エンティティもメインatom内部のatomとして存在する
    • アプリケーション全体の内容はresources/properties.ednに保存され、malli-schemasを使って検証され、GUIで編集可能である

  • スクリーンショット

  • 開発の始め方

    • 次のコマンドを入力:
      • lein dev
    • アプリケーションが起動し、次の作業も実行される:
      • NREPLサーバーを起動
      • アプリケーション終了時（メインメニューでESC）、clojure.tools.namespaceが変更されたファイルをリロードし、アプリを再起動する
      • エラー発生時はJVMを再起動する必要はなく、エラーを修正してdev-loop/restart!を呼び出せばよい
      • VIMでF5キーに次のコマンドをバインドして使用可能: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • コードライセンス

    • MITライセンスの下で提供される

  • アセットライセンス

GN⁺の要約

  • coreCoreはAction-RPGゲームを簡単に制作できるツールで、シンプルなコンポーネントシステムを使ってゲーム状態を管理する
  • ゲーム全体の状態を1つのatomに保存し、GUIを通じてプロパティを編集できるため、開発者にとって有用である
  • MITライセンスで提供されるが、使用されているアセットは独占的である
  • 類似の機能を持つツールとしては、RPG MakerやUnityなどがある

関連記事

1件のコメント

 
GN⁺ 2024-09-09
Hacker Newsのコメント

  • すごい。ゲームをリリースしたことはないが、ゲーム開発に対する異なるアプローチを見るのはいつも好きだ
    これまでのところ、Bevyは最初は良いが実装上の問題が多く、散らかりやすかったし、Unityはgameobjectとコンポジションベースのコンポーネント方式が最も実用的で、エンジンが邪魔をせずスパゲッティ化を避けやすかった
    Godotは好きではなかった。オブジェクト指向のよくない階層構造、いまひとつな内蔵言語、そしてスパゲッティを減らそうとする“signals”がかえってそれを増やしていた。Pygameは小さなプロジェクトにはかなり良く、手続き型ベースの上にオブジェクト指向や関数型の層を自分で載せられる
    Clojureは知らないが、典型的にはオブジェクト指向によく合いそうな分野で関数型実装を試みた点は興味深い

    • UnityとGodotの両方で実際の製品を作ったプロのゲーム開発者として、GodotとUnityに対する評価にはまったく同意しがたい
      Godotのsignalsは、Unity組み込みクラスのモジュール性の欠如と比べれば大きな進歩だ。GodotとUnityは基本的に同じscene/node/componentモデルを持つが、Godotのほうがうまくやっていると思う
      Unityの強みは3Dレンダラー、内蔵PhysX、C#向けil2cppバックエンド、プロファイラ、全体的な実行性能、コンソール対応だ。一方でGodotの設計はより一貫しており、Unityは2018年ごろから10方向に分裂したように感じる
    • ゲーム開発者ではないが、Godotのオブジェクト指向設計は私が使った中ではかなり良い部類だった
      今はC++の組み込み分野にいるのでオブジェクト指向をあまり使わないが、C#でプログラミングを学んだので継承には慣れている
    • Godotは素晴らしく、5年ほど後にはゲーム制作のBlenderになると思う。バージョン4は実戦投入でき、多くのインディープロジェクトをこなせる
      Unityが優位な領域は“Triple I”と“Double A”級で、3D/性能機能、ツール、アドオンがより優れているからだ。AAAプロジェクトではどちらも最善ではない
      2Dやシンプルな3Dゲームでは、もはやUnityを使う理由はないように見えるし、Godotがゆっくり追い越していき、Unityのシェアは着実に減っていく気がする
    • 商業開発者として以前はUnityを使い、今はGodotを使っている。GD Scriptとsignalsへの批判には共感しており、私はC#のイベント処理で回避している
      ノードやエディタに、バグなのか機能なのかわからないものがあるのが一番つらく、最初に“小さな”プロジェクト向けとして作られた感じが強い
      そのためエディタはscene構成と大まかな階層設定以外ではほとんど使わない。普段のツールはEmacs+C# LSP、デバッグはVS Code、scene treeの調整はGodotエディタを使う
    • Godotをかなり真剣に使ってきて、嫌う理由もあるが、GDScriptはその理由ではないと思う
      基本的にはPythonにslot/emitのセマンティクスを付けてエディタと統合した形なので、むしろ悪くない。ビルドシステム、メタデータ、外部設定ファイルで統合する複雑なやり方より、言語の中に入っているほうが良い

  • ゲーム開発を単純にできると言っておきながら、Clojure vectors、datomics、atoms、transactions、malli schemasのような専門用語を大量に投げ込んでいる。誰か説明してくれないか？

    • 紹介文を整えて言えば、CoreはアクションRPG制作を単純化しようとする実験的ツールだ
      ゲーム要素と属性を単純なデータ構造で表現し、ゲーム全体の状態を1つのコンテナ(app/state)に保存して管理と更新をしやすくする
      さらに、単一ファイル(resources/properties.edn)に保存されたゲームコンテンツを編集するGUIを提供し、非プログラマーでも扱いやすくし、Malliスキーマでデータ検証を行ってコンテンツの一貫性とエラー削減を狙っている
    • 公平に言えば、ゲーム開発が単純になりうるのかと尋ねているだけだ。答えはたぶん「いいえ」である可能性が高い
    • 必ず出てくる「単純さは容易さと同じではない」: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vectorは基本的にはリストに近い。atomは不変データ構造を指す変更可能な参照であり、特定の更新セマンティクスを持つポインタのようなものと見なせる
      transactionはデータベーストランザクションに似ており、複数のデータ構造を同時に変更するが、すべての操作が成功したときだけコミットし、失敗した場合はロールバックまたは再試行する
      Malli schemaは動的型付け言語で型検査を行う方法で、Datomicは不変データ構造ベースの非SQLデータベース実装であり、変更を破壊的に上書きせず追加のみを行うため、過去のどの時点にでも巻き戻して見られるようにする
    • Clojure言語には組み込みの状態管理モデルがあり、このプロジェクトはそのモデルをゲーム開発に適用しようとする試みだ
      このモデルを学ぶ最良の方法は、Clojureの生みの親であるRich Hickeyの講演「Are we there yet」を見ることだと思う
    • Clojure vectorは言語組み込みのデータ構造で、[1 2 3]のような形をしている
      私はこれを使って[:tx/foo 3]のような副作用を構成し、これをDatomicにならってtransactionと呼んでいる。ここで:tx/fooはキーワードであり、コンポーネントの動作を一意に識別する

  • 正直に言って、このプロジェクトは実際には失敗したと思う。過剰設計された混乱で、明確な構造がない
    最大の問題は、仕様がまったくないことだ。ゲームストーリーを作っていなかったか、あるいはゲームにストーリーは不要だと考えていたからだろう。だからただClojureでコードを書くのが楽しくて、夢中でコーディングしていた

    • 公平に見れば、成功したプロジェクトの中にも、過剰設計された混乱で明確な構造がないものは多い
      面白いことを試みたのは良いし、多くの人が関心を持っている領域だ
    • 単に楽しい趣味だったことと、主張したほど単純ではないかもしれないことを認めているだけでも、すでに多くの人より一歩先にいる。プロジェクトから多くを学べたことを願う

  • ゲーム開発者としては、このGitHubは滑稽に感じる。ゲーム開発者が嫌う学術的な自己陶酔のパロディに近い。醜いスクリーンショットまであってまさに仕上げという感じ

    • だとすると、このサイトにはあまり合っていないのでは？ Hacker Newsはたいてい興味深い新しいアイデアを扱う場であって、C++やUnityの漸進的な改善だけを語る場ではない。
      こういう奇妙な学術的自己陶酔から生まれたゲームもいくつか思い浮かぶ。兄弟コメントのJonathan Blowもそうだし、このプロジェクトを見た瞬間にBraidを思い出した。
      手続き的生成も昔は象牙の塔の話題だったし、3Dグラフィックスのあらゆる進歩も最初は学会から出てきた完全に非現実的な論文から始まった。今ではゲームで主流のものの多くが、かつてはニッチな学術アイデアだった
    • スクリーンショットが「醜い」とは思わないが、READMEが機能的に役に立たないという点には同意する。ドキュメントもサンプルもなく、なぜ使うべきなのかの説明もない。
      何をするものなのかを伝える基本段階で失敗している
    • 知的に刺激的なものを作ることにも価値はある。Clojure datomicsを作るのに100時間使って、レベルコンテンツを1時間しか作らなくても、1時間は0時間より大きい。
      退屈で最初から何も作らなかっただろうなら、むしろ得だ。インディー開発におけるJonathan BlowがJaiを使う論理に近い
    • 実験的だとは書いてある

  • このリポジトリはドキュメントがこれほど少ないのに、かなり議論が出ているのが意外だ。コードを見ると、ゲームエンジンというよりプロジェクトに近く見える。
    property editorは興味深いが、この投稿は内容よりタイトルのおかげで支持されているように思える

  • いいね。私のようにClojureでゲーム開発をしている開発者を見るとうれしい。時々自分で仕事をもっと難しくしてしまうけれど :)
    今はClojureで3DマルチプレイヤーTPSシューターを開発中。興味があればデモはこちら: https://prototype-game.pages.dev
    近いうちに開発の道のりをまとめたブログ記事も公開する予定

    • 複数人が仮想空間に入って、その場で走り回ってゲーム内チャットを書く瞬間は、インターネットで一番好きな光景のひとつだ

  • Clojureは好きだけど、不変データ構造を使う関数型言語はビデオゲーム開発には少し変わった選択ではない？

    • 十分可能だし、興味深いトレードオフもある。
      関数型ゲーム開発に関連して気に入っている記事:
      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
    • かなり自然に感じる。ClojureはJVMベースなので、このプロジェクトは内部的にlibgdxを使っていて、すべてのプラットフォームに配布可能でライブラリも豊富だ。
      あとはLispでほぼ何でもできる。Clojureの不変データ構造の扱い方と優れたprotocolシステム(https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...)のおかげで、ゲーム全体を別々のコンポーネントに簡単に分けられた
    • Tim SweeneyもUEFNでVerseを通じてそういう方向に賭けているように見える。VerseはHaskellをもっと親しみやすくしたものに近い
    • そこまで変ではない。次のAAやAAAゲームが採用することはないだろうが、ReactのreducerやReduxのような非常にインタラクティブな領域でも不変性はよく見られる。
      ClojureはRubyやPythonより性能面の可能性が高く、どちらも商業インディーゲームで実際に使われたことがある
    • 関数型プログラミングは、ゲーム開発でまともに試されたことすらほとんどない。ゲーム開発業界と学術界の重なりが足りない。
      スタジオは当然ながらリスク回避的で、オブジェクト指向や、大規模な群衆にECSを使うといった慣れた戦略を好む。
      個人的には関数型プログラミングは相性がいい可能性があると思うが、まずは実際のゲーム開発の問題を解くアーキテクチャを見つける必要がある。小さな実験から始めるべきで、ゲームジャムはそこにぴったりだ

  • Unreal Engine 4ベースで動くCoreという商用ゲーム制作プラットフォームはすでに存在する。
    https://en.wikipedia.org/wiki/Core_(video_game)

  • 名前の選び方を誤ったように思う。すでにこちらで使われている: https://www.coregames.com/create

    • 私も真っ先にそれを思った。特にあちらはゲームの中でゲームを作るものなので、ゲームを書くための「新しい」方法と見ることもできる

  • 「ゲームエンジンに費やした時間/複雑さ」と「できあがったゲームの複雑さ/面白さ」のデータを分析すると面白そうだ。
    ゲーム開発者として、単純なテンプレート/エンジンシステムから生まれる新しいゲームの収益は、逓減する対数曲線になるだろうと予想する。
    言い換えれば、クッキーを型抜きする機械を良くすればするほど、クッキーの多様性は減っていく