フルチェーンゲームの未来："MUD ECSエンジンの約束"

Web3のアイデアは、ゲーム業界や近年のゲーミフィケーションのトレンドにぴったりと当てはまるようだ。ここしばらくの間、私たちはオンチェーンゲームというユニークな体験という形で、新たな破壊を約束されてきた。非中央集権化によってゲーム業界の既存企業からクリエイティブな主体へとパワーバランスがシフトすること、コンポーザビリティによって長い間閉ざされていた庭の壁が取り払われること、そしてプレイヤーによる真の所有権といった特徴だ。MUDは、次世代のゲームに火をつけることができるオンチェーンゲームの完全なフレームワークを作成する最初の勇敢な試みです。

伝統的なゲーム業界からの教訓

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

ゲーム開発の初期段階を振り返ってみると、オンチェーンゲームとの明確な類似点が見て取れます：多くの才能と非常に刺激的なプロジェクト、しかし協調性と明確なフレームワークの欠如。

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

ゲーム エンジンとゲームそのものを明確に区別することは困難です。一般的に言えば、ゲームエンジンは、ルールとデザイン パターンのセットを持つフレームワークであり、さまざまなゲームの実装を作成するために少し変更したり拡張したりすることができます。1990 年代までに、何年にもわたって断片的なゲーム開発が続いた後、状況は変化し、「タイプ ベース」のゲーム エンジンと、汎用エンジンを開発するためのいくつかの取り組みが優勢になりました。Doom」や「Unreal」のようなゲームのコア コンポーネントは、さまざまなゲームを作成するために再利用することができ、似たようなジャンルのゲームは、コアロジック インプラントの多くを共有するようになりました。レース ゲーム、格闘ゲーム、一人称視点のシューティング ゲームの開発コストと複雑さは、桁違いに低下しました。不可能が可能になり、何世代ものゲームとアップグレードされたコードが蓄積されました。ソフトウェアの観点からは、これがゲーム開発がこれほど巨大な産業になった主な理由の1つです。

オンチェーン ゲームには、いくつかの核となる問題があります。すべてのチームがゼロからすべてを構築しようとするため、非効率になり、ビルダーがどのように同じ問題に対処し、最良のソリューションを最適化するかについての、集約された経験と体系的な知識が不足してしまいます。

MUDの解決策:

MUDは、メンテナンス可能で、スケーラブルで、変更可能な構造を提供する最初の勇気ある試みです。構造を提供する最初の勇気ある試みです。MUDが提唱するエンティティ・コンポーネント・システム（ECS）モデルは、ゲーム開発全般にとって理にかなっており、オンチェーンゲーム開発にとってはさらに理にかなっています。

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

MUDにおける最も基本的な構成要素はコンポーネントです。コンポーネントは、エンティティデータを格納するデータベースのように機能するスマートコントラクトです。例えば、プレイヤーのウォレットアドレスなどのエンティティ（イーサアドレス）があります。このアドレスは、Locationコンポーネントのlocation (x,y)、Levelコンポーネントのlevel 10、Tokenコンポーネントのvalue 50といった異なる属性を持つことができるEntityを表し、Componentはマッピングと基本的な設定のみを含みます。

システムはより複雑で、コンポーネントの値を変更するロジックを実装します。システムの指定したデータベース（コンポーネント）に対するPOSTリクエストAPIと考えることができ、そのコンポーネントへの書き込みアクセス権を持っている場合にのみ、特定のコンポーネントにデータを書き込むことができます。システムは異なるコンポーネントと相互作用して、詳細なロジックを作成することができます。例えば、プレイヤーが移動できる有効な歩数（一度に2歩など）を指定する移動システムがあり、プレイヤーがレベルアップするたびにゴールドを与える報酬システムがあるかもしれません。

これらすべてがワールドコンタクトに登録され、コンポーネントデータの変更ごとにイベントが発生します。ワールドコントラクトはライセンスフリーで、誰でも新しいシステムやコンポーネントを追加することができます。理論的には、異なるワールドコントラクトは相互に作用することができます。

オンチェーンゲームにECSを導入することで、非常にエレガントな構造となり、OPcraftはわずか10個のコンポーネントと約15個のシステムで構成されます。

True Composability

True Composability

ECSシステムはウェブだけのものではありません。

1. ECSシステムはウェブだけのものではありません。

2. 配置されたゲームのスケーラビリティ

3. 最高度のコンポーザビリティ

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

標準的なPVP戦略ゲームを想像してください。基本バージョンは 2D ですが、チームはゲームの 3D レンダリングを作成することにしました。必要なのは、場所に依存するすべてのシステムを取得し、(x,y)座標の代わりに(x,y,z)座標を使用してアップグレード版を作成することだけです。他のすべてのシステムおよびコンポーネント（攻撃システム、生命体、軍用建物など）は変更せずにそのままでよい。コミュニティは、システムやコンポーネントを再配置することで、ゲームの異なるモジュール（Mod）を作成することができ、新しいシステムへの書き込みアクセスを許可することで、同じコンポーネントと相互作用することもできます（コミュニティ所有のゲームの場合、さまざまなガバナンスモデルを使用して、このような決定に投票することができます）。

同じコンポーネントとシステムを維持し、新しいシステムへの書き込みアクセスを許可せず、その代わりにコンポーネントとシステムを追加することでゲーム内の機能を拡張する、別のアプローチとはどのようなものでしょうか？チェーン上の基本的なチェスゲームを考えてみよう。手とルールシステムはすでに配備されている。人々は、あたかも現実のチェスのようにゲームをプレイすることができますが、おそらくあなたのチームは、マッチングやその他のユースケースのためのレーティングシステムを含むソーシャルレイヤーという追加のレイヤーを作成することを決定するでしょう。必要なのは、レーティング・コンポーネントとレーティング・ルールを持つシステムを追加することだけです。これにより、ユーザーをゲームの新しいバージョンに移行するのが非常にシームレスになるだけでなく（より良いユーザーエクスペリエンス）、スマートコントラクトレベルで異なるバージョンを共存させたり、重ね合わせたりするための技術的な手段も作成されます。プレイヤーが同じコア・コンポーネントのデータとやり取りしながら、異なるバージョンのゲームでプレイできるという事実は、コンポーザビリティの応用に加えて非常に革新的です。これは、インバリアントへのオプトインの能力を生み出し、オンチェーンゲームが提供する所有権の別の次元を作り出します。さまざまなゲーム資産 (スコア、NFT、実績など) の真の所有権は、追加のアップグレードで拡張できるが、そのコアは変更されない不変のロジックによって保護されます。これは、Web3 ゲームの主な問題の 1 つである、クリエイターが同意なしにアセットを無効にできるという問題を解決します。

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

MUDは進行中であることに注意してください。次のセクションは最新ではなく、不正確な記述もあるかもしれませんが、全体的なアーキテクチャは劇的に変わることはないはずです。

ここまでは、スマートコントラクトレベルでMUDを見てきましたが、それだけではありません。MUDはクライアントサイドのライブラリとレイヤーのスイート全体を提供し、 MUD はいくつかのユニークな機能を持つように設計されています。strong>ブロックチェーンの状態変化（ゲームデータ）と完全に同期するクライアント

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

ネットワーク層はクライアントの基本層です。ネットワーク層は、クライアントが相互作用できるすべての異なるコンポーネントとシステムの仕様で作成され、特定のコンポーネント/システムとのみ相互作用するように選択できます。

たとえば、ゲーム内で動きを作成し、フロントエンドでそれを表現したい場合、位置コンポーネントとデプロイするためのスマートコントラクトと、移動システムと同期するためのネットワークレイヤーを作成する必要があります。これで、場所とゲーム内のオブジェクト（エンティティ）に作用し、それらの位置を設定したり、ある場所から別の場所に移動させたりするMove APIを作成できる。プレイヤーが移動APIを使用できるときはいつでも、ブロックチェーンにトランザクションを送信する。移動システムについては、移動システムのスマートコントラクトの機能を実行することになる。

この構造により、マルチクライアントベースのゲームが可能になります。誰もがユニークなクライアントを作成でき、ブロックチェーンと同期し、ネットワーク層のインフラに従う限り、すべて等しく有効です。私たちは、プレイヤー同士が競い合いながらも異なるクライアントやプラグインを使用する「ダークフォレスト」のような、マルチクライアントゲームの実にクールなユースケースを見てきました。クライアントの構造により、私たちはネットワーク レイヤーに移植し、API を変更して異なるクライアント バージョンを非常に迅速に取得することができます。

クライアント・コンポーネントがチェーン・コンポーネントとどのように同期しているのか尋ねるかもしれません。これは、連鎖するゲームクライアントを扱うときに開発者が直面する大きな課題の1つであり、MUDにはいくつかの解決策があります。

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

さらに、MUDのIDシステムは、各システムとコンポーネントがその名前に基づいたIDを取得し、デプロイされたときにWorldコントラクトに登録されるため、変更の追跡やゲームとのやり取りが簡単になります。

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

MUDには、「Phaserの上に構築された拡張性の高いフレームワーク」であるPhaserXが付属しています。PhaserXは必須ではありません。OPcraftでは、PhaserXではなく、Noaボクセルエンジンが使用されています。理論的には、構造に従っている限り、どんなエンジンでも使用することができます。

前述のように、各コンポーネントとシステムはWorldコントラクトに登録され、変更が発生するとイベント（コンポーネントIDやエンティティIDなどの識別データ）が発生します。ここでECS Streaming Serviceは、サブスクライブするイベントを選択するオプションをクライアントに提供できる。

エンティティのグラフィカルな表現は、どのようなものであってもかまいません。格闘ゲームでは、アニメのキャラクターや騎士、あるいはお気に入りの暗号ドメインのKOLであってもかまいません。オンチェーンイベントを表現し、それに反応する限り、それらはすべて有効なバージョンです。

元記事へのリンク：https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY