はじめに
今回はこちらを見ていきます
5. プログラミング
理念と概念
- 合理化された開発に必要とされるすべてのツールはすでに利用可能です
- コーディングツールだけではなく管理、それらをスムーズに行うツールを提供する事を行ってきている
- 低レベルの言語性能と高レベルの言語機能
- C++がサポートされたのはパフォーマンスのため
- 高速な反復サイクルのためのスクリプト言語
- BPのこと
- 柔軟でよくテストされたゲームプレイフレームワーク
- ネットワーキングがネイティブに実装されています
UE1 to UE3
- Source Code 中央
- Unreal Build Tool
- Source Codeを整理する為のツール
- 要件に応じて必要となる全ての構造を生成する
- Actor
- Objectから継承する
- Object
- Gameplay Framework
- Memory Management
- Replication
- Compile
- パイプラインでコンパイルする
スキマティック
Unreal Build Tool
Code Structure コード構造
- コードをグループ化する様々な方法
- プロジェクトの設定方法
Modules モジュール
- コードの柱
- 1つの巨大の機能群でコードを整理する
- モジュール別に機能を管理すれば、他のプロジェクトへの流用がしやすくなる
- モジュール別に機能を管理すれば、コンパイル時に影響範囲に応じてコンパイルする範囲も狭めることができ時間節約にもなる
Plugin プラグイン
- エンジンまたはプロジェクトに配置可能
- プラグインは有効・無効が可能ななにかである
- プロジェクトまたはエンジンのどちらにプラグインを配置するかは、そのプラグインが異なるプロジェクトで使用する予定であるならエンジンにあるべき。
Platform
- まだ取り組み中の新しい何か
- プラットフォームごとにフォルダが区切られ、そのプラットフォームに必要なすべてのコードを収集する
Base Type
- 基本データ型と構造
- UObjectとAActorはプログラミングの柱
- 最も重要なものはUObjectとアクタ
- その他有用な型
- UEのC++は純粋なC++ではなく新しいタイプがある
- C++の上部には作業を大幅に簡素化しコードからエディタへの可視性を提供するレイヤーがある
Enum
Strings
- FString
- 最も基本的
- FName
- アクターの一意の名前に使う
- FText
- ローカライゼーション対応の文字列
- BPやアクタやコードにある全てのFTextは簡単に編集できる
Structs
- UPropertyマクロを使用している事が期待されている
Collections
ネストされたコンテナがサポートされている
- TMap
- TArray
- 配列の配列を使用することはできない
- TSet
Transform types
- FVector
- FRotator
- オイラー角を使用する
- FQuat
- FTransform
UObject
- ガベージコレクションシステムによって処理されるオブジェクト
- メモリシステムによって自動的に処理される必要がある全てのものは UObject から継承されている
- UObject例
- アセット
- アクタ
Actor
- アクタとはレベルに配置できる何か。
- トランスフォーム(ロケーション、回転、スケール)を持てるものはすべてアクタ
- 親クラスの調べ方
- キャラクターをペルソナエディター開くと右上に表示されている
- キャラクターをペルソナエディター開くと右上に表示されている
Components
Lifecycle
- ライフサイクルはレベルに直接配置されているかまたは、BPあC++からスポーンされる場合で異なる
- アクタやコンポーネントを参照するスマートポインタがある
- ガベージコレクタはスマートポインタの参照が失われたものを収集する場合としない場合がある
- アクタのライフサイクル
Creation / Destruction
- Creation と Destruction はいくつかの方法がある
- 通常コードで行う場合、アクターはスポーンされDestroyされる
- しかしオブジェクトは新しいオブジェクトによって作成される
- オブジェクトを自動的に削除してはならない
- そのオブジェクトへの参照がなくなった場合でもガベージコレクタによって削除される必要がある
Data Objects
- ゲームプレイの用途及びデザイナーがこの種のデータにアクセスできるようにするために非常に便利なもの
Curves
- カーブデータはC++やBPから参照可能
DataAssets
- 汎用コンテナでカスタムなデータ設定の為の大きな構造体に似ている
DataTables
- インポート/エクスポート可能なテーブル
- 他のツールで生成されたものをインポートするのに便利
Memory Management
- ガーベージコレクタは参照を持たないオブジェクトのようなものを自動的に探しマークし、適切だとみなした場合はそのメモリを回収する
- 処理方法はいくつかある
- 例
- コードから参照するアセットがある
- コードがロードされるとそのアセットもすぐにロードする(同期)
- または参照を使用する事も可能
- ストリーミングシステムに要求してそのアセットを非同期でロード可能
- アクタも同様にマップに配置されている場合を除きロードするタイミングは制御可能
- マップに配置されていて、マップをアンロードした場合ガベージコレクションが自動的に行われる
Gameplay Framework
- ゲームプレイフレームワークはエンジンに付属している
- あらゆる種類のゲームを作成するための一般的なシステムを提供する
- ゲームフローを制御する手段を提供する
- ゲームでキャラクターを使用する手段を提供する
- プレイヤーがゲームで行うあらゆる操作を制御する手段を提供する
- ここに示し以外にも大量に存在するが主要なものの解説
- TickとSubsystemを扱う必要がある
- Tick は物事を更新するように指示する方法
- Tickはフレームごとに発生するか2フレームごと、またはフレームグループごとに発生させるように制御可能
- SubSystemは GameInstance、GameModeなど様々なブロックの機能を簡単に拡張する方法
- SubSystemはそれを作ったブロックと同じライフサイクルを持つ模様
GameMode
- Gameplay Framework の主柱
- ゲームのフローを制御する
- いつゲームが終了したのか
- いつ変更する必要があるのか
- 通常ゲーム中の状態を変更するために処理する必要のある全ての情報が含まれている
- ゲームモードはレベルに存在している
- レベルを変更するたびに GameMode が変更される
- レプリケーションの観点からサーバーに置かれ、クライアントはアクセスできない
GameInstance
- GameInstanceは実行するレベル変更をまたがって存続する
Game State
- ゲームの状態に関する情報を共有する場
- 例えば特定のポイントに達するとゲームの状態が変更される
- 敵の残り数(赤枠)などはGameModeに保存する情報
- しかし複数プレイヤー間でこういった情報を共有したい場合、GameStateに配置しレプリケートとしてマークする必要がある
- 例えば特定のポイントに達するとゲームの状態が変更される
PlayerController
- PlayerController はキャラクターの頭脳
- 操り人形を制御する頭脳を持つことができる
- 操り人形のアクションに関する決定はすべてここで行われる
- プレイヤーの入力によって駆動される
- 他の種類のコントローラーも使用する事ができる
- AIコントローラー
- 決定木を使用したりできる
- AIコントローラー
- 他の種類のコントローラーも使用する事ができる
- 直接操作する事もあれば、ここへ移動しろなどの司令をグループに出すような場合は司令はPlayerControllerでAIコントローラーが移動の方法を決定する模様
- PlayerController クライアントのみがレプリケートする
Input Component
- 読み込まれるアクションを設定したりするよう
Pawn/Character
- Pawnはワールド内での物理表現、振る舞いを持つか意思決定を持つ必要のあるあらゆるもの
Replication
- オーナーシップに基づく
- アクタとプロパティ両方レプリケートできる
- Replicationは信頼性(Reliability)に基づく
- ものをどのようにレプリケートするかに関する信頼性が設定できる
- RPCs 独自のメッセージを生成できる
- それらが変更された時に更新するものを決定できる
- RepNofify メッセージを送信できる
- 何かが変更された時にイベントをフックしてあらゆる種類のアクションが実行できる
Unreal Automation Tool
- ビルド、クック、パッケージングはすでにエンジンで解説済みだが補足として
- それらは Unreal Automation Toolによって導かれる
Cook
- クックの方法は選択可能
- オンザフライ(一部のみ)
- すべて
Profiling and Debugging
- メモリレポート
- コマンドライン
- すべてのアクタやオブジェクト、メモリ全体をダンプする
- LLMは低レベルメモリ
- コマンド
- ビルドで有効にする必要がある
- メモリにロードれさるもののメモリとクラスにある要素の数を提供する
- 他のものよりも非常に正確
- プロファイルGPU
- コマンド: ProfileGPU
Advise
Project structure
- プロジェクトは複数のモジュールに分割することでコンパイル時間を減らせるだけでなく、流用できそうであれば別プロジェクトでも使えます
- Live++を常に使用しましょう。エディタで実行中にコンパイルしたりプレイ中にコンパイルできます
- 可能な限りプラグインを使用してください。プラグインは有効・無効化ができる機能を持つものです。
- エンジン内で多くの変更を行うのは避けてください
- チームでファイルやフォルダを共有することについて、Content、Source、Configは共有されるべきです。Binariesはプログラマーや継続的インテグレーションシステムからのみアップロードされます
- プラットフォーム拡張
Text and Localization (テキストとローカライゼーション)
- テキストとローカライゼーションについて留意すべきこと
Specifiers (指定子)
- 是非注目してほしい指定子がある
- BlueprintPure
- これは関数を純粋なBlueprint関数に転送する
- そのためこれを呼び出すフローはない
- 通常これは定数関数用
- BlueprintType
- 構造の分割が可能
- 構造内のすべての変数が確認できる
- EditInlineNew/Instanced
- 画像の右上のような情報をエディタに表示できる
Actor Ticking
- できるだけティックは避けるようにしてください
- 例えばデザイナーチームがあまり熟練していない場合、デフォルトでTickをfalseに設定してください
- これによってBPはTickしなくなる
- 例えばデザイナーチームがあまり熟練していない場合、デフォルトでTickをfalseに設定してください
- Tickにはオーバーヘッドがあります
- 一度のティックで多くのアクタに多くのことを行うよりもマネージャがあるならそっちでやって下さい
- 可能なすべてのティックをグループ化するようにします
- Tickレートが変更できます
Gameplay Frameworkk
UEを初めて使用するプログラマーは数日間で良いのでBPから開始してエンジン構造の一部のフレームワーククラスについて理解してください。なぜならこれが標準だからです。
その後C++に移行したらシステムの構築をすぐに変更する前にエンジンには何があるのかフレームワークは実際に何を行うかを理解するようにしてください。
基礎を理解するようにしてください。
- Game instance はレベルをまたがって存続する必要のある情報を核の王する必要がある場合に使用します
- 複数のPlayerControllersを使用できます
- 例えばゲーム内の PlayerControllerを1つのキャラクタ用に使用できます
- Pawn vs Character
- 誰が入力を消費するかに注意して下さい。BPで入力を消費するのを避けるようにして下さい。そのほうが入力の消費者をより簡単にトラックできます
- BPで入力を取得して消費すると入力は継続しません。
- そうなるとコントローラーでそれを取得できません
- そうなると多くの時間を費やして入力を消費している部分をBPから探すことになります
- BPで入力を取得して消費すると入力は継続しません。
Blue Print Balance
- これは長い議論になるが講師の方がよく行う方法
- コア機能のようなものはすべてC++で行うようにして
- 特定のレベルやプレハブはBPで行うようにしている
- イベントはC++とBP両方にリンクできるためやり取りもできる事に留意して下さい
Constructor Helpers
- C++でアセットへの参照を取得する最も簡単な方法は通常コンストラクターヘルパー
- Google で検索すると最初に見つかるもの
- コードをロードするとアセットはメモリにロードされる。そのアセットが他のものを参照していれば、それらのものはすべてメモリを参照する
- 変わりの方法を見つけるとするならその1つはアセットのポインタを使用する事。
- DataAssetsサブクラスやUAssetポインタなど
- これにより最初からロードするのではなく必要な場合にそのアセットを読み込めるようになる
- これに相当するものはBPにも存在する。BPのセクションで解説しますとのこと
Build Cook and Pack
- 素早くテストしたいものがあればオンザフライでクックできます
- 出荷バージョンができたらリリースフォルダーをバックアップします
- しなければDLCパッチまたは修正を出荷バージョンに行う時にデルタインクリメンタルパックを行うことができません
Profiling and Debugging
- 開発でのみ使用可能な関数を設定できます
- この関数を開発ターゲットの外部で呼び出した場合は何も起こりません
- Print Stringなどが良い例です
- その関数のコンソールコマンドバージョンを作成する指定子を使用することを推奨します
最後
全く使わなかったけどC++を昔勉強しておいてよかった。そこまで迷子にならずに済んだ。
しかしだだっ広いなぁ
メモ
- エンジン内のすべてのものはレプリケーションに対応している
マクロ
- 種類例
- UFUNCTION
- UPROPERTY
- UCLASS
- GENERATED_BODY
- 指定子(Specifier)を持つものもある
- 非常に重要。なぜならデザイナーやアーティストに公開し、彼らはそれをエディタで使用するため
- カッコ内の引数の事 例
// 変数例 エディタからは編集可能、BPからは読み取り専用、ソート用のカテゴリは Combatという意味 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Combat) float BaseDamage;
// 関数例 BPから呼び出し可能(つまりBPノードになる)、ソート用カテゴリは Team UPROPERTY(BlueprintCallable, Category = Team) virtual FGenericTeamId GetGenericTeamId() const override;