Web3ゲーム分析シリーズ（2）：工業化された制作と制作（技術および美術）

2024.10.16

共有先

TechFlow厳選深潮セレクト

Web3ゲーム分析シリーズ（2）：工業化された制作と制作（技術および美術）

本稿は主にWeb3ゲームの工業的生産および制作（美術および技術）に関して分析を行う。

2024.10.16 - 12:58:34

Web3業界の深掘り報道に専念し潮流を洞察

本稿は主にWeb3ゲームの工業的生産および制作（美術および技術）に関して分析を行う。

執筆：Jake @Antalpha Ventures、Blake @Akedo Games、Jawker @Cipherwave Capital

はじめに

異なる開発企業が採用するアーキテクチャ（プロジェクト＋中台組織構造）は異なり、プロジェクトと中台組織への注力度もまちまちである。強力なプロジェクト体制を取る企業もあれば、強力な中台体制を取る企業もある。そのため本シリーズでは、主にゲーム開発に関わる職能とプロセスに基づいて分析を行う。この文脈において、本シリーズ第2回目の記事では、Web3 Gamingの工業化された制作プロセス（美術と技術）に焦点を当てる。ゲーム企画が正式に承認されると、ゲームプランナーはコアとなるゲームプレイや遊びやすさ、キャラクター成長、プレイヤー行動誘導、マップ設計、ストーリー展開などの詳細を決定する。その後、ゲームプランナーは美術チームおよび技術チームと連携し、Web3ゲームの設計・開発フェーズへと推進していく。

出典：公開市場情報

出典：不鳴科技

工業化生産と制作：技術編概要

企画側が要件を明確にした後、フロントエンドおよびバックエンドの技術チームは、企画部門が提示したゲームデザインを実装し、コードを書き、技術的な実現性を確保しなければならない。具体的な実行プロセスでは、フロントエンドプログラムとバックエンドプログラムに分かれる。チーフエンジニアは技術全体の流れを管理し、主要な技術的実装方針の決定、各種パフォーマンス最適化、基盤フレームワークの構築指導などを担う。

フロントエンドプログラム：表示、最適化、ロジック処理などに関わり、サウンドファイル、画像ファイル、テキストファイルの処理を含む。
バックエンドプログラム：サーバーサイドを担当し、データベース構造、データ転送、検証、保存、通信方式などを含む。

以下の図は、Web3 Gamingにおけるフロントエンドおよびバックエンド各構成要素の概要を示している。以降の章で両者について詳しく分析する。

出典：遊鯊ゲーム圏；Jake 整理

工業化生産と制作：技術フロントエンド

ゲームのフロントエンド開発は、ユーザーインターフェース、インタラクション、ユーザーエクスペリエンスに重点を置く。インタラクティブ性とユーザーエクスペリエンスに関しては、UIデザインの実装、ユーザーインタラクションシステムの開発、アニメーションやビジュアルエフェクトの作成などが含まれる。また、フロントエンドエンジニアは、デスクトップ端末やモバイル端末など、さまざまなプラットフォーム上で一貫したユーザーエクスペリエンスを提供できるよう保証しなければならない。ゲームロジックの実装面では、キャラクターの挙動、ゲームルールの実行、スコアや進行状況の管理、ゲーム内イベントの応答機構に注力する必要がある。効率的かつシームレスなコードを書くことで、ゲームプレイがスムーズで公平かつ挑戦的であることを保証する。

上記の目的を達成するため、フロントエンド開発者はC#やC++などのプログラミング言語を用い、Unreal、Unity、Source、CryEngineなどのゲームエンジンを使用して、ゲーム画面を作成し、アニメーション、音響効果などを調整する。市場には多数のゲームエンジンツールがあり、開発者のニーズに応じて選択する必要がある。各ゲームエンジンは開発者コミュニティのサポート重点が異なるため、以下に技術開発者がゲームエンジンを選ぶ際の好みと要件を示す：

プロジェクト要件：ゲームの種類によってエンジン選定の要求が異なる。たとえば、ビジュアル表現が重要なAAA級ゲームにはUnreal EngineまたはCryEngineが適している。一方、モバイル向けの小型ゲームにはUnityがより適している。
学習曲線とコミュニティサポート：使いやすく習得しやすいエンジンは、開発難易度を大きく低下させる。さらに、活発なコミュニティがあれば豊富なリソースや支援を受けられ、問題発生時に迅速に対応できる。
パフォーマンスと最適化：エンジンのパフォーマンスと最適化能力は、ゲームの動作効果にとって極めて重要である。
コストとライセンス：一部のエンジンは使用料が必要だったり、特定のライセンス条件が設けられている。開発者は予算とプロジェクト要件を考慮して判断しなければならない。
拡張性とカスタマイズ性：ゲーム業界の継続的な発展に伴い、ゲームエンジンは新しい技術トレンドやニーズに対応できる必要がある。エンジンの拡張性とカスタマイズ能力を理解することで、将来の変化にうまく対応できる。

以上の要件分析に基づき、代表的な2つのゲームエンジン、UnityとUnreal Engineについて簡単に紹介・分析する。

UnityはWindows、Mac、iOS、Androidなど複数の主要プラットフォームに対応するゲームエンジンである。C#またはJavaScriptでスクリプトを記述でき、高いカスタマイズ性を持つ。また、Unityは豊富なリソースストアを提供しており、開発者はここでプラグイン、モデル、音声素材などを購入・ダウンロードできる。主な利点として、活発なコミュニティ、優れたクロスプラットフォーム互換性、扱いやすい開発環境、大量のサードパーティ製パッケージが挙げられる。開発者は自ら機能パッケージを作成し、Unity公式ストアで販売することも可能だ。現在、毎月150万人以上の開発者がストアを閲覧しており、利用可能なパッケージは56,000以上ある。商業化と収益化の観点から見ると、Unityは多様なビジネスモデルを持っている。収益化SDK、Unityゲームクラウドによるネットワークゲーム統合サービス、Vivoxのゲーム音声サービス、Multiplayの海外サーバーホスティング、Unityコンテンツ配信プラットフォーム（UDP）、Unityクラウドビルドなどがある。その中でも、収益化SDKは広告配信ゲートウェイとしてUnityが直接広告を配信するものであり、現在ではエンジンライセンス収入に代わって主要な収益源となっている。「Escape from Tarkov」「Temtem」「Call of Duty Mobile」「Hearthstone」など世界的に有名なゲームがUnityを使用しており、市場で最も優れたゲームエンジンの一つであることが証明されている。ただし、Unityのパフォーマンス最適化は比較的劣っており、大規模シーンや高精度モデルの処理能力に限界がある。UI体験もUnrealに劣るため、多くのサードパーティ製パッケージを追加して機能を補完する必要がある。また、C#とJavaScriptを使用しているため、開発中に適応上の課題が生じることもある。2020年3月、Unityは最新版2019.3を正式にリリースし、HDRP（High Definition Render Pipeline）とURP（Universal Render Pipeline）という2つの新機能を導入した。これによりビジュアル効果と最適化能力が向上した。さらに、エフェクトビューエディタ、リアルタイムレイトレーシングシステムなどを追加し、現代市場のニーズに適応し、大型ゲーム制作にも対応できるようになった。
Unreal Engineは完全オープンソースで高性能なゲームエンジンであり、卓越したグラフィックス効果と物理エンジンで知られる。C++およびブループリントによるビジュアルプログラミングをサポートし、強力なマテリアルエディタと照明システムを備え、リアルなゲーム画面を実現できる。開発者向けには無料での使用が可能であり、コードを研究することで開発効率をさらに高めることができる。また、Unreal Engineにはブループリントが標準搭載されており、技術者でなくても視覚的に点と点をつなぐ操作でゲーム設計が可能になる。さらに、クロスプラットフォーム対応と高度にカスタマイズ可能なUIシステムを持つ。料金体系については従来のエンジンビジネスモデルを採用している。一つ目は、ゲームの総収益が100万ドルを超える部分に対して5%の固定ロイヤリティを課すこと。もう一つは、ストア内で公式素材やサードパーティ素材を販売し、そこから12%の収益を得ることである。「Borderlands」「Batman: Arkham Asylum」「Final Fantasy VII Remake」など世界的に有名なゲームがUnreal Engineを使用している。しかし、Unreal Engineの学習曲線は急峻で、初心者には扱いやすくても習得するのは難しい。一定の時間と経験が必要となる。

Mediumおよび競核のデータ分析によると、2021年にUnityの世界市場シェアは49.5%、Unrealは9.7%で、二社による寡占的競争構造が形成されていた。別の市場調査報告書では、2023年の市場シェアはそれぞれ48%と13%であった。以下の表は、両者をグラフィックス、機能、コード、パフォーマンスなどの面で比較したものである。

出典：Incredibuild；Jake 総合分析

ビジュアル・画像効果の観点では、Unreal Engineの再現効果はUnityよりもわずかに優れているが、差は非常に小さい。扱いやすさに関しては、Unityの方が初心者にとって学びやすく、必要なC#言語はコンパイル速度が速く、短いイテレーション時間を実現できる。一方、Unreal Engineはアニメーションとグラフィックス処理において初心者には難易度が高い。実際の運用では、Unreal Engineで実現したいことはUnityでも同様に実現できる。どちらのソフトウェアもAPIやツールを呼び出すことで、より高品質かつ効率的なグラフィックス表現を実現できる。統計によると、実務ではコードエンジニアはUnityを好む傾向にあり、一方でグラフィックスや表現力に高い要求を持つテクニカルアーティストはUnreal Engineを好む傾向にある。

Unity 実際操作画面例, 出典：公開市場情報

Unreal Engine 実際操作画面例, 出典：公開市場情報

また、フロントエンド技術開発者にとってUnityやUnreal以外にも選べるゲームエンジンがあり、以下にいくつか代表的なものを紹介する：

CryEngineは高品質なグラフィックス効果と強力な物理エンジンで知られる。リアルタイムグローバルイルミネーション、高品質なモデルとマテリアルを提供し、開発者が現実世界レベルのゲームを作成できる可能性を提供する。ただし、ドキュメントやコミュニティリソースが比較的少なく、初心者にとっては学習難易度が高くなる可能性がある。
GameMaker Studio 2は2Dまたは3Dゲーム制作に使える開発ツールである。多くのツールとエディタがあり、開発者のアイデアを実現し、最終プロジェクトを同じ初期リソースから複数のプラットフォームに移植できる。直感的で使いやすいドラッグ＆ドロップ（Drag and Drop、略称DnD™）アクションインターフェースを提供し、仮想コードロジックでゲームを作成できる。また、スクリプト言語GMLを使ってゲームを作成することも可能で、両者を組み合わせてDnD™アクションから関数を呼び出すこともできる。
Godot Engineは多機能でクロスプラットフォーム対応の2D・3Dオープンソースゲームエンジンであり、Windows、macOS、Linuxなど複数のOSで動作可能。作成したゲームはPC、Android、iOS、HTML5などでも動作する。ノードベースのアーキテクチャでゲームを設計でき、3Dレンダラー設計により3Dゲームの画質を強化できる。組み込みツールを持つ2Dゲーム機能はピクセル座標で動作し、2Dゲーム効果を細かく制御できる。

どのゲームエンジンを選んでも、フロントエンド技術開発者は実際の運用状況を考慮しなければならない。Web3ゲームは消費財であり、多様なゲームメカニクス（集中、共感、想像）と没入型の感情インタラクション体験（喜び、恐怖、渇望、成長、リラックス、驚きなど）が消費者の継続的消費の重要な前提となる。以下では、ゲーム中の物理シミュレーションと描画システム（レンダリングシステム／レンダラー）を例に、フロントエンド技術者がゲームエンジン使用時に考慮すべき技術的詳細やユーザーエクスペリエンスの問題を分析する。

正確な物理効果のシミュレーションがなければ、どれほど華やかなゲームでも静的で退屈に見える。ゲーム内の多様なシーンはすべて物理原理と物理エンジンに関係している。物理エンジンとは、ゲーム世界のオブジェクトに現実世界の物理的特性（重量、形状など）を与え、滑車やロープなどを含む剛体モデルとして抽象化し、力が加わったときにゲーム内の物体が現実世界のように運動し、衝突する過程を模倣するコンポーネントである。つまり、ニュートン力学モデルに基づき、シンプルなAPIを通じてゲーム物体の運動、回転、衝突を計算し、現実の運動と衝突効果を再現する。この計算プロセスでは、運動学や力学など複数の学問領域の理論と計算が応用される。

運動学：物体の位置が時間とともにどのように変化するかを、物体の物理的性質や外力の影響を無視して幾何学的に記述・研究する力学の一分野。点の運動学は、点の運動方程式、軌道、変位、速度、加速度などの運動特徴、および異なる空間における変換を研究する。運動学は理論力学の一分野であり、幾何学的手法を用いて物体の運動を研究する。実務では、フロントエンド技術者は前提条件を設定し、現実の物理ルールにできるだけ近づけつつ、計算の複雑さを低減する必要がある。一般的な前提条件としては、外力の影響を無視する、物体を幾何学的部品と見なし、質点運動モデルに抽象化する、物体の属性（位置、速度、角度など）のみを考慮する、などが挙げられる。
力学：物体に作用する力とその運動との関係を研究する学問。研究対象は光速より遅く運動する巨視的物体である。ゲームの物理エンジンでは、主に剛体力学が扱われ、質点系力学の基本定理（運動量の定理、角運動量の定理、エネルギーの定理）およびこれらから導かれる他の定理が含まれる。運動量、角運動量、エネルギーは、質点、質点系、剛体の運動を記述する基本的な物理量である。実務および計算プロセスでは、外力が物体の運動に与える影響、重力、抵抗、摩擦などの力が物体の重量や形状に及ぼす影響（弾性体を含む）、剛体の前提条件、ゲーム内の物体が現実世界の運動にどれだけ近いか、といった要因を考慮する必要がある。

物理エンジンを使用することで、ゲーム開発者はゲーム内の物体に形状（均一分布を仮定）と力を与えるだけでよく、エンジンが自動的に運動と衝突の計算を完了してくれる。以上の物理エンジンに関する分析に基づき、フロントエンド技術チームは複雑な運動学知識や衝突計算・最適化を深く掘り下げず、物理エンジンにパラメータを入力するだけでよい。ただし、物理エンジンを効率的に活用するためには、フロントエンド技術チームが基礎的な物理運動知識を理解し、ゲームの離散シミュレーションによって生じる特殊現象に精通しておかなければならない。経験豊富なフロントエンド技術者は、ゲームのスムーズさや実行パフォーマンスなどの問題も考慮する必要がある。

ゲーム内の剛体運動モデルを構築する前に、以下の多くの要因を考慮する必要がある：

設定されたモデルが剛体かどうか、受力後の弾性変形の程度；
運動中または受力後に、形状やサイズが変化するかどうか；
運動中または受力後に、物体内部の各点の相対位置が変化するかどうか；

したがって、以上の分析に基づき、技術フロントエンドチームは物体の中心、形状、質量、初期運動方向および軌道を設定する必要がある。また、物体の重力と運動に関しては、特に重心の設定に注意を払い、物体モデルが均質であり、重心と幾何中心が一致すると仮定する。物体の運動を設定する際には、物体に作用する力を、作用点における力とその点周りのトルクに分解する必要がある。これらのパラメータ設定は、プレイヤーが物体とその運動に対して持つ認識に合致していなければならず、そうしないとプレイヤーは没入感を失い、ゲーム体験に支障が出る。以下は力とトルクの分解の概念図である：

出典：公開市場情報

リアルな物理挙動を実現するため、ゲーム内の物体は正しく加速（人間の認知に合致）し、衝突、重力などの力の影響を受ける必要がある。まず注意すべき点は、3D物体モデルの運動を設定する際、そのモデルが凸形状かどうかを判断することである。つまり、任意の2つの頂点を結ぶ線分が物体の表面から出ないことを意味する。現実の多くの物体は凸ではないが、物理シミュレーションでは凸形状が理想的な近似となることが多い。物理エンジンが衝突を計算・シミュレーションする際、凸形状は落下や衝突などの受動的挙動をより正確に生成できる。凸衝突形状は、元の衝突形状と凹衝突形状の中間に位置し、あらゆる複雑な形状を表現できる。スクリプトで物理を制御することで、車両、機械、布地などのダイナミックな特性を与えることができる。もちろん、入力するメッシュは凹でもよく、物理エンジンがその凸部分を計算する。オブジェクトの複雑さに応じて、複数の凸形状を使用することが、単一の凹衝突形状よりも良好なパフォーマンスを得られることが多い。Godotエンジンでは、凸分解によって中空オブジェクトに概ね一致する凸形状を生成できるが、凸形状の数が多すぎるとこのパフォーマンスの利点は薄れる。大型で複雑なオブジェクト（たとえば全体のステージ）には、凹形状の使用が推奨される。物体の形状をモデリングする際、よく使われる形状タイプには球（SPHERE）、立方体（BOX）、カプセル（CAPSULE）、円柱（CYLINDER）、凸包（CONVEX_HULL）などがあり、中心点、回転角、サイズなどのパラメータを加えて技術フロントエンドが使用できる。

物体の運動をシミュレーションする際、追加の計算プロセスが必要となる。モデルをインポートしても物理エンジンが無効になる場合があるため、物体に簡単なMeshを包み、物体の姿勢をMeshに追従させることができる。Babylonで作成されたMeshには直接物理属性を追加できるほか、カスタムShaderを作成することもできる。カスタムShaderは複雑だが、より良い効果を得られる。エディタでの実際の操作では、メッシュインスタンスを選択し、3Dビューの上部にあるMeshメニューを使用することで、1つまたは複数の凸衝突形状を生成できる。エディタは2つの生成モードを提供している：

「単一凸衝突形状の作成」はQuickhullアルゴリズムを使用し、自動生成された凸衝突形状でCollisionShapeノードを作成する。単一形状のみを生成するためパフォーマンスが良く、小型の物体モデルに適している。
「複数の凸衝突兄弟ノードの作成」はV-HACDアルゴリズムを使用し、複数のCollisionShapeノードを生成し、それぞれに凸形状を持つ。複数の形状を生成するため、凹物体に対しては正確性が高く、パフォーマンスは犠牲になる。中程度の複雑さのオブジェクトでは、単一の凹衝突形状を使うよりも高速になる可能性がある。

凹衝突形状に関しては、凹形状はGodotにおいて最も遅い選択肢だが、最も正確である。StaticBodiesでのみ使用可能。剛体のモードが静的でない限り、KinematicBodiesやRigidBodyと一緒に使用できない。GridMapsを使わないステージ設計では、凹形状が最適な衝突方法となる。また、3Dモデリングソフトで簡略化された衝突メッシュを構築し、Godotが自動的に衝突形状を生成するようにすることもできる。メッシュインスタンスを選択し、3Dビュー上部のMeshメニューからエディタで凹衝突形状を生成できる。エディタは2つのオプションを提供している：

Create Trimesh Static Body：メッシュのジオメトリに一致する凹形状を持つStaticBodyを作成する。
Create Trimesh Collision Sibling：メッシュのジオメトリに一致する凹形状を持つCollisionShapeノードを作成する。

注意すべき点として、パフォーマンス向上のために、形状の数は可能な限り少なく保つべきである。特にRigidBodiesやKinematicBodiesなどの動的オブジェクトにおいてはなおさらである。物理エンジンの内部最適化の恩恵を受けるために、CollisionShapesの移動、回転、スケーリングは避けるべきである。StaticBodyで単一の変換されていない衝突形状を使用すると、エンジンのワイドフェーズアルゴリズムが非アクティブなPhysicsBodiesを破棄できる。パフォーマンスに問題がある場合は、正確さとのトレードオフを検討する必要がある。ほとんどのゲームは100%正確な衝突を持っておらず、正常なゲームプレイ中に目立たないようにするために創造的な方法でそれを隠している。

出典：公開市場情報

以上は物理シミュレーションを例に、フロントエンド開発者が留意すべき内容を分析したものである。次に、描画システム（レンダリングシステム／レンダラー）を例に、フロントエンド開発者が遂行すべき事項を分析する。描画システムは、ゲームエンジン全体の中で最も高度で困難な部分の一つである。理論的には、レンダリングは数学（数学、物理学、アルゴリズムの正確性）と描画効果（照明、立体感、散乱、屈折、反射など）の正確性という2つの問題を解決する必要があり、これによりユーザーに没入感を提供する。実行・実践の過程では、以下の4つの実際的な問題を解決する必要がある：

シーンの複雑さ：単一シーン内の複数オブジェクトを多角的にレンダリングする必要があり、各フレームのゲーム画面生成時に何度も計算を繰り返す。複数のシーンになると、多角的なレンダリングはさらに複雑になる。
ハードウェアとの深い適合性：PC、スマートフォンなどのハードウェア性能がアルゴリズムの実行と出力に影響を与える。ハードウェアに対応して、様々なテクスチャサンプリング作業や、三角関数、指数関数、対数関数などの超越関数計算といった複雑な数学計算を処理する必要がある。また、底層の演算ハードウェアユニットが混合精度演算をサポートしているかどうかも、ハードウェア適合性の重要な検討事項の一つである。
パフォーマンス予算：ゲーム画面の品質要件がどれほど高くても、ゲームエンジンは33ミリ秒（1/30秒）以内に画面を計算し終える必要がある。大規模な没入型ゲームでは、短時間で画面が大きく変化する可能性があるが、計算時間の要件は短縮できない。さらに、ゲーム産業の発展に伴い、ゲームの精緻さに対する要求がますます高まり、フレームレートや解像度の要求も高くなっている。各フレームの時間予算は減少する一方で、画質への要求はますます高まっている。
各フレームの時間予算配分：GPUの性能比率はCPUより高くできる。グラフィックスレンダリングアルゴリズムは過剰なCPU計算リソースを占有してはならず、計算リソースは他のシステムモジュールにも割り当てられる必要がある。

出典：不鳴科技

以上の分析に基づき、計算は描画・レンダリングシステムの最も重要な核心機能の一つである。数千万の頂点とピクセル、論理演算ユニット、テクスチャに対して演算操作を行う。簡単に言えば、複数の三角形で構成される平面が投影行列を通過し、スクリーン空間に投影される。ラスタライゼーションにより、頂点データがフラグメントに変換され、各フラグメントの要素がフレームバッファの各ピクセルに対応する。この過程で、画像がラスター化された2次元画像に変換される。シェーディングと描画の過程では、各ピクセルごとに、対応するマテリアルとテクスチャを計算し、ピクセルを対応する色にレンダリングする。さらに、没入感とリアリズムを高めるため、実際の状況に応じて照明や物体の模様などを調整し、最終的な効果をレンダリングした後、頂点バッファとインデックスバッファを構築し、メッシュデータをGPUに送信する。「投影 → ラスタライゼーション → シェーディングと描画 → 後処理と照明計算」という一連のプロセスが描画プロセスである。

出典：不鳴科技

詳しく言えば、レンダリング対象の物体とシーンは、多様な幾何形状、マテリアル、模様、用途などを持っているため、実際のレンダリング操作では個別に分析が必要である。通常、モデルファイルには複数の頂点を保存する必要があり、頂点位置、法線方向、UV座標、その他の属性データを含む。多くの場合、各モデルの三角形の向きを計算し、隣接する数個の三角形の法線ベクトルを平均することで、その頂点の法線方向を得られる。実際の処理では、インデックスデータと頂点データでモデルの三角形を記述し、すべての頂点を一つの配列に格納し、3つの頂点のインデックス位置情報のみを保存することで、ストレージ容量を元の1/6まで削減できる。

テクスチャはマテリアルを表現する上で極めて重要な手段である。マテリアルの質感は、しばしばパラメータではなく、テクスチャによって決まる。例えば、滑らかな金属表面と錆びた非金属表面の視覚的違いは、粗さのテクスチャによって区別される。シェーディングと描画の過程では、テクスチャサンプリングのパフォーマンス消費が大きく、複雑である。一度のテクスチャサンプリングでは2×4＝8個のピクセルデータを取得し、7回の補間計算が必要となる。注意すべきは、エイリアシング（ジャギー）などの問題を避け、視点の変化による画面の揺れやずれを防ぐこと。そのため、サンプリング時には4点を取り、それらを補間し、さらに2つのレイヤーのテクスチャを一定の割合でサンプリングすることが不可欠である。

シェーディングと描画時には、さまざまな要素を組み合わせる必要がある。このとき、エンジンが生成するShaderコードはバイナリデータブロック（Block）にコンパイルされ、ネットワークと共に保存される。多様なメッシュとShaderコードの組み合わせにより、多彩なゲーム世界が形成される。同一モデルの異なるマテリアルには、それぞれのサブメッシュ内で独自のマテリアル、テクスチャ、Shaderコードを使用できる。各サブメッシュは一部のデータしか使用しないため、インデックスバッファ内の開始位置と終了位置のオフセット値のみを保存すればよい。また、シェーディングと描画の実際の操作では、スペース節約のため、同一のリソースプール（メッシュプール、テクスチャプールなど）を共有できる。特に、インスタンスレンダリングでは、頂点データを共有することで、GPUメモリ使用率と帯域幅を大幅に削減できる。ただし、高品質を求めるゲームでは、インスタンス使用に加えて、個別オブジェクト選択などの追加技術処理が必要になる。

後処理と照明計算の過程では、照明の強さ、角度、ユーザー視点、散乱と屈折、マテリアルの光吸収率など、多面的な問題を考慮する必要がある。たとえば、UnityのBuilt-inパイプラインでは、後処理効果を実現するためにPost Processing Stackプラグインを使用できる。あるいはOnRenderImage()とShaderを組み合わせてカスタマイズすることも可能で、自由度が高く、いつでも修正・拡張できる。ゲームエンジン内での照明処理の計算は複雑であり、以下の図にある照明の分析と方程式表現を参考にできる。興味のある読者はパラメータ調整を試してみるとよい。ゲーム産業の精緻化の発展に伴い、照明表現はゲーム業界の高次元的表現として重要なトレンドとなりつつあり、関連レンダリング技術はアニメーション、映画、バーチャルリアリティなど多くの分野でも応用されている。

出典：不鳴科技

補足として、ゲームエンジンの描画システムは一種のコンピュータ工学であり、GPUのアーキテクチャ、パフォーマンス、エネルギー消費、速度、制限などを深く理解しなければ、エンジンの真価を完全に発揮できない。また、GPUは極めて高い並列処理能力を持ち、安価なコストで一連の遮蔽物の深度マップを形成し、一部のモデルオブジェクトを除外することで、複雑なシーンの処理能力を最適化できる。

工業化生産と制作：技術バックエンド

バックエンドの主な業務は、サーバーサイドのロジックとデータ処理、ネットワーク通信と同期などに関する技術的解決策を担当する。サーバーロジックの面では、バックエンド開発者はサーバーサイドのロジックとゲームデータの保存を担当し、プレイヤーアカウント管理、ゲームワールドの状態同期、マルチプレイヤー間のインタラクションサポートなどを含む。また、ゲーム進行状況、プレイヤーの達成項目、仮想アイテムなどの情報を保存するための効率的なデータベースアーキテクチャを設計・実装する必要がある。さらに、バックエンドシステムはゲームクライアントからのリクエストを処理する必要があり、プレイヤー間のやり取り、プレイヤーデータ数、キャラクターのレベルアップ、リソース購入などの情報リクエストを含む。Web3ゲームのバックエンドアーキテクチャは以下の図を参考にできる。伝送速度、決済時間などの要因の影響を受け、現時点の通信および暗号化技術レベルでは、大規模なWeb3ゲームのバックエンドアーキテクチャはまだ完全にオンチェーンに構築することはできない。

出典：公開市場情報

ゲームのバックエンド開発におけるネットワーク通信と同期では、TCP/IP、HTTP、WebSocketなどの各種ネットワークプロトコルを使用し、安定したクライアントとサーバー間の通信リンクを構築する。この開発プロセスでは、高頻度のデータ交換とリアルタイムのゲーム状態更新をサポートするネットワークプロトコルを設計・実装する必要がある。効果的なネットワーク通信戦略と同期メカニズムにより、遅延を削減し、すべてのプレイヤーがゲーム世界で一貫した状態を見られるようにする。特にオンラインゲームでは、リアルタイムデータの転送と同期が良好なユーザーエクスペリエンスを保証する核心である。

バックエンド開発時には、全体の拡張性、安定性、パフォーマンスを向上させる必要がある。パフォーマンス面では、バックエンドはキャッシュにおいて低遅延と高速な計算フィードバックを実現するだけでなく、HTTPプロトコルにおいてもサーバーとできるだけリアルタイムで通信できるようにする必要がある。安定性と有用性の面では、各サーバーを隔離し、単一サーバーの問題が全体に影響しないようにする。拡張性の面では、計算容量と機能の拡張に注目し、複数のサブサーバーを単一サーバーで接続し、TCP、IPCなどのチャンネルを通じて通信することで、ピーク期間中の情報とリクエスト処理能力を高める。以下は技術バックエンドの代表的な全体構造図であり、ストレージ、サービス、インタラクションなど各面の参考となる。

出典：公開市場情報

多人数・多シナリオのWeb3ゲームでは、プレイヤー体験を保証し、短時間に大量のアクセスリクエストによる負荷を軽減するために、開発者は複数のサーバーを設定できる。各サーバー内で複数のワールドモジュールをグループ化し、多数のユーザーのゲーム利用ニーズを満たせる。また、マルチサーバー構成では、多数のアクセスとリクエストの過程で、リアルタイム操作をサポートし、遅延を最小限に抑えることができる。以下はマルチサーバーとワールドの参考図である。

出典：公開市場情報

Web3ゲームの技術フロントエンドとバックエンドは完全に切り離された存在ではなく、多くの面で協力して初めて全体の技術サポートを完成できる。たとえばチート対策では、フロントエンドとバックエンドの技術がそれぞれの強みを発揮し、共同でチート検出を行う。全体の技術サポートプロセスでは、フロントエンドはUnityなどの利点を発揮し、バックエンドはデータリクエストと書き込みの利点を発揮し、以下のような面で協力する：

スピードハック防止：サーバーによる検証、クライアント側の協力；
メモリデータ暗号化：Unity AssetStoreのプラグインを使用してクライアントメモリを暗号化し、クライアント内のすべてのデータへの依存度を下げる；
プロトコルCD：特定のプロトコルへの頻繁なアクセスを防ぐ。アクセス頻度を制限し、300ミリ秒～1000ミリ秒ごとに1回のみアクセス可能にする；
プロトコル暗号化：プロトコルヘッダーにバイト数を追加；
WPEによるパケットの繰り返し送信防止：繰り返し報酬受け取りやエリア再進入を防止；
非課金チャネルの監視：非課金チャネルから通貨や資産を取得する状況を監視；
移動と操作のスピードハック防止：検出ロジックをプレイヤープロセスやシーンプロセスに配置；

以上はチート対策を例に、フロントエンドとバックエンドの技術連携を説明したものである。フロントエンドとバックエンドのゲーム開発プロセスを深く理解することで、それぞれが異なる任務を担いながらも密接に連携し、一体となったゲームシステムを構成していることがわかる。魅力的なゲーム体験は、フロントエンドの豊かなインタラクションとバックエンドの強力なサポートから生まれる。以上はWeb3ゲーム技術の一部の簡単な紹介に過ぎず、より多くのフロントエンド・バックエンド技術に興味がある読者は、以下の書籍を参考にしてさらに学んでほしい：

Web3ゲームの数学的側面：『Foundations of Game Engine Development, Vol 1: Mathematics』『3Dゲームとコンピュータグラフィックスの数学的方法』『3D Math Primer for Graphics and Game Development』『Essential Mathematics for Games and Interactive Applications』『Geometric Algebra for Computer Science』『コンピュータグラフィックス幾何ツールアルゴリズム詳解』『Visualizing Quaternions』『発散、回転、勾配の解説』『計算幾何学』
ゲームプログラミング：『Learning Unreal Engine Game Development』『Blueprints Visual Scripting for Unreal Engine』『Introduction to Game Design, Prototyping, and Development』『Unity 5 実践』『ゲームプログラミングアルゴリズムとテクニック』『ゲームプログラミングパターン』『Cross-Platform Game Programming』『Android NDK Game Development Cookbook』『Building an FPS Game with Unity』『Unity Virtual Reality Projects』『Augmented Reality』『Practical Augmented Reality』『Game Programming Golden Rules』『Best Game Programming Gems』『Advanced Game Programming』
ゲームエンジン：『ゲームエンジンアーキテクチャ』『3D Game Engine Architecture』『3D Game Engine Design』『ゲームスクリプト上級プログラミング』『プログラミング言語実装パターン』『ガベージコレクションアルゴリズムハンドブック：自動メモリ管理の芸術』『Video Game Optimization』『Unity 5 Game Optimization』『アルゴリズムの心得：効率的アルゴリズムの秘訣』『Modern X86 Assembly Language Programming』『GPU Programing for Games and Science』『Vector Games Math Processors』『Game Development Tools』『Designing the User Experience of Game Development Tools』
コンピュータグラフィックスとレンダリング：『Real-Time 3D Rendering with DirectX and HLSL』『コンピュータグラフィックス』『コンピュータグラフィックス原理と実践：C言語記述』『Principles of Digital Image Synthesis』『デジタル画像処理』『3Dゲームプログラミングマスターテクニック』『リアルタイムシャドウ技術』『リアルタイムコンピュータグラフィックス』『Real-Time Volume Graphics』『レイトレーシングアルゴリズムと技術』『Physically Based Rendering』『Graphics Programming Methods』『Practical Rendering and Computation with Direct3D』『グラフィックスシェーダー』『OpenGLシェーディング言語』『OpenGL Insights』『Advanced Global Illumination』『Production Volume Rendering』『Texturing and Modeling』『Polygon Mesh Processing』『Level of Detail for 3D Graphics』『3D Engine Design for Virtual Globes』『Non-Photorealistic Rendering』『Isosurfaces』『The Magic of Computer Graphics』
ゲーム音響：『Game Audio Programming』
ゲーム物理とアニメーション：『コードで見る：自然システムのプログラミングシミュレーション』『Computer Animation』『ゲーム開発物理学』『Physics Modeling for Game Programers』『Physics Based Animation』『Real-Time Cameras』『Game Inverse Kinematics』『Fluid Engine Development』『Game Physics Pearls』『The Art of Fluid Animation』『Fluid Simulation for Computer Graphics』『Collision Detection in Interactive 3D Environments』『リアルタイム衝突検出アルゴリズム技術』『ゲーム物理エンジン開発』
ゲームAI：『Artificial Intelligence for Games』『ゲーム開発における人工知能』『ゲームAIプログラミングケーススタディ』『Unity AIゲーム開発』『Behavioral Mathematics for Game AI』
マルチプレイヤーゲームプログラミング：『Multiplayer Game Programming』『Massively Multiplayer Game Development』『POSIXマルチスレッドプログラミング』『大規模オンラインゲーム開発』『TCP/IP详解巻1-3』

工業化生産と制作：美術編

篇幅の制約から、本パートではWeb3ゲームの美術部分について簡潔に分析する。美術はWeb3ゲームにおいて極めて重要な地位を占める。優れたゲーム作品は単なる娯楽品ではなく、特にAAAクラスになると、各々の高水準なゲームは「文以載道」の芸術作品と言える。美術的表現形式に関して、ゲームスタジオはエフェクト、インタラクション、アニメーション、レンダリングなど多方面からWeb3ゲームの芸術的表現を高めていく。以下の表は、Web3ゲームの美術表現において考慮すべき複数の細分化方向を示している。ゲームの種類、制作期間、ターゲットユーザーの違いにより、Web3ゲームスタジオは美術表現面でのバランスと取捨選択を総合的に検討する必要がある。