I’d like to know more about UGameInstance. I know it’s an object spawned at game creation and only destroyed when the game shuts down. In the API it also says that running a standalone game, there will only be one, but in PIE there will be one for each instance. Is this the case on dedicated servers as well? Will there be a GameInstance for each connection?
This is something I’d really like to know, as I’m experimenting with dedicated servers and travelling atm. Also, if there are only one GameInstance that are shared between clients, how would I go about transfering data only for one specific player and retrieve it on my server?
Yes each executable running will have its own GameInstance, no matter which machine it is on (server or client).
Not sure how it works with Dedicated Servers though.
GameInstance does not replicate, but persists between level changes and joining sessions, server/client travel etc. So it’s a good way to remember what you need to sync between the server and clients once the client has joined the server’s level. For example if you choose a certain skeletal mesh on the client and then join the server, which destroys your pawn, gamestate, gamemode, playerstates and controllers and replaces them upon joining, then you can wait for something like the gamestate or playerstate to start up anew on the client who has joined, and then fetch the remembered selection from the client’s GameInstance, have the new playercontroller send an RPC to the server telling it which skin you chose, and have the server’s GameState multicast or set with repnotify or at least a replicated variable, to get all the other clients to put that skin on the same pawn in their own versions of the universe that they’re running.
(rule of thumb: PlayerControllers are usually best for Server RPCs, GameState is usually best for Multicasts. Some blueprints will silently fail to send RPCs of certain types because they don’t own the connections necessary to do it, like Level blueprints for example)
GameInstance is really helpful for remembering preferences like music on/off etc after loading them from file when the game starts, between level changes, too. This way you can have the game remember your settings each time you start it up.
This is very valuable information! I’m also assuming GameInstance would persist per client on dedicated servers as well, would make sense. Alot of thanks, it’s highly appreciated!
I’m not sure what you mean, but I can say that GameInstance exists as long as the game is running. If the server machine’s game shuts down, then the GameInstance will be destroyed. It should exist at all times that the game itself is running. Every machine gets its own GameInstance, and no GameInstance can see anyone else’s or access the others’ variables. It is not replicated over network.
So any machine, server or client, that shuts down their copy of the game will also destroy their own GameInstance (along with all other objects from memory) when the game shuts down, because the games do not have any background process to keep anything in memory. Close the game, and all objects in the game and anything else the game allocated in memory, will be removed from the system’s RAM memory. This is normal and simplest use case for any executable computer program.
kk that was helpful thank you.
i was understanding this why they call destroy function.
so that means if in any case our server Gameinstance is shutdown then we have to shutdown our server too.
does that happen by the way?
I’m sorry I don’t know, because I never have used an online subsystem before, let alone GameLift. I think it is really up to you whether you want to shut down your instance on GameLift when the game exits, or not. You could keep the GameLife instance running and waiting for the game to start back up but that depends on how you want to run things and what works best for you. also I am not sure if that Destroy node actually shuts down GameLift instances or not. If it is not specifically a GameLift node, then I think it doesn’t, and you’d have to send command specifically to GameLift to have the Unreal instance cause GameLift instance to shut down. Probably. Like I said, I don’t know.
And remember: Game Instances only exist on each machine running the game, and cannot communicate any in-game data to the other machines in the networked game. You can think of a Game Instance as “The Game running on my machine, which only I can access data from”).
This can be confusing because it’s usually best to use the Game Instance to CONNECT to other machines, as it has functions to do that, but it does NOT replicate anything between the machines it connects you to. That is the job of other object or actor classes.
