What are these higher level blueprints??

What is Level Blueprint, GameMode, GameInstance, GameState, and HUD?

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. 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.


Level blue print is the BP for the current level.

One thing i’ve used it for is getting the sun that is in the level and updating it’s rotation for day/night
also if there was a level timer (escape in 5 minutes before the core explodes!!!) you could put it there.

Basically things that you would only need when the level is open and not saved on/with the character or, targeting/interacting with things in the level.
See level stuff.

The HUD would be where you put the stuff you see on screen. Like a widget: health bar, current ammo etc. Basically it’s an image put between the camera and the actor you’re controling.

Level blue print might have the level timer. Or at least into that it would send to the character’s timer. If you wanted it to get dark when timer was 1/2 down you could do that there.
That way your character doesnt have to have a variable, begin play 90 seconds, counting down from moment level starts.
Each level could have it’s own timer built in.

The HUD would have something like a text box. You would bind it to the variable in the character you name something like “score” it would constantly print out your score.

In that image, the number zombies killed, the HP bar, the ammo count, satchel are all part of my main hud.
(the joysticks, jump button and reload button are in the virtual joystick and is just turned on so no worries on the blue print stuff there)

My level has a BP that rotates the sun
Event tick, set rotation, the sun plugged in.
15x delta time
When my sun is in a certain rotation rate, it turns on that lamp…

I recommend that you watch these 2 videos:


Here’s a quick cheat sheet for Single-Player: The engine is so massive that it can help to figure out what parts you can safely ignore for now… Higher Level-Blueprints bring structure but they’re just a framework… So like anything else built on rules, you can bend them a little and more so in Single-Player…

Pawn / Character - [Essential].
Create your car, spaceship, character, weapons etc here. Assemble the mesh and control the mechanics and camera here. Question: Why not do some or all of this in Player-Controller or Gamemode etc? You can and most devs prefer to. But for simple single-player games its easier and simpler to just do it all here instead. Question: What’s the difference between Pawn / Character? Answer: Lots… Epic has written a huge amount of code that underpins Character. This helps to simplify everything from animation to movement to multiplayer replication etc. But it also brings disadvantages and loss of control (non-biped characters etc).

Player-Controller - [Optional but important]
The PC Blueprint itself is technically optional (just use a placeholder or what’s called a data blueprint). However PC objects in general are a crucial object to understand in the context of the engine. Player-Controller might control all the gamepad inputs in your game. It might control all the different cameras too, for example (a death-cam)… If the Pawn is killed, it might also respawn a new one etc. But this kind of functionality can also be done in Gamemode too (unless you cheat and hide the character or pawn every time rather than destroying it)…

**Gamemode **- [Optional but important]
Usually this houses Game-Rules but its optional. For simple games you can just use Pawns / Characters to house game logic for now, as you won’t break anything. Gamemode or Player-Controller can be used to respawn a new car if the player is killed, or keep track of scores, or the length of the game, or overall game preferences etc. But as mentioned, you can cheat too, by just hiding a killed pawn, so no respawn is needed (or rely on Player-Controller as mentioned above). Limitations: If a new map or level is loaded the state of every game object is lost, so use Game-Instance in conjunction with Gamemode (or save out to a database).

Level-Blueprint [Optional]
For prototyping its often useful to place code here as its easier to access level objects directly. But long term its better to avoid putting anything here, except purely ‘cosmetic’ code.

Game-Instance - [Optional]
Want to keep player scores as you move between levels or open up a new Deathmatch map? Use this or save out to a Database etc. This class becomes much more important in Multiplayer.

**HUDs **- [Optional]
Basic legacy 2D screen menu system made vastly redundant because of widgets. But far easier to set up as regards simple gameplay text or texture displays.

Widgets - [Optional]
Gives you the ability to create advanced UI elements inside the world itself. When done right it provides very powerful in-game functionality for gameplay. Imagine flying a jet-fighter where the entire cockpit contains in-game buttons that can be clicked on to fly the craft, fire weapons, trigger countermeasures, or access radar or other enemy tracking systems etc.

Gamestate - [Optional]
Mostly relevant in Multiplayer

Player-State - [Optional]
Mostly relevant in Multiplayer

Most of these has “special” events and behaviour.
The difference in behaviour are

  • Their replication
  • How they are initialized after each other.

Gamemode only exists in server, so only have data and function that is only needed for the server. Also gamemode has an event you can capture when a player joins the server (event postlogin)

Gamestate is replicated to the clients as well, but the owner is the server. Also it has the list.of currently connected players (and their playerstate).

The same gameinstance always exists regardless of mapchanges (and it does not replicates) so you can use it store - for example - to data that needs to be present regardess the map (like settings?)

Go to the function of these bluprints and at “override” you can check what built-in functionlity each has.

Thank you so very much everyone! I apologize for the late response…I didn’t get a notification that someone had replied. I have a much better understanding. :slight_smile: