オンチェーンゲーム技術スタック：ゲーム状態をどのように同期するか？

執筆：Fiona，IOSG Ventures

感謝@BriefKandle Creator of @netherscape_xyz, @stokasz CEO@rhascau @mintersworld,@0xcurio team, @SebastienGllmt cofounder@PaimaStudios, @hiCaptainZ, and @SerenaTaN5 の支援と貴重な意見！

TL;DR

• 全チェーンゲーム / 自治世界（「FOG/AW」）は、Web 3 に関する数少ない重要なストーリーの一つです。NFT を通じて Web2.5 に接続するアプリケーションとは異なり、FOG/AW はゲームロジックもチェーン上に置いています。ブロックチェーンをゲームサーバーとして利用し、ゲーム状態の分散型信頼源となります。これにより、持続性、検閲耐性、可組み合わせ性などの利点がもたらされますが、その一方で、これに基づいて構築されるゲームの多様性と複雑性が制限されます。
• ゲームの複雑性とプレイ可能性の要求が高まる中で、エンジンアーキテクチャに対するさらなる挑戦が求められています。例えば、フレームレートの遅延、乱数、ライフ回復、継続的なパッシブ効果、タイマーなどです。この中で、時間の概念や Ticks 単位はブロックチェーン上で異なります。Mud は時間の経過やパッシブ回復スキルをシミュレートするための多くのアイデアを提供しています。例えば、プレイヤーが部屋の中を移動する際、取引に基づいて事前に定義されたデザインに従って部屋の中のすべてのアイテムを移動させることができます。これにより、時間と状態の変化を認識します。
• FOG/AW 技術スタックは、開発者が UI/UX とゲームコアロジックのためにフロントエンドとバックエンドコードを記述し、ゲーム状態のループを通じてすべての変化を同期し、最後にインデクサーが新しい状態をフロントエンドのローカルデバイスに反映させるという形で抽象化できます。
• RTS などの多くのゲームタイプは高い tickrates を必要としますが、コンセンサスによって生成されるブロックチェーンはブロック時間の変化しか処理できず、tickrate はここで解決すべき大きな問題です。Curio と Argus はこの分野のリーダーであり、チェーンのレベルでゲームの tickrate を増加させる方法を模索しています。Mud は、全チェーン上でアプリケーションの状態を EVM に保存することを最大限に実現しようとしています。ゲームのより高い tickrate を実現するためにオフチェーンの組み合わせの解決策を導入していません。
• 異なるチェーンの選択に関して、Dojo は Starknet の全チェーンエコシステムをリードしています。@tarrenceva の説明によれば、Starknet には State diffs 状態差異があり、optimistic rollups とは異なり、出力の実行に重点を置いています。ゲームへの影響は主にコストの最適化に関連している可能性があります。例えば、チェスゲームでは、3 分間のゲーム中に 50 手が行われる可能性があります。状態差異を通じて、単一の証明と最終状態が「出力」を証明できます。一方、optimistic rollups はすべての中間状態の「入力」を必要とします。

FOG/AW の定義：ゲーム状態はどのように同期されるか

FOG であるかどうかを判断する基準は、ゲーム状態がどのように同期されるか（source of truth）です。

Web 2.5 ゲームや従来のマルチプレイヤーゲームでは、現在のゲーム状態を定義するために中央集権的なサーバーがあります。プレイヤーがアクションを送信すると、サーバーはこれらの入力をコンパイルし、更新された結果を接続されている各プレイヤーのデバイスに返します。サーバーはすべての入力（tick）を処理し、不整合の問題を解決し、定期的にプレイヤーに更新を送信し、ゲーム内のすべての要素のスナップショットを提供し、各 tick でゲーム状態を更新します。ゲーム状態（「game state or tick」） は、ゲーム世界の各オブジェクトの属性の時間的スナップショットです。Tickrate は、ゲームサーバーが毎秒計算し、プレイヤーに更新されたゲーム状態をブロードキャストする回数を指します。Tickrate が高いほど、ゲーム体験はより正確で高忠実度になります。一般的に、リアルタイムストラテジーやアクションゲームは高い tickrate を必要とし、カードゲームなどのターン制ゲームはそれほど必要ありません。

出典：https://www.gabrielgambetta.com/client-server-game-architecture.html

完全にチェーン上で動作するゲームでは、ブロックチェーンがゲームサーバーであり、ゲーム状態の分散型信頼源として機能します。この場合、NFT やトークンだけでなく、プレイヤーの ticks やゲームロジックもチェーン上にあります。これが、真の所有権、持続性、検閲耐性、可組み合わせ性を実現できる理由です。理想的には、プレイヤーの各アクションはブロックチェーンに提出され、コンセンサスが達成された後、ゲーム状態が更新され、ローカルデバイスに戻されるべきです。したがって、自然に、tickrate が少ないゲームタイプは完全にチェーン上で行うのに適しています。

ゲームの遅延、時間などの課題を解決する

ゲームの複雑性とプレイ可能性の要求が高まる中で、エンジンアーキテクチャに対するさらなる挑戦が求められています。例えば、フレームレートの遅延、乱数、ライフ回復、継続的なパッシブ効果、タイマーなどです。

フレームレートの遅延 は実際に Web2 の世界でも非常に一般的で、クライアントのレンダリングやユーザー操作による遅延から来ています。特に FPS のような高い tickrate のゲームでは、遅延が発生するとプレイヤーの体験が非常に悪化します。Web2 での解決策の一つは lockstep state update で、すべてのプレイヤーの同期をプレイヤーの中で最も高い遅延の基準に合わせて行い、プレイヤーの公平性を確保します。ブロックチェーンを導入し、取引の確認を待つ必要がある場合、この遅延はさらに深刻になる可能性があります。そのため、Mud はゲーム内で一般的に使用される optimistic rendering（楽観的レンダリング）というメカニズムを導入し、ユーザー操作が成功したと仮定し、サーバーの同意を得る前（またはこの場合、トランザクションの確認前）にクライアントでレンダリングします。

チェーン上での乱数生成 はしばしば議論されるテーマで、Mud はユーザーの行動を乱数結果の入力として使用し、インタラクションが発生した後に生成することができると考えています。

時間の概念や Ticks 単位はブロックチェーン上で異なります。@SebastienGllmt は、詐欺証明の概念を用いたチェーン上（例えば Op）ではタイマーを使用するのが難しいと考えています。なぜなら、一度エラーが発生するとロールバックが必要になり、ゲーム内でタイマーを使用すると体験が非常に悪化するからです。Mud は時間の経過やパッシブ回復スキルをシミュレートするための多くのアイデアを提供しています。例えば、時間の経過とともにコインを増加させ、プレイヤーがコインを必要とする操作を実行するたびに、プレイヤーの以前のコインの数、最近のリフレッシュの数、リフレッシュ率に基づいてプレイヤーのコインの数を計算します。さらに、プレイヤーが部屋の中を移動する際、取引に基づいて事前に定義されたデザインに従って部屋の中のすべてのアイテムを移動させることができます。これにより、時間と状態の変化を認識します。

スクリプト「チート」を書くことは問題ではないかもしれません。 @BriefKandle はゲームシステムの MEV をチートとは考えておらず、スクリプトが簡単に MEV を防ぐことができるかどうかはゲームチームが考慮すべきことです。Web2 のゲーム開発は考え方を変える必要があり、良い MEV ボットはゲーム内の NPC です。

一部の機能は最近リリースされたチェーン上のゲームで実現されています。例えば Rhascau では、タイマーと継続的なパッシブ効果を使用しています。基本的にはブロック時間を尺度として使用しています。（現在の L2 では、ブロック時間 = tickrate）。

FOG/AW 技術スタック

FOG/AW エンジンフレームワークは、開発者がブロックチェーンをサーバーおよび信頼源として利用してゲームを構築できる開発者ツールスタックです。さらに、現在のいくつかの問題を解決できます：

• 標準 / 既製のフレームワークがないため、チェーン上の FOG/AW の構築が非効率的です；
• モジュール化とコードの再利用性が欠如しています；
• 可組み合わせ性が不足しています。FOG/AW エンジンの発展に伴い、チェーン上のゲームはより面白く、想像力豊かになることができます。

理解を容易にするために、この種のエンジンの一般的な簡略化された技術プロセスは、開発者が UI/UX とゲームコアロジックのためにフロントエンドとバックエンドコードを記述し、ゲーム状態のループを通じてすべての変化を同期し、最後にインデクサーが新しい状態をフロントエンドのローカルデバイスに反映させるという形です。

ブロックチェーン上で動作するゲームがこのループをスムーズに実行できるように、Mud、Dojo、Curio、Argus、Paima engine および Lootchain などがそれぞれの技術スタックを開発しています。技術スタックは 3 つの重要な部分で構成されています：チェーン、コア開発スタック、ゲームフロントエンド。彼らはすべて独自の革新を持ち、分散型とゲームの複雑性の間でトレードオフを行っています。

• ゲームフロントエンド：Unity、Unreal などの従来のエンジンや、react/Threejs などの言語と強力なツールを含み、レンダリングなどの機能を提供し、ゲームのプレイ可能性と体験を向上させるために不可欠な要素です。これらのプロジェクトは基本的に関連する SDK を提供しています。
• コア開発スタック：ゲームロジックをブロックチェーン上で実行し、適時にフロントエンドに同期できるようにするためのソリューションを設計します。重要なコンポーネントには、適切なデータベース構造（ゲームの行動とロジックを定義）や、ゲーム状態の同期と返却が含まれます。
• チェーン：ほとんどが Ethereum、Optimism、Starknet 上に構築されています。

下の図は、異なるプロトコルがどのようにそれぞれの技術スタックを設計しているかを示しています。Mud V2 の運用フローを例に見てみましょう：

1. 開発者は Mud でいくつかの Web2 のフロントエンドツールを呼び出してコードを記述し、これらの強力な機能を利用してゲームをより視覚的に楽しく見せます；
2. 同時に、開発者は Mud のスマートコントラクトフレームワーク（Mud World）を利用してゲームのキャラクター、アイテム、および具体的な運用ロジックを記述します。例えば、ヒーロー A が X から Y に移動し、Y の土地を攻撃する際に、どの程度の確率またはどのような状況でその土地を占領できるかを決定します；
3. 上記のアクションおよびゲーム状態は Mud Store に記録されます。これはチェーン上のデータベースで、グローバルなゲーム状態を管理し、ゲーム状態の同期の信頼源となります；
4. ヒーロー A が Y に攻撃を行うのは、実際にはプレイヤーがフロントエンドのローカルマシンでマウスをクリックし、そのコマンドをチェーン上に送信したことを意味します。このコマンドは、開発者のゲームデザインロジックおよび現在の Store にあるゲーム状態に基づいて結果を生み出し、その結果が新しいゲームのグローバル状態に更新され、チェーン上に同期されます；
5. Mud 上のゲームは Web、Mobile などさまざまなフロントエンドをサポートしていますが、複雑なインデックス要求に直面する可能性があります。Mode はそのために開発されたオフチェーンインデクサーです。

さて、これらのコアフレームワークの共通点と異なる設計について話しましょう。

• 彼らの大多数は Mud v1 の設計に従い、ECS をゲーム開発のデータ構造として利用しています。これはゲームロジックの記述と提示の方法です。Mud V2 はこれを改善し、データが Tables と Systems に定義され、他のデータ標準（V1 の ECS データモデリング標準に従う必要はありません）を許可します。これにより、開発者により多くの選択肢が与えられ、より包括的になります。
• 大多数は分散型データベースを使用しています。なぜなら、ブロックチェーンは自然にゲーム状態とデータベースの信頼源だからです。Mud は全チェーン上でアプリケーションの状態を最大限に実現しようとしています。ゲームのより高い tickrate を実現するために、分散型を犠牲にしたり、オフチェーンの組み合わせの解決策を導入したりしていません。
• FPS などの多くのゲームタイプは高い tickrates を必要としますが、コンセンサスによって生成されるブロックチェーンはブロック時間の変化しか処理できず、tickrate はここで解決すべき大きな問題です。Curio と Argus は独自の革新設計において、チェーンのレベルで tickrates を増加させることを最初に望んでいます。
• 異なるチェーンの選択に関して、Curio と Loot は Caldera を利用して Op stack chain を構築しています。さらに、Dojo は Starknet の全チェーンエコシステムをリードしています。@tarrenceva の説明によれば、Starknet には State diffs 状態差異があり、optimistic rollups とは異なり、出力の実行に重点を置いています。ゲームへの影響は主にコストの最適化に関連している可能性があります。例えば、チェスゲームでは、3 分間のゲーム中に 50 手が行われる可能性があります。状態差異を通じて、単一の証明と最終状態が「出力」を証明できます。一方、optimistic rollups はすべての中間状態の「入力」を必要とします。

現在、これらのエンジンの上に構築されたゲームがいくつか存在し、Mud と Dojo は開発者を引き付けるためにハッカソンを開催しています。Curio も ETHCC で Warcraft のミニゲームデモを発表したばかりです。

明らかに、FOG/AW はパブリックチェーンの競争の重要なエコシステムとなりつつあります。Lattice が提唱する AW（自治世界）は非常に大きな概念で、ゲームに限らず、ソーシャル、金融など多くの属性を含んでいます。したがって、これに基づいて構築されるのは、想像力に満ちた仮想世界、すなわちメタバースです。新しい形態のゲーム、ソーシャル、金融などの融合アプリケーションが期待できます。

参考文献:

1.https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY

2.https://jumpcrypto.com/writing/defining-on-chain-gaming/

3.https://www.oneqode.com/what-is-a-game-server/

4.https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950

5.https://latticexyz.notion.site/Building-Autonomous-Worlds-with-MUD-39d5eb5d31034589bc54a2053efb4c56

6.https://twitter.com/tarrenceva/status/1660686571270705152

7.https://book.dojoengine.org/framework/sozo/overview.html

8. https://www.youtube.com/watch?v=A0OXif6r-Qk