今回は、MatchboxDAOの「The future of on-chain gaming: ‘The promise of MUD ECS engine’」という素晴らしい英文記事について、MatchboxDAOのLouthing氏に許可を取った上で日本語訳＆加筆させていただきました。
さて、そんなMatchboxDAOが先日ブログを更新し、StarkNetではなくOptimismでオンチェーンゲーム（Autonomous World）の構築をサポートするオープンソースツール「MUD」についてピックアップしていました。
また、それらの理解を終えた後で、実際にECSパターンやMUDエンジンを用いて構築されているオンチェーンゲーム（Autonomous World）の事例についても概観していきたいと思います。
ということで本記事では、「The future of on-chain gaming: ‘The promise of MUD ECS engine’」の内容を筆者なりに分かりやすく一部改変してお伝えするとともに、MUDの概要やその発展可能性、実際に開発が進められているオンチェーンゲーム（Autonomous World）事例などについての理解を深めていただくことを目的とします。
でははじめに、この記事の構成について説明します。
まずは、MUDやECSとは何なのかについて簡潔に概要をまとめて解説していきます。
続いてMatchboxDAOの記事をベースに、MUDやECSがオンチェーンゲーム開発においてどのように革新的なのかについて深掘りし、さらにオンチェーンゲームの未来像についての理解を促進していただくことを目指します。
最後に、執筆時点で開発が進められているオンチェーンゲーム（Autonomous World）の事例について概観していきます。
本記事が、ECSパターンやMUDエンジンの概要およびその可能性、およびオンチェーンゲーム（Autonomous World）開発事例などについて理解したいと思われている方にとって、少しでもお役に立てれば幸いです。
※本記事は一般的な情報提供を目的としたものであり、法的または投資上のアドバイスとして解釈されることを意図したものではなく、また解釈されるべきではありません。ゆえに、特定のFT/NFTの購入を推奨するものではございませんので、あくまで勉強の一環としてご活用ください。
イーサリアムnaviの活動をサポートしたい方は、「定期購読プラン」をご利用ください。
前提：MUDの概要・発展可能性について簡潔におさらい
本章では、スムーズに本題についての内容理解を深めていくために、「MUD」の概要について簡潔に解説していきます。（※既にMUDについてご存知の方は本章を読み飛ばしていただき、次章から読み進めてください。）
なお、より詳しくMUDについて深掘りして知りたいという方は、以下記事にまとめてありますので合わせてご参考ください。
「MUD」とは何か
昨今では、世界中のクリプトコアな人たちを中心に「オンチェーンゲーム開発」が行われている状況です。
Dark ForestやIsaacなど先進的な事例を見て、「私もオンチェーンゲーム開発をやってみたい！」と思われた方もいらっしゃったのではないかと思います。
そこで本章は、Optimismエコシステムでオープンソースライブラリなどを提供し、そのような課題解決をサポートしてくれる「MUD」についてピックアップしていきます。
MUDは、Autonomous Worldsを構築するためにつくられた、オープンソースのツールです。
オンチェーンゲームを超える概念として「Autonomous World」を提唱しており、それをEthereumエコシステム上で構築する際の全ての困難な問題を解決するために、オープンソースライブラリを提供しています。
また、オープンソースにするために、コンポーザビリティの高い設計がなされている点も特徴的です。
MUDでは「ECSパターン」を採用しています。
ECSとは「エンティティ・コンポーネント・システム」の略称であり、主にゲーム開発で使用されているソフトウェアアーキテクチャパターンを指す単語です。
その名の通り、エンティティ/コンポーネント/システムという3つの基本的な構成要素からなります。
開発元であるLatticeチームは当初、Autonomous Worldをオンチェーンで構築するにあたり、コードの
- maintainability(メンテナンス性)
- composability(構成可用性)
- mudulability(調節可用性)
に大きな問題を抱えていました。
では、ECSが先に述べてきた課題をどのように解決できるのかについて見ていきます。
まず、ECSではその名の通り、「エンティティ」「コンポーネント」「システム」の3つが、基本的な構成要素です。
- エンティティ（空箱）
- 単なるID（uint型）であり、ロジックやデータを格納していない
- コンポーネント（データ）
- データを格納し、「エンティティにアタッチ（添付）」することが可能
- 「プロパティ」と考えることもできるが、データはクラスのプロパティとは異なる方法で構造化されている
- システム（ロジック）
- ロジックを実行する
- コンポーネントだけを扱い、エンティティは扱わない
ECSについての理解を深めるために、ここでは「Movable」「Combat」「Inventory」という3つのコンポーネントを作成するケースを想定してみましょう。
コンポーネントは単なるデータであり、処理の内容などは一切含みません。
ロジックを実行するための処理は「システム」として分けて扱われますが、ここでは以下3つのシステムを追加します。
- MovementSystem
- Movableコンポーネントを持つあらゆるエンティティの移動を処理する
- CombatSystem
- Combatコンポーネントを持つあらゆるエンティティの戦闘を処理する
- InventorySystem
- Inventoryコンポーネントを持つあらゆるエンティティの在庫を処理する
これにて、エンティティの実装は非常にシンプルかつ簡単になりました。
加えて、「ここから更に多くの種類のエンティティを追加したい！」と思った場合でも、シンプルかつ簡単に実装することができるようになり、より保守性の高いコードを記載することが可能になります。
しかし、ここで最も重要な点は、ECSパターンが「全く新しいレベルの高いコンポーザビリティを開放してくれること」にあります。
各システムは限られたコンポーネントにしか対応しないため、ロジックは高度に分離されると同時に、非常に拡張しやすい構造になっています。
それによって生まれる発展可能性
ゲームエンジンのSolidityの部分の話をすると、各コンポーネントはそれ自身がコントラクト（○○.sol）であり、さらに各コンポーネントが自身のことを記録するための「Worldコントラクト」が中心に存在します。
これにより、各コンポーネントの値が変わるたびにWorldコントラクトはイベントを発し、クライアントはそれを受信することでローカルステートを表すことが可能になります。
これまで学んできたように、コンポーネントには一切のロジックはなく「データのみ」が格納されており、ロジックは全てシステムに実装されています。
そして、各コンポーネントがWorldコントラクトに自身のことを記録するのと同じように、全てのシステムもそれ自体がコントラクト（○○.sol）なのです。
さらにWorldコントラクトの特筆すべきポイントは、「所有者がおらず、パーミッションレスであること」です。
全てのコンポーネント・システムは各自インターフェイスを実装しつつもWorldコントラクトに記録がなされているので、クライアントをフォークする必要がなく、新しいコンテンツが追加されたら自動的に表示させるといったことが可能になります。
よって、MUDを使ってオンチェーンゲームを構築する人々は、ゲームをフォークしているわけでも、自分たちの世界を作っているわけでもありません。彼らは、既に存在している「Autonomous World」に対して、新しい機能を追加していくことになるのです。
【和訳&加筆】オンチェーンゲームの未来: 「MUD ECSエンジンが果たす約束」
本章では、「The future of on-chain gaming: ‘The promise of MUD ECS engine’」の内容を一部和訳しつつ、筆者なりに要所ごとに分かりやすく読み進められるよう加筆していきます。
web3が追い求める理想は、ゲーム業界や近年のゲーミフィケーションの流れにぴったり合っているように思います。
かなり長い期間、私たち（MatchbocDAO）はオンチェーンゲームというユニークな体験を通して、新たな変革を期待されてきました。
「分散化」によって、パワーバランスが既存ゲーム業界の事業者からクリエイティブな人々へと移行し、さらに「コンポーザビリティ」によって長く閉ざされていた庭の壁がなくなり、プレイヤーに真のオーナーシップ（※以降、本記事では”保有権”と記載）が与えられるのです。
しかし、これらの強力なweb3の理想はまだ実現されていないため、残念ながら脇役となってしまっているのが現状です。
そんな中で今回ご紹介する「MUD」は、オンチェーンゲームのための完備されたフレームワークを構築するという最初の勇敢な試みであり、次世代のゲームの火付け役となる可能性を秘めています。
これは夢物語ではありません。実際に短期間でMUDチームは、3D Minecraftをテーマにしたゲーム「OPcraft」をフルオンチェーンで構築しているのです。
「OP Craft」を概観
OP Craftは「自律型ボクセル世界」を標榜する、オンチェーン（OP Stack）の3Dボクセルゲームです。
2022年10月18日に正式ローンチされた本ゲームは、LatticeチームとOptimismチームの技術協力により誕生しました。
オンチェーンゲームエンジン「MUD」と、Optimismの「OP Stack」を組み合わせることにより、3DのAutonomous Worldを構築しています。
OP Craftの世界を構成する全ての要素（川・草の葉・山など)や、状態、ユーザーの行動履歴などはオンチェーン情報として格納され、最終的にEthereum（L1）のトランザクションとして記録されます。
従来のゲーム産業からの教訓
- イノベーションを起こそう
- すべてを一から作り上げよう
- まったく新しい生命体を作り上げよう
といったある種の強迫観念について、今日では多くのことが語られるでしょう。
しかしゲームに関して言えば、設計パターンと新しいエンジニアリングニッチの作成には何十年にもわたる教訓があるわけですから、これについて我々は真剣に受け止めておく必要があります。
これらを無視することは、Atari(ゲーム会社)の技術でAAAゲームを作成しようとすることと同じくらい無謀なことです。つまり、料理人が低品質の材料で素晴らしい料理を作ることはありません。
そしてゲーム開発の黎明期に目を向けてみると、膨大な才能と非常に刺激的なプロジェクトがある一方で、『調整や明確なフレームワークが欠如している』という、紛れもなく今のオンチェーンゲームと同じような状況が見受けられたのです。
ビデオゲームの黎明期、つまりゲームエンジンが登場する以前の段階では、それぞれのゲームで確立された個別のルール・設計パターンがありました。
見た目は同じようなゲームでも、ビデオゲームAとビデオゲームBの間にはほとんど共通点がない（コードベースがまったく異なる）といったことも、多々ありました。
しかし、ゲームエンジンが登場したことで、すべてが変わりました。
「ゲームエンジン」と「ゲームそのもの」を明確に区別することは困難ですが、一般的にゲームエンジンはルールや設計パターンが決まっているフレームワークを指し、それを少し修正・拡張することで様々なゲーム実装をおこなうことができます。
何年にもわたる断片化されたゲーム開発の後、1990年代に差し掛かった頃には何かが変化し、「ジャンルベース」のゲームエンジンと汎用エンジンを開発するいくつかの取り組みが主流となったのです。
DoomやUnrealのようなゲームには、さまざまなゲームを作成するために再利用できるコアコンポーネントがあり、似たようなジャンルのゲーム間でコアロジックの移植/埋め込みが多くおこなわれるようになりました。
以上を踏まえて現状のオンチェーンゲームを俯瞰すると、いくつかの核となる問題を抱えています。
- 「フレームワーク」の欠如
- 現状オンチェーンゲームでは、各チームが0からすべてを構築しようとしているため、効率が悪いです。「同じ問題に取り組んでいるビルダーの経験を集約したり、最適なソリューションに向けて最適化するためのシステム的な知識」が欠如しています。
- 「コードの再利用性」の欠如
- 現在開発されているオンチェーンゲームの多くを見てみましょう。その中で、少し違うゲームを作るために上手くコピーできるものはいくつあるでしょうか？ゲームのさまざまなレイヤーやコンポーネントを明確に区別して、同様のコードベースで新しいオンチェーンゲームを構築できるものはいくつありますか？お分かりのとおり、ゲームのために最も重要な「相互接続されたオープンソースプロジェクトを作るという約束」は、はるか彼方にあるようです。
- 「データコンポーザビリティ」の欠如
- ②のコードの再利用性だけの話では収まらず、オンチェーンゲームがブロックチェーンの共有ステートを活用し、ゲームAのデータをゲームBで使って互いに構築するという機能についても同様の課題です。実際、一般的なゲームAのデータやロジックを、他のゲームBに組み込むためには、多くの労力とリソースが必要です。
MUDのソリューション
MUDは、Maintainability（メンテナンス性）、Upgradability（アップグレーダビリティ）、Mudulability（調節可用性）のための構造を提供することで、オンチェーンゲームのためのエンジンとフレームワークを作成するという、最初の勇敢な試みです。
スマートコントラクト×ECS
MUDの最も基本的な構成要素は「Components（コンポーネント）」であり、これは『エンティティに関するデータを保存するためのデータベースのような、デプロイされたコントラクト』に当たるものです。
例えば、「プレイヤーAさんのウォレットアドレス」のようなエンティティ（address）について考えてみましょう。このAさんのアドレスというエンティティは、
- 位置情報として位置値（x,y）
- レベル情報としてレベル10
- コイン情報として50
など、さまざまなプロパティを持つことができます。
また、このコンポーネントは、mapping（マッピング）と基本的なconfig（設定）のみというシンプルな構成で成り立っていることも特徴的です。
一方、Systems（システム）の方はもっと複雑で、コンポーネントでvalue（数値）を書き変えるといった「ロジック」を実装しています。
これは、データベース（コンポーネント）に対するPOSTリクエストのためのAPIを、システムが規定していると捉えることもできます。
つまり、特定のコンポーネントへの書き込み権限がある場合にのみ書き込みが可能になるのですが、ここからがECSパターンの面白いところです。
まず第一に、システムは異なるコンポーネントと相互作用して、詳細なロジックを作成することが可能です。
プレイヤーができる有効な動き（例えば1度につき2歩動く）を指定する移動システムや、レベルアップするたびにコインがもらえる報酬システムなどを搭載することができます。
そして第二に、これらはすべて “Worldコントラクト（上写真中央の地球アイコン）“に登録され、コンポーネントのデータが変化するたびにイベントが発生するようになっています。
Worldコントラクトはパーミッションレスです。誰でも新しいシステムやコンポーネントを追加することができます。理論上は、異なる世界（Worldコントラクト）同士が相互作用することも可能です。
先に述べたOPcraftは、このECSをオンチェーンゲームに導入することで、10個のコンポーネントと15個程度のシステムだけで構成されるようになり、非常に洗練された構造のオンチェーンゲームとなっています。
真のコンポーザビリティ
ECSシステムは、従来のゲーム開発において完璧な効果を発揮するだけでなく、以下の2つの重要な機能を提供することで、オンチェーンゲームにおいて一層その真価を発揮するようになりました。
- 一度デプロイされたゲームのアップグレーダビリティ（アップグレード可能性）
- 最高レベルのコンポーザビリティ
2つの方法で上記を考えてみます。1つは「ゲームのコアロジックを変更して上記を達成する方法」、そしてもう1つは「基本設計を維持しつつ上記を達成する方法」です。
前者「ゲームのコアロジックを変更して上記を達成する方法」の場合
一般的なPVPストラテジーゲームで、プレイヤー同士が軍隊を作って戦うケースを想定してみましょう。このとき、『基本バージョンは2Dだが、開発チームは今後3Dレンダリング版を作成したいと考えている』とします。
ここで開発チームがおこなう必要があるのは、すべての位置関連のシステムを取得し、(x,y) の代わりに (x,y,z) 座標でアップグレードされたバージョンを作成すること『ただそれだけ』であり、他のシステムやコンポーネント（攻撃システム、HP、軍団構築など）は変わらずそのままで問題ありません。
これであれば、初期の開発チームの枠を超えて、コミュニティがシステムやコンポーネントを再度デプロイすることで異なるゲームのMod（改造版）を作成したり、新しいシステムへの書き込みアクセスを許可することで同じコンポーネントと相互作用することもできるはずです。（コミュニティ所有のゲームであれば、この種の決定にはさまざまなガバナンスモデルが適用されます）
後者「基本設計を維持しつつ上記を達成する方法」の場合
これが意味するのは、新しいシステムに書き込み権限を与えることなく同じコンポーネントやシステムを維持することですが、この場合ゲーム内の機能を拡張するためのコンポーネントやシステムを追加すると、どのように見えるでしょうか？
ここでは、基本的なオンチェーンチェスゲームを例に考えてみましょう。
移動やルールに関するシステムは、既にデプロイ済みです。
人々は実際のチェスをプレイしているかのようにゲームをプレイできますが、あなたの開発チームは追加のレイヤー、つまり「マッチメイキング」やその他のユースケースのためのrating system（評価システム）で構成される「ソーシャルレイヤー」を作成する必要があると判断するかもしれません。
このとき必要なのは、RatingComponent（レーティングコンポーネント）と、評価ルールを持つRatingSystem（レーティングシステム）を追加すること、ただそれだけです。
これによりプレイヤーは、同じコアコンポーネントのデータを操作しながら、様々なバージョンのゲームに参加することができるようになり、コンポーザビリティアプリケーションとはまた違った非常に革新的な体験が可能となります。
これが「不変性の保持」という特徴を生み出し、オンチェーンゲームが提供することになる『保有権とは別次元のもの』を作り出します。
さまざまなゲームアセット（スコア、NFT、達成度など）の真の保有権は、追加アップグレードで拡張される可能性はありますが、そのコア部分は変更されない不変のロジックによって保証されているのです。
これは、Web3ゲームの大きな問題の1つである『クリエイターが勝手にアセットをナーフできる状態』という問題を解決すると同時に、これこそが「オンチェーンゲームの未来」であると私たちは考えています。
- クライアントのコンポーザビリティ
- ブロックチェーンのステート変化（ゲームデータ）に完全に同期したクライアント
- レンダリングレイヤーとしてのPhaserX
興味がある方は、ぜひ出典元の記事「The future of on-chain gaming: ‘The promise of MUD ECS engine’」をご参考ください。
MUDやECSパターンに関する最近の事例をいくつか紹介
MUDの概要記事で紹介した「OP Craft」と「Sky Strife」以外に、現時点でもMUDならびにECSパターンを活用したオンチェーンゲームが多数開発されている状況です。
本章では、MUDやECSパターンに関する最近の事例をいくつか紹介していきたいと思います。
Treaty（by Curio）
Curioは、クリプトのコンポーザビリティ（構成可用性）とスマートコントラクトの力を通じて、豊かで広範なソーシャルインタラクションを作成するためのゲーム構築に焦点を当てたクリエイティブグループです。
そんなCurioが構築している「Treaty」は、プレイヤーが新しい国や統治構造、そしてユートピアの国における新しい生き方を創り出すことがコンセプトのオンチェーンゲームです。
Treatyに参加したユーザーは、スマートコントラクトで定義された条約に同意したものとみなされ、互いのユーザーを攻撃することを禁じられます。
Treatyで定義されたルールはゲームのコア機能に直接組み込まれているため、参加ユーザーには貿易（transferFromやapprovalなどの関数）の条件が厳密に適用されます。
建物や軍隊などゲームオブジェクトがスマートコントラクトウォレットとして表現されており、DeFiやメタバースの文脈でも興味深いゲームであるという所感です。
また、本ゲームはMUDを用いておらず、ゲーム内のキャラクターにトークンを付与するためのスマートコントラクトやトークン化レイヤー、AA(Account Abstraction)レイヤーなどを備えた「独自のECSゲームエンジン」をベースに設計されている点も特徴的です。
Words3（by Small Brain Games）
Words3は、OptimismのオンチェーンPvP単語ゲームです。
プレイヤーのゴールは「収益性の高い単語を作ること」であり、好きな文字を使用してグリッド上の単語を作ることによってポイントを獲得していきます。
細かいルールや戦略はここでは割愛しますが、
- 他の人があなたの単語を使用することで利益が得られる
- ゲームに投入された資金はすべて賞品や単語報酬を通じてプレイヤーに分配される
など、面白そうな仕掛けがたくさん散りばめられたゲームという所感です。
derio個人的に、クリプトネイティブな思想を突き詰めていった先の一つに「繋げる」という事象があると思うので、下のサムネイル画像にはワクワクしますね。
この続き: 2,936文字 / 画像7枚
まとめ
今回は、「The future of on-chain gaming: ‘The promise of MUD ECS engine’」の内容を筆者なりに分かりやすく一部改変してお伝えするとともに、MUDの概要やその発展可能性、実際に開発が進められているオンチェーンゲーム（Autonomous World）事例などについて紹介・解説しました。
本記事が、ECSパターンやMUDエンジンの概要およびその可能性、およびオンチェーンゲーム（Autonomous World）開発事例などについて理解したいと思われている方にとって、少しでもお役に立ったのであれば幸いです。
また励みになりますので、参考になったという方はぜひTwitterでのシェア・コメントなどしていただけると嬉しいです。
🆕記事をアップしました🆕
— イーサリアムnavi🧭 (@ethereumnavi) January 21, 2023
今回は、いま注目のMUDやECSについてピックアップし、概要とその発展可能性について深掘りしました✍️
“ブロックチェーンゲームならでは” を深淵まで追求し、開発が進められているオンチェーンゲーム（自律型世界）事例についても概観しています🎮https://t.co/QZSADyy6rN
イーサリアムnaviを運営するSTILL合同会社では、web3/crypto関連のリサーチ代行、アドバイザー業務、その他(ご依頼・ご提案・ご相談など)に関するお問い合わせを受け付けております。
まずはお気軽に、こちらからご連絡ください。
- 法人プランLP：https://ethereumnavi.com/lp/corporate/
- Twitter：@STILL_Corp
- メールアドレス：info@still-llc.com