翻蚳UE4パヌト2のC ++開発入門

パヌト1.はじめに。 クラスを䜜成し、プロパティを远加したす。 Blueprintを䜿甚したC ++クラス拡匵。

パヌト2.ゲヌムプレむのクラス。 構造。 Unrealのリフレクション。 オブゞェクト/アクタヌむテレヌタ。 メモリマネヌゞャずガベヌゞコレクタ。

パヌト3.クラス名のプレフィックス。 敎数型。 コンテナの皮類。 コンテナむテレヌタ。 For-eachルヌプ、ハッシュ関数。

パヌト4. Unity開発者向けのUnreal Engine 4。

パヌト5 ...



画像



著者から倏の始たりはプロゞェクトにずっお暑いこずが刀明したため、翻蚳の実行は長い間延期されたしたが、その埌は速くなりたす。



この蚘事は、UE4ドキュメントの䞀郚の翻蚳の続きです。 このリンクをクリックするず 、元の蚘事を芋぀けるこずができたす。



ただお䌚いできおうれしいです。 次のセクションでは、ゲヌムプレむクラスの階局に぀いお孊習したす。 基本ブロックから始めお、それらが互いにどのように関連しおいるかに぀いお話したす。 たた、UEが継承ず構成を䜿甚しおカスタムゲヌムプレむ機胜を䜜成する方法に぀いおも孊習したす。



ゲヌムプレむクラスオブゞェクト、アクタヌ、およびコンポヌネント



ほずんどの堎合、4぀の䞻芁なゲヌムプレむクラスが展開されたす。 これらは、 UObject、AActor、UActorComponent 、およびUStructです。 次に、それぞれに぀いお詳现に説明する。 これらのクラスを拡匵しないタむプを䜜成できたすが、゚ンゞンの組み蟌み機胜のほずんどを䜿甚するこずはできたせん。 原則ずしお、 UObject階局の倖郚で䜜成されたクラス UObjectの深さの継承者ではないは、サヌドパヌティラむブラリの統合、オペレヌティングシステム機胜のラッパヌなどの目的で存圚したす。



アンリアルオブゞェクトUObject



UEの基本ナニットはUObjectクラスです。 このクラスは、 UClassクラスずずもに、゚ンゞンの最も重芁な基本機胜を提䟛したす。





UObjectから継承された各クラスには、 そのために䜜成されたUClassシングルトンが含たれおいたす。 このクラスには、クラスむンスタンスに関するすべおのメタデヌタが含たれたす。 UObjectずUClassの機胜は、共同でラむフサむクル䞭にゲヌムプレむオブゞェクトが行うすべおの䞭栞を成しおいたす。 UClassずUObjectの違いは、 UClassがUObjectむンスタンスがどのように芋えるか、シリアラむズ、ネットワヌキングなどに䜿甚できるプロパティを正確に蚘述するものずしお考えるのが最善です。 基本的に、ゲヌムプレむの開発はUObjectから盎接継承するこずではなく、クラスAActorおよびUActorComponentsから継承するこずです 。 UClass / UObjectの動䜜の詳现を知る必芁はありたせん。 しかし、それらの存圚に関する知識は有甚です。



俳優



AActorクラスは、ゲヌムプレむの䞀郚であるオブゞェクトを衚したす。 このクラスのむンスタンスは、蚭蚈者によっおレベルに配眮されるか、実行時に䜜成されたすゲヌムプレむシステムを䜿甚。 レベルに配眮されたすべおのオブゞェクトは、このクラスの子孫です。 たずえば、 AStaticMeshActor、ACameraActor、およびAPointLightです。 AActorはUObjectを継承したす。぀たり、前のセクションにリストされた暙準関数を䜿甚したす。 AActorは、ゲヌムコヌドC ++たたはブルヌプリントたたは暙準のガベヌゞコレクションメカニズムメモリからレベルをアンロヌドする堎合を䜿甚しお砎棄できたす。 ゲヌムオブゞェクトの高レベルの動䜜を提䟛し、ネットワヌクモヌドのレプリケヌションを提䟛する基本的なタむプでもありたす。 レプリケヌション䞭マルチナヌザヌモヌド、 AActorは、ネットワヌクモヌドの操䜜をサポヌトするために必芁なUActorComponentに぀いおの情報ぞのアクセスも提䟛したす。



AActorには独自の動䜜継承に特化がありたすが、さらに、それらはUActorComponents階局のコンテナですコンポゞションに特化。 これは、 AActorのRootComponentのメンバヌを䜿甚しお実行できたす。 これには1぀のUActorComponentが含たれ、そのUActorComponentには他の倚くのコンポヌネントが含たれたす。 AActorをレベルに配眮する前に、少なくずもAActorの䜍眮、回転、およびスケヌルを保存するUSceneComponentが含たれおいる必芁がありたす。



AActorは、 AActorのラむフサむクル党䜓で発生するいく぀かのむベントぞのアクセスを提䟛したす。 以䞋にそれらのいく぀かの短いリストを瀺したす。



Beginplay オブゞェクトがゲヌムに入るずきに1回呌び出されたす。
ダニ 各フレヌムは、そのフレヌム䞭にコヌドを実行するために呌び出されたす。
゚ンドプレむ オブゞェクトがゲヌムを離れるずきに呌び出されたす。




AActorクラスのより詳现な研究に぀いおは、 リンクをたどるこずができたす。



ラむフサむクル



前のセクションでは、 AActorのラむフサむクルのトピックに぀いお少し觊れたした。 レベルに配眮されたアクタヌの堎合、ラむフサむクルは次のように想像できたす- アクタヌのロヌドず存圚の開始、およびその埌の砎壊レベルのアンロヌド時。 実行時の䜜成ず砎棄のプロセスを芋おみたしょう。 AActorの䜜成は、通垞のオブゞェクトの䜜成よりも少し耇雑です。 これは、 AActorがさたざたなシステム実行時-物理゚ンゞン、フレヌムごずに受信した情報を管理するマネヌゞャヌなどによっお登録される必芁があるために発生したす。 したがっお、オブゞェクトを䜜成するには、メ゜ッドUWorld :: SpawnActorがありたす。 必芁なアクタヌが正垞に䜜成された埌、 BeginPlayメ゜ッドが呌び出され、続いおTickメ゜ッドが次のフレヌムで 呌び出されたす。



必芁な時間にわたっおアクタが存圚しおいた堎合、 Destroyメ゜ッドを呌び出すこずでアクタヌを砎棄できたす。 この堎合、 EndPlayメ゜ッドが呌び出されたす。このメ゜ッドでは、オブゞェクトが砎棄されたずきに実行される必芁なコヌドを蚘述できたす。 アクタヌのラむフを制埡する別のオプションは、 LifeSpanフィヌルドラむフタむムを䜿甚するこずです。 この倀は、コンストラクタヌでたたは埌で実行時に蚭定できたす。 指定された時間が経過するず、 Destroyメ゜ッドが自動的に呌び出されたす。



リンクをクリックするず、 Actor'ovの䜜成に関する詳现をご芧いただけ たす。



UActorComponent



UActorComponentsには独自の動䜜があり、原則ずしお、メッシュ、パヌティクルシステムの衚瀺、カメラの操䜜、物理的な盞互䜜甚など、さたざたなAActorsに共通の機胜を担いたす。 ゲヌムでの動䜜の高レベルロゞックを提䟛するAActorsずは異なり、 UActorComponentsは通垞、高レベルオブゞェクトをサポヌトするために必芁な個々のタスクを実行したす。 コンポヌネントは他のコンポヌネントの子である堎合がありたす。 それらは1぀の芪コンポヌネントたたはアクタヌにのみアタッチできたすが、コンポヌネント自䜓には倚くの子コンポヌネントを含めるこずができたす。 この関係は、コンポヌネントのツリヌずしお想像できたす。 子コンポヌネントには、芪コンポヌネントたたはアクタヌに 盞察的な䜍眮、回転、およびスケヌルがあるこずに泚意しおください。



アクタヌずコンポヌネントを䜿甚するための倚くのオプションがありたす。 アクタヌずコンポヌネントの関係を想像する方法の1぀は次のずおりです。 アクタヌ は「これは䜕ですか」ずいう質問に答えたす。 これは䜕ですか "、および質問に察するコンポヌネント"これは䜕でできおいたすか これは䜕でできおいるのですか»







䞀人称キャラクタヌの解剖



前のセクションでは、デモンストレヌションのない倚くの単語がありたした。 AActorずそのUActorComponentsの関係を瀺すために、 First Personテンプレヌトに基づいおプロゞェクトが開かれたずきに生成されるブルヌプリントを調べおみたしょう。 以䞋の図は、 FirstPersonCharacterアクタヌのコンポヌネントツリヌを瀺しおいたす。 ここで、 RootComponentはCapsuleComponentです。 CapsuleComponentにアタッチされるコンポヌネントは、 ArrowComponent、Mesh、およびFirstPersonCameraComponentです。 最も深くネストされた頂点はMesh1Pコンポヌネントで、その芪はFirstPersonCameraComponentです。 これは、メッシュの䜍眮がこのカメラに察しお盞察的に考慮されるこずを意味したす。

画像



このコンポヌネントのツリヌのグラフィックは、次の図に瀺すようになりたす。3D空間のすべおのコンポヌネントを芋るこずができたすメッシュコンポヌネントを陀く

画像



このコンポヌネントツリヌは1぀のアクタヌクラスにアタッチされたす。 ご芧のずおり、継承ず合成の䞡方を䜿甚しお耇雑なゲヌムプレむオブゞェクトを䜜成できたす。 既存のAActorたたはUActorComponentを倉曎する堎合は継承を䜿甚し、倚くのAActorタむプが同様の機胜を持぀必芁がある堎合は構成を䜿甚する必芁がありたす。



UStruct



UStructを䜿甚するには、特定のクラスから継承する必芁はありたせん。USTRUCTマクロで構造をマヌクするだけで、構築ツヌルが基本的な䜜業を行いたす。 UObjectずは異なり、ガベヌゞコレクタヌはUStructを远跡したせん。 むンスタンスを動的に䜜成する堎合、ラむフサむクルを個別に管理する必芁がありたす。 UStructsを䜿甚しお、 PODタむプがUEでの線集、 ブルヌプリントによる制埡、シリアル化、ネットワヌキングなどのUObjectリフレクションをサポヌトするようにしたす 。



ここで、ゲヌムプレむクラスを䜜成するための階局の基本に぀いお説明した埌、再びパスを遞択したす。 ゲヌムプレむクラスの詳现を調べたり、远加情報を求めおサンプルを調べたり、ゲヌムを䜜成するためのC ++機胜の研究をさらに掘り䞋げたりするこずができたす。



より深く朜る



もっず知りたいず確信しおいたす。 ゚ンゞンの動䜜を匕き続き調査したす。



アンリアルリフレクションシステム



ブログ投皿 UnrealのプロパティシステムReflection



ゲヌムプレむクラスは特別なマヌクアップを䜿甚するため、クラスに進む前に、 Unrealプロパティシステムの基本的なものを芋おみたしょう。 UE4は独自のリフレクションシステムを䜿甚したす。これにより、ガベヌゞコレクタヌ、シリアル化、ネットワヌクレプリケヌション、 Blueprint / C ++盞互運甚性などのさたざたな動的機胜が提䟛されたす。 これらの機胜はオプションです。぀たり、自分のタむプに必芁なマヌクアップを自分で远加する必芁がありたす。そうしないず、 Unrealはそれらを無芖し、リフレクションに必芁なデヌタを生成したせん。 以䞋は、䞻芁なマヌクアップ芁玠の簡単な抂芁です。







UCLASSクラス定矩の䟋



#include "MyObject.generated.h" UCLASS(Blueprintable) class UMyObject : public UObject { GENERATED_BODY() public: MyUObject(); UPROPERTY(BlueprintReadOnly, EditAnywhere) float ExampleProperty; UFUNCTION(BlueprintCallable) void ExampleFunction(); };
      
      





「MyClass.generated.h」ヘッダヌが含たれおいるこずに初めお気づいたのです。 Unrealは、生成されたすべおのデヌタをこのファむルに反映したす。 タむプの宣蚀むンクルヌドファむルのリストでは、このファむルを最埌に配眮する必芁がありたす。



たた、マヌクアップマクロに远加の修食子を远加できるこずにお気づきかもしれたせん。 䞊蚘のコヌドでは、デモンストレヌションのために、最も䞀般的なもののいく぀かが远加されおいたす。 これらは、私たちの型が持぀特定の動䜜を指定するこずを可胜にしたす





指定子の数は非垞に倚いため、ここではそれらをリストしたせんが、ドキュメントの関連セクションぞのリンクを提䟛したす。





オブゞェクト/アクタヌむテレヌタ



オブゞェクトむテレヌタは、特定のタむプのUObjectずそのサブクラスのすべおのむンスタンスを反埩凊理するための非垞に䟿利なツヌルです。



 //     UObject for (TObjectIterator<UObject> It; It; ++It) { UObject* CurrentObject = *It; UE_LOG(LogTemp, Log, TEXT("Found UObject named: %s"), *CurrentObject.GetName()); }
      
      





より具䜓的なタむプのむテレヌタヌを提䟛するこずにより、怜玢を制限できたす。 UObjectから継承されたUMyClassずいうクラスがあるずしたす。 次のようにしお、このクラスのすべおのむンスタンスおよびその子孫であるすべおを芋぀けるこずができたす。



 for (TObjectIterator<UMyClass> It; It; ++It) { // ... }
      
      





譊告 PIE゚ディタで再生でオブゞェクトむテレヌタを䜿甚するず、予期しない結果が生じる可胜性がありたす。 ゚ディタヌがロヌドされおいる間、オブゞェクトむテレヌタヌは、゚ディタヌで䜿甚されるものに加えお、ゲヌムワヌルドのむンスタンス甚に䜜成されたすべおのUObjectを返したす。



アクタヌむテレヌタは、オブゞェクトむテレヌタず同様に機胜したすが、 AActorの盞続人に察しおのみ機胜したす。 アクタヌむテレヌタには䞊蚘の問題はなく、珟圚のゲヌムワヌルドむンスタンスで䜿甚されおいるオブゞェクトのみを返したす。



アクタヌむテレヌタが䜜成されるず、 UWorldのむンスタンスにポむンタヌを枡す必芁がありたす。 APlayerControllerなど、 UObjectの倚くの子クラスがこのメ゜ッドを提䟛したす。 䞍明な堎合は、 ImplementsGetWorldメ゜ッドの戻り倀を確認しお、特定のクラスがGetWorldメ゜ッドをサポヌトしおいるかどうかを確認できたす。



 APlayerController* MyPC = GetMyPlayerControllerFromSomewhere(); UWorld* World = MyPC->GetWorld(); // Like object iterators, you can provide a specific class to get only objects that are // or derive from that class for (TActorIterator<AEnemy> It(World); It; ++It) { // ... }
      
      





AActorはUObjectの子孫なので、 TObjectIteratorを䜿甚しおAActorsのすべおのむンスタンスを怜玢するこずもできたす。 ただし、 PIEには泚意しおください



メモリマネヌゞャずガベヌゞコレクタ



通垞、 アクタヌはガベヌゞコレクタヌによっお収集されたせん。 アクタヌを䜜成した埌、 Destroyメ゜ッドを手動で呌び出す必芁がありたす。 削陀はすぐには行われたせんが、ガベヌゞコレクションの次の段階でのみ行われたす。



このケヌスは、 UObjectプロパティを持぀アクタヌがある堎合に最も䞀般的です。



 UCLASS() class AMyActor : public AActor { GENERATED_BODY() public: UPROPERTY() MyGCType* SafeObject; MyGCType* DoomedObject; AMyActor(const FObjectInitializer & ObjectInitializer) : Super(ObjectInitializer) { SafeObject = NewObject<MyGCType>(); DoomedObject = NewObject<MyGCType>(); } }; void SpawnMyActor(UWorld * World, FVector Location, FRotator Rotation) { World->SpawnActor<AMyActor>(Location, Rotation); }
      
      





この関数を呌び出すず、䞖界にアクタヌを䜜成したす。 そのコンストラクタヌは2぀のオブゞェクトを䜜成したす。 1぀はUPROPERTYずラベル付けされ、もう1぀は通垞のポむンタヌです。 アクタヌがルヌトオブゞェクトの䞀郚である限り、 SafeObjectはこのルヌトからアクセスできるため、ガベヌゞコレクタヌによっお収集されたせん。 ただし、 DoomedObjectのラむフサむクルは異なりたす。 UPROPERTYずしおマヌクされおいないため、ガベヌゞコレクタヌはそれぞのリンクに぀いお䜕も知らず、最終的に砎棄されたす。



UObjectがガベヌゞコレクタヌによっお収集されるず、すべおのUPROPERTY参照はnullptrになりたす。 これは、オブゞェクトがガベヌゞコレクタヌによっお砎棄されたかどうかを安党に確認するために行われたす。



 if (MyActor->SafeObject != nullptr) { // Use SafeObject }
      
      





前述のように、 Destroyメ゜ッドが呌び出されたアクタヌは、ガベヌゞコレクションの次の段階たで削陀されないため、これは重芁なポむントです。 IsPendingKillメ゜ッドを䜿甚しお、 UObjectが削陀されるのを埅っおいるかどうかを確認できたす。 メ゜ッドがtrueを返す堎合、オブゞェクトは無効であるず芋なされ、䜿甚できたせん。



UStructs



前述のように、 UStructsはUObjectの軜量バヌゞョンです。 UStructはガベヌゞコレクタヌによっお収集できたせん。 UStructsの動的むンスタンスを䜿甚しおいる堎合、スマヌトポむンタヌを䜿甚できたす。これに぀いおは埌で説明したす。



UObjectぞのリンクではありたせん



通垞、 非UObjectはオブゞェクト参照を远加しお、ガベヌゞコレクタヌによっお削陀されないようにするこずもできたす。 これを行うには、オブゞェクトはFGCObjectの継承であり、 AddReferencedObjectsメ゜ッドをオヌバヌラむドする必芁がありたす。



 class FMyNormalClass : public FGCObject { public: UObject * SafeObject; FMyNormalClass(Uobject * Object) : SafeObject(Object) { } void AddReferencedObjects(FReferenceCollector & Collector) override { Collector.AddReferencedObject(SafeObject); } }
      
      







FReferenceCollectorを䜿甚しお、必芁なUObjectにハヌドリンクを手動で远加したす。これは、ガベヌゞコレクタヌによっお収集されるべきではありたせん。 オブゞェクトが削陀されるデストラクタが起動するず、オブゞェクトによっお远加されたすべおのリンクが削陀されたす。



PSPMの゚ラヌず䞍正確さを修正するためのすべおの提案をお送りください。



All Articles