CaptainZ

CaptainZ

Prompt Engineer. Focusing on AI, ZKP and Onchain Game. 每周一篇严肃/深度长文。专注于AI,零知识证明,全链游戏,还有心理学。
twitter

全链游戏引擎架构ARCとECSにはどのような違いがありますか?

原文アドレス:https://twitter.com/hiCaptainZ/status/1656306576293244928
元のタイトル:全链游戏引擎架构深度分析 ECS 和 ARC

ARC の提出#

JumpCrypto は今年 1 月に ARC(Action Registry Core)という新しい全链游戏引擎架构を提案しました。ここでは、ARC 架构の詳細と ECS 架构との違いと関連性について説明します。

一般的に、ゲームエンジンのアーキテクチャには 2 つのタイプがあります。OOP(オブジェクト指向)と ECS(エンティティコンポーネントシステム)です。ゲーム内のオブジェクトの増加に伴い、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):「戦闘システム」というシステムを持つことができます。このシステムは、プレイヤーとモンスターの位置が同じ場合に、彼らの攻撃力とヒットポイントに基づいて戦闘を行います。このシステムは定期的に実行され、条件を満たすすべてのエンティティをチェックし、それらのコンポーネントを更新します(例:ヒットポイントを減らす)。

ARC(Action Registry Core)の場合:

エンティティ(Entity):同様に、プレイヤーとモンスターはエンティティです。

コンポーネント(Component):ヒットポイントや攻撃力はまだコンポーネントです。

アクション(Action):ここではシステムの代わりにアクションがあります。たとえば、「攻撃」アクションがあります。プレイヤーがモンスターを攻撃する場合、このアクションがトリガーされ、モンスターのヒットポイントが減少します。このアクションはイベントベースで実行され、定期的なチェックではありません。

レジストリ(Registry):これは ARC 固有の概念です。レジストリは、どのアクションがどのコンポーネントを変更できるかを記録します。たとえば、「攻撃」アクションが「ヒットポイント」コンポーネントを変更できるようにレジストリに登録することができます。レジストリに登録されていないアクションは、対応するコンポーネントを変更することはできません。

これが ECS と ARC の主な違いと共通点です。ECS では、ロジックはシステムによってループ方式で実行されますが、ARC ではイベントに基づいてアクションがトリガーされ、実行されます。さらに、ARC にはレジストリのレイヤーが追加され、アクションとコンポーネントの関係をより良く管理し、柔軟性を提供します。

ゲームのループとプッシュ#

伝統的なゲームはループベースであり、ゲームのコアメカニズムはゲームループに基づいています。ゲームループは繰り返し行われるプロセスであり、通常、ユーザーの入力の処理、ゲームの状態の更新、ゲームワールドのレンダリングなどのステップが含まれます。このループはゲームの実行中に継続的に行われ、通常は 1 秒あたり数十回から数百回実行され、ゲームワールドのスムーズな動作を保つために必要です。このアーキテクチャでは、ゲームシステム(物理エンジン、AI システムなど)は各ループで関心のあるゲームエンティティとコンポーネントをチェックして処理します。

一方、ブロックチェーンのアーキテクチャはプッシュベースです。ブロックチェーンは分散型データベースであり、ネットワーク内のノードが情報を共有・保存します。ノードが新しいトランザクション(送金、契約呼び出しなど)を生成すると、そのトランザクションはネットワークにプッシュされ、他のノードがそのトランザクションを受信し、検証してブロックチェーンに追加します。これは受動的なプロセスであり、ノードは新しいトランザクションをアクティブに検索するのではなく、ネットワーク内の他のノードからの新しいトランザクションを待ちます。そのため、ブロックチェーンのアーキテクチャはプッシュベースと呼ばれています。

この基本的な違いにより、ECS と ARC は設計上異なるアプローチを取っています。ECS では、システムが各ゲームループでアクティブにタスクを処理します。一方、ARC ではアクションは受動的であり、関連するトランザクションがブロックチェーン上で発生した場合にのみトリガーされ、対応する操作が実行されます。この設計は、ブロックチェーンの特性と要件により適しています。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。