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