{"id":168,"date":"2020-04-05T08:16:20","date_gmt":"2020-04-05T08:16:20","guid":{"rendered":"https:\/\/sgarces.com\/?p=168"},"modified":"2020-04-05T08:16:20","modified_gmt":"2020-04-05T08:16:20","slug":"the-forest","status":"publish","type":"post","link":"https:\/\/sgarces.com\/?p=168","title":{"rendered":"The Forest"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

When I started using Unreal<\/em> I had experience with several in-house engines as well as Unity<\/em>. There are a number of concepts that are common to almost all engines and, once you understand them, you come to expect them and rely on them.<\/p>\n\n\n\n

I couldn’t find a good resource that would break down how Unreal<\/em> implements these common concepts. Often, people talk about how to do simple things (like getting a character up on screen) or describe the parts Unreal<\/em> consists of, without explaining how they typically get used.<\/p>\n\n\n\n

What I want to do here is to write the high-level view of how I’m using Unreal<\/em>‘s architecture. It’s important to play nice with the engine (fitting a round peg in a square box is a bad idea) while building an architecture that will scale to the scope of your game. This article forgets the trees and focuses on the forest<\/em>.<\/p>\n\n\n\n

Starting from the Top<\/h2>\n\n\n\n

There is a big difference between a tech demo<\/em> and a game<\/em>.<\/p>\n\n\n\n

If your project doesn’t have multiple screens, if it doesn’t have a way to save game state, if it doesn’t have many different game modes, if it doesn’t have loading screens or streaming, then it’s a tech demo and you have a lot of work ahead of you.<\/p>\n\n\n\n

Almost every game has an object (often a Singleton) that represents the entire game. This object persists across screens and modes and serves as the connective tissue for the entire experience.<\/p>\n\n\n\n

In Unreal<\/em> the easiest way to fulfill this role is to subclass UGameInstance<\/a><\/em>. This object is created early when the game boots, and the function Init()<\/em> gets called. It will survive through level changes and can be easily accessed from the World object.<\/p>\n\n\n\n

Note that the simple examples that come with Unreal don’t<\/strong> do this. They just set up a Game Mode (which we’ll discuss later) because they are tech demos.<\/em><\/p><\/blockquote>\n\n\n\n

After you create your Game Instance<\/em>, you want to be able to access it easily. A nice way to do it is to create a static function in C++ and expose it to Blueprints are a Pure function:<\/p>\n\n\n\n

UFUNCTION(BlueprintPure, Category=\"Game\", meta=(WorldContext=\"WorldContextObject\"))\nstatic UMyGameInstance* GetMyGameInstance(const UObject* WorldContextObject);\n\nUMyGameInstance* UMyGameInstance::GetMyGameInstance(const UObject* WorldContextObject)\n{\n\tUGameInstance* gameInstance = UGameplayStatics::GetGameInstance(WorldContextObject);\n\treturn Cast(gameInstance);\n}<\/pre>\n\n\n\n
This will give you the same interface Unreal<\/em> provides<\/a>: \"\"<\/p>\n\n\n\n
Here’s some of the functionality I have in the Game Instance<\/em> (and therefore accessible to the entire game):<\/p>\n\n\n\n