HN公開: 自分のゲームエンジンをオープンソース化

 (github.com/moddio)
2 ポイント 投稿者 GN⁺ 2023-12-22 | 1件のコメント | WhatsAppで共有

Moddioゲームエンジン 2

  • Moddioはマルチプレイヤー優先のゲームエンジン。
  • サーバー権限を持つネットワークコード、スナップショット補間、クライアント側調整機能を内蔵。
  • 月額5ドルのVMで、50人以上の同時プレイヤーまたは300個以上の移動オブジェクトをサポート。

デモ

  • 同梱内容: Box2D物理エンジン、サーバー権限を持つネットワークコード、インベントリおよびアイテムシステム、内蔵プロパティ（HP、エネルギーなど）と再生率、会話システム、ショップ、ユニットコントロール、クライアント側で予測される投射体およびユニット移動、ユニットAIとA*経路探索、モバイルコントロールなど。

ゲームの実行方法

  • Node 18以上が必要。
  • リポジトリをセットアップした後、/srcディレクトリに移動してgame-sample.jsonをgame.jsonにリネームし、ルートディレクトリに戻ってサーバーを実行。
  • これで http://localhost:80 でゲームをプレイ可能。

新しいゲームをゼロから作る方法

  • Moddioゲームは https://www.modd.io で提供されるModdioゲームエディタを使用して作成・編集される。
  • ゲーム作成後、ローカルインストールで使用できる game.json をエクスポートできる。
  • エクスポートしたゲームJSONを game.json にリネームし、./src ディレクトリに移動。

貢献方法

  • ModdioはMITライセンスの下で完全無料のオープンソース。
  • コントリビューターになる方法を知るには、貢献方法ページを参照。

クレジット

  • Isogenicゲームエンジン、Phaser、PlanckJS、uWebsocket、Box2D、Kenneyアセット、Hero Iconsなどを使用。

GN⁺の意見

  • Moddioゲームエンジンはマルチプレイヤーゲーム開発に特化しており、低コストで多くのプレイヤーを支えられる強力な機能を提供。
  • オープンソースであり、コミュニティの貢献を通じて継続的に発展しているため、初級ソフトウェアエンジニアにも取り組みやすい。
  • ゲーム開発に必要なさまざまな機能が内蔵されており、開発者が素早くプロトタイプを作成してテストできる環境を提供。

関連記事

1件のコメント

 
GN⁺ 2023-12-22
Hacker Newsのコメント

  • Androidアプリの登録画面で、Googleのユーザー名とパスワードをアプリ内のWebフォームのように見える場所へ入力するよう求められるが、ユーザーにはアプリがパスワードを盗み見していないか確かめる手段がない
    普通はアプリがログイン画面へ遷移してから戻ってくるフローを使うものだと思うが、そのパターンの実装が難しいのか気になる。クロスプラットフォーム対応のせいで起きる問題なのかも気になる

    • 原則として、そこまで難しいことではない。自動車メーカーと仕事をしているが、ユーザーにOEMアカウントでログインしてもらう必要があり、理論上はどれも規約準拠のはずでも、実際には多くの部分がうまくいかず、修正にも長くかかる
      ただし、上で述べられているやり方は本当に起きてはいけないことで、Googleがすでに禁止しているものだと思っていた
    • これはOAuth 2.0と呼ばれ、Oktaのようなものを使えば実装は簡単

  • ユーザーにゲームエンジンを採用してもらうのは決して簡単ではなく、特にクローズドソースならなおさら難しい
    サイトのゲームギャラリーを見ると、これまでかなりうまくやってきたように見えるが、数人の仲間が作ったものなのか、それともかなり活発なコミュニティがあるのか気になる

    • 優れた機能、学びやすさ、低い参入障壁の組み合わせはかなり遠くまで行ける
      気軽に数日、あるいは数時間かけるだけでも意味のある結果が出る構造を思い浮かべればいい。Flashを思い出せばよい
    • 活発なコミュニティがあり、毎日150〜300本の新しいゲームが作られている
      ゲーム開発者とプレイヤーの両方にとって参入障壁が低いことが、確かに助けになっている。ダウンロードも登録も不要

  • タイトルだけ見た時点では、これがmodd.ioだとは思わなかった。IOゲームを作るのに使われる人気のフレームワーク/プラットフォームだ

    • ゲームはたくさん遊ぶし、以前売ったこともあるが、その用語は聞いたことがない。IOゲームって何？

  • Brainsサーバーの1つに入って、プレイヤー50人ほどでの体験がどんなものか気になって試してみた。WebSocketで予想される通り、動きがややカクついており、似たものを作っているのでネットワーク圧縮についても気になった
    LZ-string圧縮だけで十分なのかはよく分からない。プレイヤー50人で毎秒およそ20KB使っているが、Warzoneは150人で毎秒48KB程度しか使っていない。無制限データでなければ、クラウド帯域幅のコストはかなりかさむ可能性がある
    圧縮されたバイトバッファが埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼のように見えるのも不思議だった。LZ-string圧縮の結果が元々こういうものなのかは分からないが、かなり見慣れない
    とにかく、潜在的なコストを下げるにはネットワーキング面で改善の余地が大きい。プロジェクト全体としては非常に印象的で、よくできた仕事だ

    • うちのWebSocketでは動きはかなりタイトだ: https://gooberdash.winterpixel.io/
      核心はクライアントサイド予測とロールバックネットワーキングアルゴリズムにある。うちのゲーム状態は30Hzで約1KBなので、通常は単一パケットに収まり、そのためWebSocketもそこまで悪くない。もちろん非信頼プロトコルの方がより良い
    • 「WebSocketで予想される通り、動きがややカクついていた」という部分をもう少し説明してもらえるだろうか？ いくつかの「IOゲーム」を遊んだことがあるが、ときどき遅延の大きいプレイヤーを除けば、かなり滑らかに見えた
      数か月前にWebSocketsを少しテストしてみたが、理解した限りでは、ゲームのようにレイテンシに敏感な通信でTCPを使うことにはかなりの欠点がある。TCPヘッダーはUDPより2倍以上大きく、追加の制御パケットもあり、古いデータが再送されている間は新しいデータの送信が遅れる。WebSocketsもTCP上で動くので同じ欠点を持つ
      それにもかかわらず、TCPはWebSocketメッセージの配送を保証すると言われるが、パケットロスは再現できた。結局、欠点はそのままで、本当に保証配送が必要ならその上に自前で何かを作る必要があり、それなら最初からUDPの上に必要なメッセージだけそう作ればよかったのではないかと思う
      ネットワーキングは少し触った程度で、知識も経験もほとんどないので、その点は差し引いて見てほしい
    • CJK文字は、表示可能なユニコード文字の中でも非常に大きな割合を占めている。[1] 最大のブロック2つには U+3400〜U+4DBF、U+4E00〜U+9FFF が含まれる
      該当の文字列は \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

  • ゲームを絶対に完成させられない確実な方法は、エンジンを書くことから始めることだ
    自前の技術を作ること自体は十分可能だが、各段階でその技術は汎用ゲームプラットフォームではなく、自分のプロジェクトに合わせたものであるべきだ

    • ブログを始めなきゃ！
      ここで「ブログを始める」というのは、完全にゼロから新しいブログエンジンを作るという意味だ
    • modd.ioのどの部分を指しているのか、もう少し説明してもらえるだろうか？ ゲームを作ろうとして失敗した結果物という意味？
    • エンジンを使う人たちの大半は、そもそもゲームを作りたいのではなく、実はエンジンを作りたい人たちなのかもしれない

  • Node.jsベースのマルチプレイヤーバックエンドは、接続数が増えると結局は這うような遅さになるのを見てきた。これをどう解決したのか気になる
    こういう場合、Go のような代替のほうが良いのでは？

    • なぜそうなるのかはよく分からない。接続面では、NodeのイベントループのおかげでHTTPリクエスト/レスポンス側の入出力ブロッキングは問題にならない気がする
      バックエンドがフロントエンドのために物理演算のような重い処理をしているわけでもなさそうだし
    • uWebSockets(https://github.com/uNetworking/uWebSockets)を使っている。Cで書かれているが、NodeJSで使えるインターフェースがある
      簡単なテストでは、すぐに遅くなる他の人気WebSocketライブラリよりはるかに高性能だった
    • ほとんどの .io ゲームではボトルネックは入出力だと思う。ジャンル名はトップレベルドメインに由来するが、言葉遊びにも見える
      だから Node は良い選択に思える
    • スケーラビリティは、特に接続数が多いときには実際に考慮すべき点になりうる。私たちの場合はバックエンドを最適化して、かなりの数の 同時接続 を効率的に処理できるようにした
      各ゲームは最大64人に制限されているが、100以上の接続までテストしても性能上の問題は見られなかった。各ゲームは分離されたコンテナで実行される

  • 新しいエンジンを作る動機が気になる
    READMEを見ると、武器システム（近接/投射物）、ショップ、クライアント側予測による投射物やユニット移動など、かなり具体的なものが組み込まれている
    なぜこうしたものをエンジンに焼き込み、コピー可能なプラグインにしなかったのか気になる。もちろん多くのゲームではこうした機能は不要だが、これはゲームエンジンなのか？ それともFPS/RPG/その他の特定ジャンル向けエンジンなのか？
    技術そのものが嫌いなわけではないが、それでもなお「なぜ？」という疑問が残る。何のためのものなのか？ なぜThree.jsと自前サーバーではなくこれを使うべきなのか？

    • 質問ありがとう。私たちは、他のモジュール型の代替案よりも、エンジンをより 強い意見を持った構造 にすることを意識的に選んだ。2Dマルチプレイヤーゲームを極めて素早く開発したいからだ
      たとえばシンプルなMMORPGを2時間で作った: https://www.youtube.com/watch?v=GZVsxkALR5U
      使いやすさとカスタマイズ性の間にはトレードオフがあると考えている。私たちは、作るのが難しいとされるマルチプレイヤーゲームと、カジュアルゲーム開発者との間のギャップを埋めるために前者を選んだ
    • 「何のためのものなのか？」
      あなた向けではないのかもしれないし、そういう 特定のゲーム を作りたい人向けのものだ。すべてのエンジンが汎用である必要はない

  • ここにかなり合いそうな趣味プロジェクトをいくつか持っていた。コーディングはできるが、趣味プロジェクトではそこまで集中したくない時もあるので、ローコード と対話型エディタは趣味開発者には良さそうに見える
    個人的に一番楽しみなのはマップとワールド生成だ。ゲームをJSONとしてエクスポートし、プログラムで編集してから再インポートするのが最善の方法に見えるが、そうなのか気になる
    ただ、少し気後れする。手を加えていないチュートリアルワールドでもJSONが3500行あるので、理解すべきことが多い
    最初に思いついた方法は、意図的に編集を加えてJSONがどう変わるかを見ることだ。良いJSON diffビューアも探してみる必要がありそうだ。そうすれば、触りたい部分を見つける助けになるはずだ。アセットとマップタイルは対話型エディタで集めることになりそう
    このアプローチが妥当か、役立つツールがあるのか気になる

    • JSONを直接編集するのは勧めない。かなり読みにくく、肥大化している。modd.ioにはマップを直接編集できる アクション がある
      私たちのコミュニティのある制作者は、ChatGPTでマップを動的生成している。かくれんぼゲームを作っていて、2DマップJSONを生成するようプロンプトを送り、新しいラウンドが始まるたびにそのマップを読み込んでいる。まだ公開されていないのでゲームは共有しにくい
      また、コミュニティメンバーの一人が私たちのゲームJSON用インタープリタを作っている。例: https://pypi.org/project/pymodd/

  • このような オープンソースプロジェクト がもっと出てくるのはうれしい。GitHubスターが100個未満なのは驚きだ

    • 誤解しないでほしいのだが、本当に気になって聞いている。GitHubスターが100未満というのが、なぜ驚きなのか？
    • たぶん、公開されたばかりだからかもしれない