深度解析全链ゲームエンジンMUD

原文我发表在 PANEWS 上面。

伝統的なゲームエンジン#

ゲームエンジンは、ソフトウェアフレームワークを使用して電子ゲームを開発および作成するためのものです。これには、レンダリングエンジン、オーディオ処理、物理シミュレーション、アニメーションシステムなど、伝統的な Web2 ゲームに必要な多くのコア機能が含まれます。ゲームエンジンを使用することで、開発者はゲームデザインとクリエイティビティに集中することができ、技術基盤全体をゼロから構築する必要はありません。ゲームエンジンは、開発者にとって迅速かつ効果的なツールを提供し、開発コストと時間を削減します。

Unity、Unreal Engine、Godot など、多くの有名な Web2 ゲームエンジンがあります。これらのエンジンは、プロの開発者だけでなく、独立した開発者や初心者にも適しています。ゲームエンジンは高度にカスタマイズ可能であり、プロジェクトの要件に応じて調整することができます。通常、これらのエンジンはクロスプラットフォーム開発をサポートしており、開発者はパーソナルコンピュータ、ゲーム機、モバイルデバイスなど、さまざまなデバイス向けのゲームを作成することができます。さらに、多くのエンジンは仮想現実（VR）や拡張現実（AR）のサポートも提供しており、進化する技術ニーズに対応しています。ゲームエンジンには、ゲームの世界、キャラクター、アイテムを簡単に作成するのに役立つ豊富なツールセットも含まれています。これらのツールは、視覚的なシーンエディタ、スクリプトエディタ、アニメーションおよびエフェクトツールなど、効率的なゲーム開発プロセスを実現するのに役立ちます。

フルチェーンゲームエンジン#

ゲームエンジンは、ゲーム開発において非常に重要な役割を果たしています。フルチェーンゲームでも、開発者がゲームロジックを迅速に展開できるツールが必要です。これにより、開発サイクルが短縮され、後続のイテレーション開発やオープンエコシステム内での相互運用性に統一されたデータスタンダードが提供されます。

この領域では、Lattice スタジオによって開発された Solidity ベースのフルチェーンゲームエンジン MUD が比較的成熟しています。MUD を使用すると、開発者はゲームロジックをスマートコントラクトに迅速にデプロイし、契約とクライアントの状態の同期などの機能を実現することができます。これにより、開発効率が大幅に向上します。

注意すべきは、現在のフルチェーンゲームは Solidity 以外にも、StarkNet の Cairo という言語がよく使用されていることです。ただし、MUD は Cairo との互換性が十分にありません。そのため、StarkNet エコシステムの 2 つの活発なプロジェクトである Realms と Briq の創設者は、Cairo ベースのフルチェーンエンジン Dojo を共同開発しました。Dojo のコアコンセプトが MUD と類似しているため、MUD の創設者である Ludens は不満を表明しました。しかし、一連の議論の後、Ludens は最終的に MUD を StarkNet にデプロイするために協力する意思を示しました。

ECS アーキテクチャ#

ゲームエンジンの開発において最も重要な問題の 1 つは、ゲームオブジェクトの表現方法です。ゲームオブジェクトは、制御や相互作用のない単純な 2D 画像から、制御、音声、アニメーション、AI を備えた非常に複雑な 3D オブジェクトまでさまざまです。概念的には、ゲームオブジェクトは、複数の機能を持つエンティティとして理解することが容易です。最初はオブジェクト指向プログラミング（OOP）のアーキテクチャを使用しましたが、現在では ECS アーキテクチャ（Entity Component System）がより一般的です。

ECS は、ロジック、データ、およびエンティティを分離することで、ゲーム開発の柔軟性とメンテナンス性を向上させます。このアーキテクチャパターンは、コードの複雑さを低減し、結合を減らし、パフォーマンスと開発効率を向上させるのに役立ちます。ECS は次の 3 つの主要なコンポーネントで構成されています。

エンティティ（Entity）：エンティティはゲームワールドの基本オブジェクトであり、キャラクターやアイテム、シーンオブジェクトなどが該当します。エンティティ自体にはデータやロジックは含まれず、単に一意の識別子として機能し、コンポーネントとシステムを関連付けるために使用されます。
コンポーネント（Component）：コンポーネントはエンティティの属性やデータを格納するために使用されます。各コンポーネントは特定の特徴や機能を表し、位置、速度、体力などのようなデータを担当します。コンポーネントにはデータのみが含まれ、ロジックは含まれません。さまざまなコンポーネントを組み合わせることで、さまざまな機能や特性を持つエンティティを簡単に作成することができます。
システム（System）：システムはゲームのロジックや振る舞いを処理する責任を持ちます。システムはエンティティが持つコンポーネントに基づいて対応する操作を実行します。たとえば、移動を処理するシステムは、位置と速度のコンポーネントを持つエンティティを検索し、速度に基づいて位置を更新します。システムはエンティティとコンポーネントから独立しており、ゲームロジックをよりモジュール化し、再利用可能にします。

ECS パターンは、伝統的なオブジェクト指向プログラミング（OOP）における継承の深さやコードの再利用の難しさなど、ゲーム開発におけるいくつかの問題を解決するのに役立ちます。ECS により、ゲームオブジェクトの構築がより柔軟になり、さまざまなコンポーネントの組み合わせによって複雑な動作を簡単に作成することができます。さらに、ECS は特に大量のゲームオブジェクトを処理する場合にパフォーマンスを最適化するのに役立ちます。Unity や Godot などの多くの現代のゲームエンジンは、そのコアアーキテクチャとして ECS を採用しています。

フルチェーンゲーム、Web2 ゲーム、さらには一般的な GameFi ゲーム（ゲームアセットはチェーン上にあるが、ゲーム自体はチェーン上にない）は、非常に異なるものです。たとえば、プログラミング言語は主に Solidity を使用し、ゲームオブジェクトの属性状態はスマートコントラクトに格納されます。そのため、オブジェクト指向プログラミングはまったく使用できず、ECS アーキテクチャを採用する必要があります。

Solidity を見てみましょう。実際には、このパターンの変種を無意識のうちに使用しています。たとえば、ERC-20 トークンコントラクトでは、各アドレスのトークン残高がマッピングに格納されます（アドレスから uint256 の残高へのマッピング）。各 ERC-20 コントラクトは、"アドレス" と "残高" の 2 つの列を持つテーブルと見なすことができます。これは、単一の値（"残高"）を持つコンポーネントを持つエンティティに対応します。テーブルの各行は、エンティティ（"アドレス"）とコンポーネントの値（"残高"）を関連付けます。1 つのアドレスは、多くの独立した ERC-20 コントラクトで残高を持つことができ、これは 1 つのエンティティが多くの独立したコンポーネント値に関連付けられることに対応します。現在の ERC-20 の参考実装では、状態とロジックが同じコントラクトに結合されています。ECS では、複数のコンポーネントに状態が格納されており、中央の World コントラクトによってすべての状態更新が登録されるため、MUD はコントラクトとクライアントの状態の同期を提供するためのプラグアンドプレイのネットワークロジックを提供することができます。

もう 1 つの例は、シンプルなビデオゲームです。利用可能なコンポーネントには、"位置" と "ライフ" があります。位置を持つエンティティには位置コンポーネントのエントリがあり、ライフを持つエンティティにはライフコンポーネントのエントリがあります。"移動システム" は、エンティティを 1 つの位置から別の位置に移動するルールを実装します。"戦闘システム" は、エンティティの位置に関連するルールに基づいて戦闘ロジックを実装し、エンティティのライフを変更します。

MUD ゲームエンジン#

MUD は、イーサリアムアプリケーションフレームワークです。その核心は、一連のコントラクトインターフェースとそれらを使用する規約です。これらのコアインターフェースとライブラリにより、周辺ツール、統合、ライブラリの範囲がスムーズに行われ、チェーン上アプリケーションの開発がよりシンプルになります。

MUD には次のような機能があります。

現在

カスタムネットワークコードなしで、コントラクトとクライアントの状態を同期する
ジェネリックインデクサ（カスタムインデックスコードなし）
シームレスなコントラクトアップグレード（+ 開発中の自動コントラクトアップグレード）
コントラクト間での状態の共有
楽観的な更新
コントラクトとシステムの自動生成タイプ
コントラクト状態との対話のためのクエリ言語
コントラクトとローカル状態をチェックおよび変更するためのデータブラウザ
ビットパッキングユーティリティ

将来

ローカルシミュレーショントランザクション（楽観的な状態を含む）
組み込みのアカウント抽象化のサポート
コントラクトパッケージマネージャー

MUD フレームワークには、8 つのライブラリファイルが含まれています。

SOLECS は、MUD のコア Solidity ライブラリであり、チェーン上のコンポーネント、システムなどのインターフェースとリファレンス実装を提供しています。すべての状態がコンポーネントに格納され、すべての状態更新が中央の World コントラクトに登録されるため、MUD はコントラクトとクライアントの状態の同期を提供するためのプラグアンドプレイのネットワークロジックを提供することができます。
RECS は、TypeScript で実装された反応性 ECS ライブラリです。これは、チェーン上のコンポーネントを使用しない場合に独立して使用することもできますが、SOLECS と共に使用することもできます。これにより、クライアント上でチェーン上の状態を同じ形式でミラーリングすることができます。
Services には、上記の方法を使用してチェーン上の状態を同期するためのジェネリックインデクサが含まれています。
Network は、スマートコントラクトとノード間での状態同期を行うためのライブラリです。

Cairo ベースの Dojo は、MUD と非常に似た機能を持つため、MUD を Cairo 言語で再実装したと見なすことができます。そのため、詳細な説明は省略します。MUD の開発者ドキュメントでは、1 日でフルチェーンゲームを開発する方法を具体的な例で説明しています。興味のある方は、公式チュートリアルを参考にしてください：https://mud.dev/tutorials/emojimon/

MUD で開発されたゲーム#

Sky Strife
Sky Strife は、MUD を基に構築されたオンチェーンゲームです。このゲームは、"Ember Crown" を持って戦場から脱出することを争う、高速なリアルタイムストラテジー（RTS）バトルを特徴としています。

Kamigotchi
Kamigotchi は、PvP メカニズムを備えたマルチプレイヤーオンラインロールプレイングアイドルゲームです。プレイヤーは、世界中に散らばるノードから $KAMI を収穫するために自分の Kamigotchi（通称 "Kami"）を使用することができます。$KAMI は、Kami をアップグレードしたり食べ物を購入するために使用できます。ただし、収穫は Kami のライフを消耗します。ライフが低下すると、他のプレイヤーは自分の Kami を狩ることができます。Kami を満たし続け、最大の収穫を得るために注意深く観察する必要があります。死亡は永続的ではありませんが、コア NFT には影響を与えません。ただし、Kami を殺された場合、再びゲーム内で使用することはできません。ただし、一部の消耗品を使用して復活する場合は $KAMI が必要です。さらに、この経験により、Kami の気分が悪くなります。

Muddy Forest
Muddy Forest は、完全にチェーン上で動作する大規模なマルチプレイヤーオンラインリアルタイムストラテジースペースコンクエストゲームです。トランスポート、リソースの送信、惑星の占拠など、ゲーム内のすべてのアクションがブロックチェーン上で行われます。