Don’t worry, I know.
1 Like
Where would you put the logic of the game? This is why I have started to use the Game State.
Thanks.
It doesn’t really matter, game over is just a few instructions:
Show a widget working as a game over, change level/reset some settings/info
You can run it in your Player, in the Controller, in an external Actor that will trigger it
The most important stuff is Accessibility
Once you lay out your code in various places you need to be able to access them and where you run a specific code - depends on you
It matters because I don’t want to put all the code in the same class. I mean the code to move the paddle, the code to show the score, the code to restart the game, to show the game over, etc. all in the same class.
And, if there is a game framework, with classes to do such things, I want to start using.
Thanks!
Obviously you don’t wanna put everything in one place, but you cannot also avoid putting some in same place
And it’s not a big disaster if you load a Widget from Level Blueprint instead from Player Controller or HUD Class Object as long it all works as intended (widget is just an example here xd)
Also your Project is a tiny thing, you will feel no performance hit on the Game, only in the Editor when you see a large BP it may start to stutter
And here’s some known overview on what is the layout structure for specific parts, hope that will make it clear to you:
GameMode, GameState, PlayerState and so on
GameInstance (an object spawned when you launch the application and that remains the same until you close it)
GameMode (spawned when a level is loaded)
GameState (spawned by the gameMode)
PlayerState (spawned when a PlayerController is spawned = when a player arrives in the game)
You have to pay close attention to what you do and where you do it when coding a multiplayer game. When it comes to singleplayer, you can’t really “have it wrong” except for GameInstance stuff.
But here are the general guidelines I follow:
GameInstance - Holds any non-pointer persistent variables (persistent means that you need to store in between two levels and that you don’t need to store in a SaveGame)
GameMode - The overall game manager - starts and stops the current game space you’re in, handles the GameStates and how they rotate - an example might be “King of the Hill”
GameState - Keeps track of every data relative to the current state of the game (timers, scores, winning team) that all players in the game need to know about, handles scripted events related to the state
For instance:
PregameState: Prevents player from performing any action, starts a timer and display it to everyone. When timer expires, ask KotH (KingOfTheHill game mode) to rotate to IngameState
IngameState: Enable player input, spawn a big loud noise and open players’ spawn gates. Open the Capture Point and store the amount of capture time both teams have. When one of the team reaches max score, asks KotH to switch to EndgameState.
EndgameState: Destroy every player’s characters and starts a cinematic showing the PlayOfTheGame then asks KotH to rotate to ScoreGameState etc.
PlayerController - HUD, Camera, Mouse, Keyboard, Gamepad, Inputs calling actions on the Character.
PlayerCharacter - Actions in response of Controller’s input + Holds personal infos and stats (Health, Ammo - but Ammo might on your Weapon Class if you can switch Weapons).
PlayerState - Holds every variable non related to the PlayerCharacter that needs to be known by everyone (best scores, current killing streak, player name…).
I think it’s better to get used to doing things correctly, no matter how small the project is, from the moment I start programming with Unreal so as not to catch bad habits.
1 Like
That’s actually totally accurate what you said and I love it! 
That’s the spirit of a real upcoming Dev 
1 Like