原文アドレス：https://twitter.com/hiCaptainZ/status/1656306576293244928
元のタイトル：全链游戏引擎架构深度分析 ECS 和 ARC
ARC の提出#
JumpCrypto は今年 1 月に ARC（Action Registry Core）という新しい全链游戏引擎架构を提案しました。ここでは、ARC 架构の詳細と ECS 架构との違いと関連性について説明します。
一般的に、ゲームエンジンのアーキテクチャは OOP（オブジェクト指向）と ECS（エンティティコンポーネントシステム）の 2 つしかありません。オブジェクトの導入により、OOP は後期に拡張性を持つのが難しくなりました。その後、多くのゲームエンジンがデータ指向の ECS アーキテクチャ（エンティティコンポーネントシステム）を導入しました。私は以前の記事で ECS アーキテクチャについて説明しましたが、ここでは割愛します。伝統的なゲームはループベースですが、全链游戏はプッシュベースです。そのため、JumpCrypto は ECS アーキテクチャを参考にして、ブロックチェーンゲームに適した ARC アーキテクチャを提案しました。
ARC（Action Registry Core）アーキテクチャは、チェーン上の情報を整理するためのデータ駆動型の方法です。ARC では、エンティティ（Entities）はデータを含まないコンポーネントのコンテナであり、コンポーネント（Components）は動作を持たないデータ型であり、特定のコンポーネントに対して実行できるアクション（Actions）は機能です。伝統的な ECS とは異なり、ARC はブロックチェーンアーキテクチャのプッシュ特性を考慮しており、循環特性ではありません。アクションは、チェーン上のゲームの進行状況に関連する状態の更新、具体的にはエンティティ PDA の読み取りとコンポーネントの逆シリアル化、およびシリアル化されたコンポーネントの変更によるエンティティの更新を担当します。このアーキテクチャは拡張性を提供し、ゲームアセットの増加と相互依存性の向上に応じて拡張することができ、オブジェクト指向プログラミング方法に伴う技術的負債を回避します。
ARC と ECS の比較分析#
それでは、ARC と ECS の違いはどこにあるのでしょうか？
両者ともデータ駆動型の設計パターンを採用しており、オブジェクト指向プログラミング（OOP）に比べて効率と柔軟性が高いです。
共通点:
エンティティ（Entity）：両方にエンティティの概念があります。エンティティはコンポーネントを収容するための一意の識別子です。これらのエンティティ自体にはデータは含まれず、コンポーネントを付加することでデータを取得します。
コンポーネント（Component）：ECS と ARC の両方で、コンポーネントは行動を持たない純粋なデータ型です。コンポーネントはエンティティに付加され、エンティティにデータを提供します。
相違点:
システム（System）vs アクション（Action）：ECS はシステムを使用し、ARC はアクションを使用します。システムは、特定のコンポーネントセットを持つエンティティと一致する関数です。一方、アクションは特定のコンポーネントに対して実行されるものであり、システム全体ではなく個々のコンポーネントに対して実行されます。これは、伝統的な ECS がループベースのアーキテクチャであり、伝統的なゲームに適しているのに対し、ARC のアクションパックはブロックチェーンアーキテクチャがプッシュベースであることを考慮しています。
オンチェーン vs オフチェーン：ECS は通常、ローカルまたはサーバー上で実行される伝統的なゲームに使用されますが、ARC はブロックチェーン上のゲームとアセットに使用されます。したがって、ARC は取引コスト、データストレージ制限、クロスチェーン操作など、より困難な問題を扱う必要があります。
レジストリ（Registry）：ARC はレジストリの概念を導入し、登録されたコンポーネントと特定のコンポーネントを変更できるアクションを追跡します。これは、より高度なガバナンス機能を実現し、ブロックチェーンの分散化特性に適応するためです。これは伝統的な ECS にはありません。
上記の説明は抽象的すぎるかもしれませんので、例を挙げて説明します。戦闘ゲームを作成していると仮定しましょう。プレイヤーとモンスターの 2 つのエンティティがあります。それぞれのエンティティには、ヒットポイントや攻撃力などのいくつかの属性があります。
ECS（Entity Component System）の場合：
エンティティ（Entity）：プレイヤーとモンスターは両方ともエンティティです。
コンポーネント（Component）：ヒットポイントと攻撃力は両方ともコンポーネントです。プレイヤーとモンスターエンティティの両方にこれらのコンポーネントを付加できます。
システム（System）：「戦闘システム」というシステムがあります。プレイヤーとモンスターの位置が同じ場合、このシステムは彼らの攻撃力とヒットポイントに基づいて戦闘を行います。このシステムは定期的に実行され、条件を満たすすべてのエンティティをチェックし、それらのコンポーネントを更新します（例：ヒットポイントの減少）。
ARC（Action Registry Core）の場合：
エンティティ（Entity）：同様に、プレイヤーとモンスターはエンティティです。
コンポーネント（Component）：ヒットポイントと攻撃力は依然としてコンポーネントです。
アクション（Action）：ここではシステムの代わりにアクションがあります。たとえば、「攻撃」アクションがあります。プレイヤーがモンスターを攻撃する場合、このアクションがトリガーされ、モンスターのヒットポイントが減少します。このアクションはイベントベースで実行され、定期的なチェックではありません。
レジストリ（Registry）：これは ARC 固有の概念です。レジストリは、どのアクションがどのコンポーネントを変更できるかを記録します。たとえば、「攻撃」アクションは「ヒットポイント」コンポーネントを変更できるとレジストリに登録されている必要があります。レジストリに登録されていないアクションは、対応するコンポーネントを変更することはできません。
これが ECS と ARC の主な違いと共通点です。ECS では、ロジックはシステムによってループ方式で実行されますが、ARC ではイベントに基づいたアクションが実行されます。さらに、ARC にはレジストリのレイヤーが追加され、アクションとコンポーネントの関係をより良く管理し、柔軟性を提供します。
ゲームのループとプッシュ#
伝統的なゲームはループベースであり、ゲームのコアメカニズムはゲームループに基づいています。ゲームループは繰り返し行われるプロセスであり、通常、ユーザーの入力の処理、ゲームの状態の更新、ゲームワールドのレンダリングなどのステップが含まれます。このループはゲームの実行中に継続的に行われ、通常は秒間数十回から数百回実行され、ゲームワールドの滑らかさを保ちます。このアーキテクチャでは、ゲームシステム（物理エンジン、AI システムなど）は各ループで関心のあるゲームエンティティとコンポーネントをチェックして処理します。
一方、ブロックチェーンのアーキテクチャはプッシュベースです。ブロックチェーンは分散型データベースであり、ネットワーク内のノードが情報を共有・保存します。ノードが新しいトランザクション（送金、契約呼び出しなど）を生成すると、そのトランザクションはネットワークにプッシュされ、他のノードはそのトランザクションを受け取り、検証してブロックチェーンに追加します。これは受動的なプロセスであり、ノードは新しいトランザクションを積極的に検索するのではなく、ネットワーク内の他のノードから新しいトランザクションを待ちます。そのため、ブロックチェーンのアーキテクチャはプッシュベースと呼ばれています。
この基本的な違いにより、ECS と ARC は設計上異なるアプローチを取ります。ECS では、システムが各ゲームループで自らのタスクをアクティブに処理します。一方、ARC ではアクションは受動的であり、関連するトランザクションがブロックチェーン上で発生した場合にのみトリガーされ、対応する操作が実行されます。この設計は、ブロックチェーンの特性と要件により適しています。