What are these higher level blueprints?

Development Programming & Scripting Blueprint
, ,
1

What are these, GameInstance, GameMode, GameState, Level Blueprint and HUD for? All the info on these in the Unreal Docs seem to have been written by a robot programmer. I need it in human, non-programmer terms. :smiley:

So, over the past week, I’ve watched ALOT of tutorials, and read ALOT of docs and I feel I’m still not any closer to understanding the WHATs, WHYs and HOWs of these…Classes?..I guess, if they are Classes…maybe Blueprints. Everyone says, “yea, the GameInstance is Persistent”, or “the GameMode is where you set rules”, or “the Level Blueprint is where you put Level related stuff” …but, what does that all mean? Should I assume the HUD is where I put interface controls and logic?

Can someone give me a example of the, When I Should Use, What Are They Used For, and most importantly, Why…Why do I put things there?

I saw a article on this forum where the dude asked for it in terms of a baseball analogy…LoL… I don’t know baseball…so…woooosh…over my head.
Say I’m building Mario, or Tetris, or Angry Birds, or Metal Gear Solid, or Halo… how would I organize my blueprints using these? (Mostly interested in single player aspect)

I read about Server/Client stuff and how these relate… woooosh…over my head. Is that something I need to worry about for a single player game?
I read about different levels of persistence… what’s the hierarchy look like? Should I care? I know it depends on my game, but say I’m making Halo, what does persistence mean to me?

Almost 90% of the tutorials use GameMode to assign the player. It’s usually left blank…Why? What can I use it for?

If someone here can give me a detailed look at these classes and their uses and why, I will super appreciate it.

Thanks!

2

So there is a lot of stuff in there but I will try and help straighten some of it out as best I can. I will do a Call Of Duty analogy for you since I don’t know Halo as well and it’s been years since I played haha but here goes.

Game Mode:

sets the “rules”, ok so Game Mode basically determines when you start the level what “pawn” class you control, so are you a tank, an infantry or are you bombing the enemy from a C130. Game mode will determine that. It sets the “default” classes which include “pawn”, “game instance”, “player state” etc. These are all high level classes BUT game mode’s job is to say “this level is going to be played using this particular game instance, player pawn, player state etc”.

Game Instance:

This is “persistent”, so it survives and remembers all data and information it contains until you turn off the device you are playing your game from. This is important because if you finish your bombing level in the C130 and now you are placed on the ground shortly after the bombing as a foot soldier the game probably loaded a new “level” even though the battlefield is the same, the “Game Instance” will remember if you killed that building previously from the air or if there are still enemies left in it because it doesn’t matter how many “levels” you change or complete, “Game Instance” will remember whatever you want it to remember between levels.

Game State:

Haven’t used this one much so won’t comment but it is another container blueprint to hold information

Level Blueprint:

This is the top of the BP hierarchy for “Level” specific details. Things that ONLY pertain to a specific level/world you are creating and no other can be stored here. This knows all actors present in the world and references can easily be created to any actor in the level from within this blueprint. The level BP might hold something like “player score” for a particular level, while the “Game Instance” would hold the “total score” collected over multiple levels. The level would most likely hold your “objectives”, capture this enemy, kill this many targets etc and it would determine when you have successfully completed those objectives.

Server/Client:

Usually used on multiplayer games BUT even single player games if you want to hold data anywhere but a player’s individual device you will need a server of some sort. And anyone who uses that server is a “client”. So if you had a simple single player game like candy crush if you want to save data off the phone you would need a server. If your goal is to just play a game on one device and it never communicates with anything else or anyone else for anything then everything is self contained on one device and you don’t need a server. If you want anything like a leader board or to send updates you would need some sort of “server” and “client” relationship.

Hope that helps get you on the right track at least, it is not an exhaustive explanation but it’s a start.

3

Because Game Mode class is not replicated (quick explanation replication technical word for client server sync, since clients trying to “replicate” game state from server why client sent data related to local playe) to clients for security reasons (to prevent client from any data/server manipulation) which means it does not exist and you can’t get data or do any direct calls to it from client side.

Thats why GameState exists, it is kind like replicated extension of game mode, in game state you put data from game mode that you want clients to have access to things like time limit, score board, overall non-player game stats etc.

Same goes with PlayerController and PlayerState

4

Player character is the default “Pawn Class” you control during gameplay. So in Call of Duty sometimes that is a soldier, sometimes it’s a Vehicle sometimes it’s a gun on an aircraft. When you die as a soldier for example and are in multiplayer you end up in like a limbo before getting respawned back into the game. At that point any guns you were carrying and ammo that you had go back to default BUT your number of kills for example do not, that “persists” because it is stored elsewhere likely on a player controller. The controller survives death so anything stored on a controller will remain after death. Anything stored on the player character will be wiped clean each time you die.

5

Ahh!! Your explanation should be in the official docs, Nebula

A few follow ups:
The Player Character: I kinda understand this…but I’m a little fuzzy on the concept of death. When the player dies in Call of Duty, or starts a new level, what happens to that object? Is it destroyed? If so, this means that between levels and death, any data/variables I have on it is lost during transition? Anything I wanna keep should be on the GameInstance.

6

Yes, data stored on a pawn such as PlayerCharacter will die with the pawn, but PlayerController variables live as long as the controller does (which is usually the whole time you’re in a particular level), PlayerState also dies when a level unloads. However, PlayerControllers don’t “see” each other in multiplayer across the network. Player controller 0 will be a totally different object on machine 1 than it is on machine 2. To replicate info specific to players, that survives when their pawns die, use PlayerState.

GameInstance stays alive between levels, basically lives the whole time the game is running and only dies when the game closes, but GameInstance only exists by itself on each computer and cannot replicate between machines on a network or between instances of the game running.

Gamestate replicates between machines but does not survive between levels. So sometimes I use the GameInstance to copy info between levels when the players travel to another level.

7

Can you say a bit more on REPLICATE and what that process is, please?

8

To explain replication, first understand that every machine that connects to a networked game has their own copy of the game’s world running on that machine, and it has its own version of everything that is happening. If a pawn turns left on one machine it doesn’t necessarily turn left on all the others, and so their respective versions of the universe will get out of sync.

Because of this, there needs to be one machine whose version of the universe is considered to be the Authority, or the “true” universe. To enforce that version of the universe on all the other machines and make them match, it can be set to copy some of the variables’ values and objects or actors onto those connected client machines, thereby making them match the server’s version of the world.
This is called “replication.”

You don’t want to replicate EVERYTHING, or even replicate some things ALL the time, or you’ll flood the connection and slow it down with too much data waiting to get sent and received, or it will have to choose to drop some of those packets in order to keep up with reality.

So we set some Actors, their components, and/or variables to be replicated.
Remember this only goes from Server to Client, not the other way around.

So in order to change something on the Server, you have to use a special kind of Event called a Remote Procedure Call (RPC), which you can do simply by setting the Replication variable on any given Event (red node) to say Run on Server, and then you can call it like a function (blue node) on the Client and it will run on the Server. You can even pass parameter variables along.

there’s another kind of RPC called a Multicast that runs on all connected machines, but this will only do so if it is run from the server (the Authority) machine. Done from anywhere else it just runs normally on its own machine.

The last kind of RPC is a target Client RPC, which is the Server calling a function only on one client specific machine, which connection is playercontroller

9

Again, trying to do a Client RPC from a Client will not work to trigger the function on another client, because clients don’t own each other’s connections or playercontrollers. They have to pass everything through the Server to reach each other (this prevents cheating and keeps the worlds in sync).

Replicate Movement is an option on Pawn classes which automatically replicates the pawn’s Control Rotation, Location, and Actor Rotation across the network, but be aware, this is merely copying those values without any prediction or smoothing to make it look good between network updates (which typically happen at a rate much slower than your framerate), unless you’re using a Character pawn class or a child class of that. So if you want smooth movement across network you have to figure out all the fun buffer interpolation around that yourself, unless you’re using Character Movement.

CharacterMovement can deceive you into thinking that replication normally goes from client to server as well, but that’s a special case for that class and its child classes, and only for movement. Normally it only goes server to client and you have to use RPCs to change things on the Server from the Client.

10

Well Explained, Thank you so very much!