web3の理想は、ゲーム業界や近年のゲーミフィケーションのトレンドと完全に一致しているようです。 かなり前から、私たちはユニークな体験であるオンチェーンゲームという形で新たな破壊を約束されてきました。 ゲーム業界の既存企業からクリエイティブなエンティティにパワーバランスをシフトする分散化、長い間閉鎖されていた庭の壁を打ち破るコンポーザビリティ、プレイヤーの真の所有権などの特性を備えています。

しかし、これらの強力な理想は、私たちがまだ実際に見たことがないため、脇に置いたままです。 MUDは、オンチェーンゲームのための完全なフレームワークを作成する最初の勇敢な試みであり、次世代のゲームに火をつけるかもしれない火花です。 これは夢物語ではありません。 MUDチームは、短命に終わったものの、Minecraftをテーマにした実際の3Dゲームである OPcraft を完全オンチェーンで担当しています。

従来のゲーム業界からの教訓

革新し、すべてをゼロから構築し、まったく新しい生き物を生み出すことへの執着については、多くのことが言えます。 しかし、ゲームに関しては、デザインパターンと新しいエンジニアリングニッチの創造について、何十年にもわたる教訓があり、真剣に受け止めるべきです。 これらを却下することは、Atari の技術で AAA ゲームを作ろうとするのと同じです。

ゲーム開発の初期段階を覗いてみると、膨大な数の才能と非常に刺激的なプロジェクトがある一方で、調整や明確なフレームワークが不足しているなど、オンチェーンゲームとの紛れもない類似点が見られます。

ビデオゲームの黎明期、ゲームエンジンが登場する前は、信念とデザインパターンを確立していました。 異なるビデオゲームには共通点がほとんどなく、ある時点までは、類似のゲームがまったく異なるコードベースを持つことがありました。 しかし、ゲームエンジンの導入により、すべてが変わりました。

ゲームエンジンとゲーム自体を明確に区別することは困難です。 一般に、ゲームエンジンは、さまざまなゲーム実装を作成するためにわずかに変更および拡張できる一連のルールと設計パターンを備えたフレームワークです。 90年代に入ると、ゲーム開発の細分化が進み、何かが変わり、「ジャンルベース」のゲームエンジンと汎用エンジンの開発が主導権を握りました。 『Doom』や『Unreal』などのゲームには、さまざまなゲームの作成に再利用できるコアコンポーネントがありました。 似たようなジャンルのゲームでも、コアとなるロジックの移植の多くが共有され始めました。 レース、格闘、ファーストパーソンシューティングゲームの開発コストと複雑さは桁違いに減少しました。 不可能を可能にするようになり、何世代にもわたるゲームとアップグレードされたコードが積み重なってきました。 ソフトウェアの観点から見ると、これはゲーム開発が巨大な産業になった主な理由の1つです。

オンチェーンゲームには、いくつかの核心的な問題があります。

1. フレームワークの欠如:どのチームもすべてをゼロから構築しようとしているため、効率が悪く、同じ問題に取り組み、最適なソリューションに向けて最適化するビルダーの経験を集約しても、体系的な知識が不足しています。
2. コードの再利用性の欠如:現在開発されている多くのオンチェーンゲームを例にとってみましょう。 そのうちのいくつをうまくコピーして、わずかに異なるゲームを作成できますか? ゲームの異なるレイヤーやコンポーネントを明確に区別し、同様のコードベースで新世代を構築できるものはいくつありますか? ゲームのための最も重要で相互接続されたオープンソースプロジェクトを作成するという約束は、遠い未来のように思えます。
3. データ構成性の欠如:コードの再利用性にとどまりません。 また、オンチェーンゲームが共有ブロックチェーンの状態を活用して、ゲーム内のゲームAのデータを使用して互いに構築する能力についても重要です。実際には、あるゲームのデータとロジックを別のゲームに組み込むには、多くの作業とリソースが必要です。

MUDのソリューション:

Mudは、保守性、アップグレード性、成形性のための構造を提供することで、オンチェーンゲーム用のエンジンとフレームワークを作成する最初の勇敢な試みです。 mudが提唱するECS(Entity Component System)パターンは、一般的なゲーム開発だけでなく、オンチェーンゲーム開発においても理にかなっています。

スマートコントラクトにおけるECS:

MUDの最も基本的な構成要素はコンポーネントです。 これらは、エンティティに関するデータを格納するデータベースのように機能するデプロイされたコントラクトです。 たとえば、プレイヤーのウォレットのようなエンティティ(アドレス)を考えてみましょう。 アドレスで表されるこのエンティティは、位置コンポーネントの位置値 (x,y)、レベルコンポーネントのレベル 10、コインコンポーネントの 50 など、さまざまなプロパティを持つことができます。 コンポーネントは、マッピングと基本構成のみで構成されます。 システムはより複雑で、コンポーネント内の値を変更するロジックを実装しています。 これは、データベース(コンポーネント)に対するPOSTリクエストのAPIをシステム固有に指定していると考えることができます。 これは、特定のコンポーネントへの書き込みアクセス権が付与されている場合にのみ実行できます。 ここからが面白くなります。 システムは、さまざまなコンポーネントと対話して、詳細なロジックを作成できます。 プレイヤーが行うことができる有効な移動(例:毎回2ステップ)を指定する移動システムや、レベルアップするたびにプレイヤーにコインを与える報酬システムを持つことができます。 これらはすべて「ワールドコンタクト」に登録され、コンポーネントデータの変更の後にはイベントが発行されます。 ワールドコントラクトはパーミッションレスです。 誰でも新しいシステムやコンポーネントを追加できます。 理論的には、異なる世界が互いに相互作用することができます。

ECSをオンチェーンゲームに持ち込むと、OPcraftは10個のコンポーネントと約15個のシステムのみで構成されるという、非常に洗練された構造になります。 この素晴らしいブログ投稿は MUD.dev で確認できます

真のコンポーザビリティ

ECSシステムは、従来のゲーム開発において完全に理にかなっているだけでなく、2つの重要な機能を提供することで、オンチェーンゲームにおいてさらに理にかなっています

1. デプロイされたゲームのアップグレード可能性
2. 最高レベルのコンポーザビリティ

2つの道を想像してみてください。 1つは、基本設計を維持することです。 そしてもう一つは、ゲームのコアロジックの変更です。

プレイヤーが軍隊を組んで互いに戦うことができる標準的なPVP戦略ゲームを考えてみてください。 基本バージョンは 2D でしたが、チームはゲームの詳細な 3D レンダリングを作成することにしました。 必要な作業は、位置に関連するすべてのシステムを取得し、(x,y) ではなく (x,y,z) 座標でアップグレードされたバージョンを作成することだけです。 他のすべてのシステムとコンポーネント(攻撃システム、HP、軍隊の建物など)は同じままでかまいません。 初期の開発チームだけでなく、コミュニティはシステムやコンポーネントを再デプロイすることでゲームのさまざまなMODを作成したり、新しいシステムへの書き込みアクセス権を付与することで同じコンポーネントと対話したりすることもできます(コミュニティ所有のゲームの場合、この種の決定にはさまざまなガバナンスモデルを適用できます)

もう 1 つのアプローチは、新しいシステムに書き込みアクセス権を与えることなく、同じコンポーネントとシステムを維持します。 しかし、ゲーム内の機能を拡張するためのコンポーネントやシステムが追加されると、それはどのようなものになるのでしょうか? 基本的なオンチェーンチェスゲームを考えてみましょう。 ムーブ・システムおよびルール・システムは既にデプロイされています。 人々は現実のチェスをしているかのようにゲームをプレイできますが、チームが追加のレイヤー、つまりマッチメイキングやその他のユースケースの評価システムで構成されるソーシャルレイヤーを作成する必要があると判断した場合があります。 必要なのは、評価コンポーネントと評価ルールを持つシステムを追加することだけです。 これにより、新しいゲームバージョンへの非常にシームレスな移行(UXの改善)だけでなく、スマートコントラクトレベルで異なるバージョンが共存したり、互いに重なり合ったりするための技術的手段も生まれます。 プレイヤーは、同じコアコンポーネントのデータを操作しながら、さまざまなゲームバージョンにとどまることができますが、これはコンポーザビリティアプリケーションとは別に、非常に革新的です。 オプトインの不変性という特徴を生み出し、オンチェーンゲームが提供する別の次元の所有権を生み出します。 さまざまなゲーム資産(スコア、NFT、実績など)の真の所有権は、追加のアップグレードで拡張される可能性があるが、コアでは変更されない不変のロジックによって保護されています。 これは、web3ゲームの主な問題の1つである、クリエイターが同意なしにアセットを弱体化できることを解決します。

クライアント側の全体像:

MUDは進行中のプロジェクトです。 次の部分は最新ではなく、不正確さや大まかな違いが含まれている可能性がありますが、一般的なアーキテクチャが大幅に変更されることは期待されていません。

ここまで、スマートコントラクトレベルでMUDについて調べてきました。 しかし、それだけではありません。 MUDは、クライアントライブラリとレイヤーを備えた完全なスイートを提供します。 MUDにはいくつかのユニークな機能があります。

1. クライアントのコンポーザビリティ
2. クライアントはブロックチェーンの状態変化(ゲームデータ)と完全に同期されています
3. レンダリングレイヤーとしてのPhaserX

より具体的にするために、技術的な詳細に飛び込みましょう。

ネットワーク層:

ネットワーク層は、クライアントの基本層です。 これには、基本設定 (ワールド コントラクト、ゲーム、ネットワーク設定) と、ゲーム インタラクションのための API が含まれています。 ネットワーク層が作成されると、クライアントが対話できるすべての異なるコンポーネントとシステムの仕様があり、特定のコンポーネント/システムのみと対話することを選択できます。 例えば、ゲーム内で動きを作成し、それをフロントエンドで表現したい場合は、位置コンポーネントにデプロイされたスマートコントラクトや移動システムと同期するネットワークレイヤーを作成する必要があります。 これで、位置とゲーム内オブジェクト (エンティティ) を取得し、その位置を設定したり、ある場所から別の場所に移動したりする移動 API を作成できるようになりました。 プレイヤーが Move API を使用するときはいつでも。 彼らはブロックチェーンにトランザクションを送信しようとしています。 移動システムの場合、移動システムのスマートコントラクト内で機能を実行します。

この構造により、マルチクライアントベースのゲームが可能になります。 誰もがユニークなクライアントを作成でき、ブロックチェーンと同期し、ネットワーク層の基本構造に従っている限り、それらはすべて等しく有効です。 マルチクライアントゲームでは、暗い森のように、プレイヤー同士が競い合いながらも異なるクライアントやプラグインを使用するという、非常にクールなユースケースが見られます。 クライアントの構造により、ネットワーク層の埋め込みとAPIの変更により、さまざまなクライアントバージョンを非常に迅速に取得でき、高レベルのクライアント成形性と構成性を実現できます。

クライアントコンポーネントがチェーンコンポーネントとどのように正確に同期するかを尋ねるかもしれません。 これは、オンチェーンゲームのクライアント側を扱う際にビルダーが直面する大きな課題の1つです。 MUDにはいくつかの解決策があります。

まず、MUDはスナップショット機能を導入し、過去のイベントをすべて処理して状態を再構築することなく、クライアントがワールドステート(つまり、コンポーネントごとのエンティティの値)と同期できるようにすることで、レイテンシーが低くなり、複雑さが軽減されました。

また、MUD の ID システムでは、すべてのシステムとコンポーネントが名前に基づいて ID を取得し、デプロイ時にワールド コントラクトに登録されるため、変更の追跡、ゲームの操作、イベントの取得がはるかに容易になります。

レンダリングレイヤー - イベントがいつ、どのようにレンダリングされるか

MUDには「フェイザーの上に構築された非常にスケーラブルなエンジン」であるPhaserXが付属しており、PhaserXは必須ではありません。 OPcraftでは、PhaserXの代わりにNoaボクセルエンジンがあります。 理論的には、構造に従っている限り、任意のエンジンを使用できます。

前述したように、すべてのコンポーネントとシステムはワールドコントラクトに登録されており、変更が発生するとイベントが発行されます(コンポーネントIDやエンティティIDなどの識別データを含む)。 この場合、ECS ストリームサービスは、サブスクライブするイベントを選択するオプションをクライアントに提供できます。

エンティティのグラフィカルな表現は、任意のものにすることができます。 格闘ゲームには、アニメのキャラクター、騎士、さらにはお気に入りの暗号インフルエンサーがいる可能性があります。 それらはすべて、オンチェーンイベントを表し、反応する限り、有効なバージョンです。

免責事項：

1. この記事は【ミラー】より転載、著作権は全て原作者に帰属します【Matchbox DAO】。 この転載に異議がある場合は、 Gate Learn 「Gate Learn」チームまでご連絡いただければ、速やかに対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。