As the title, are there reasons from epic to make game mode an instance of aactor ?
What we ususally use game mode as an actor ?
Thanks
GameModeBase is not derived from AActor. It’s derived from AInfo. It’s variant of AActor that’s an information holding class. There is no physical presents of it in the world it’s a managerial class.
I’m guessing it’s a design choice. Inside most of the functions you have copious amounts of commands involving GetWorld() and controller logic.
It also has a distinct lifecycle that works well if it can be instantiated and as the documentation states
"Actor is the base class for an Object that can be placed or spawned in a level."
so you can’t get any more bare-bones because UObject is in a sense just an abstraction of an object.
So you have
- UObject = base object, doesn’t exist in world.
- AActor = Can be spawned, has presence in word.
- AInfo = Can be spawned but has no physical representation, has extra limits placed on it than actor and stripped elements like no need for transforms etc.
So that’s why AGameModeBase is derived from AInfo
Technical nitpick but it is derived from AActor because AInfo is. AActor->AInfo->GameModeBase.
Can’t be sure of the exact reasons but the most sensible reasonings would be easy integration with the World and replication. Instead of making that functionality all over again, everything that is not needed is overridden. UCLASS specifiers prevent the GameMode from being rendered or placed into a level.
GameMode is spawned into the level when you play and can be seen in the outliner.
class AInfo : public AActor
AInfo is subclass of AActor
I now use GameMode as the place where I inject dependency like dagger framework.