I have prototyped a racing game and would like to add three different gameplay modes: (1) Time Trial, (2) Free Race, and (3) Two-player Versus. There is no online play.
Q1: Should each of these modes be put into its own separate Game Mode Blueprint?
Q2: Should the main menu, sub-menus, etc be put into a Game Mode Blueprint as well? For example, BP_MenuSystem or something like that.
If you have any other advice about best practices for game mode organization that would be great.
GameMode only runs on servers, so putting UI in there is generally a bad idea.
Typically, you’ll build your UI as specific UMG widgets, and then you’ll use the player controller as the thing that adds the UI to the screen when it begins play (and removes it when it ends play, if you re-create player controllers when changing games/servers.)
For the game rules, you can use a different GameMode for each rule set, but you can also just switch on some “current mode” variable instead – both mechanisms work, and which one is better, depends on specifics. If your maps are largely built to support one specific kind of mode, using a specific game mode class makes sense. If your level is a generic track, and the player can start a new game mode on the fly on the same track, you may instead want to put the specifics into a few if statements or somesuch.
@jwatte great answers as always, thank you.
The idea is that when the game starts the player lands on a main menu screen, selects a save game slot, then lands on a mode select screen. After selecting a mode, the player then selects a level (track) and the level loads.
Importantly, all levels will be available in all three game modes. In other words, the levels are generic and can support all game modes. (This is the second scenario you described.) I’m persuaded that the Player Controller Blueprint is the best option.
When the level loads it must somehow know which mode the user selected. What’s the best way to handle this? One idea is that when the user selects the mode and track, the UMG widget will set a CurrentMode variable then Open Level will be called to load the level. After the level loads, CurrentMode will be used to configure the Player Controller Blueprint.
Also, I like the idea of having different three different Player Controller Blueprints to encapsulate the logic for the three different game modes. What do you think of this idea?
It doesn’t ultimately matter in the sense that you are able to do it either way because it’s not an online game, but you would rather encapsulate that logic in the game mode class over the player controller class. GameMode is server-only level-persistent, PlayerController is local and level-persistent. And in this instance, server = local.
You can create multiple versions of the same level for the the different game modes (or even just composite the levels with i.e the base with environment being the same, but adding i.e TimeTrial checkpoints sub level to the Time Trial version of the level) or if using the same level for everything, determine the game mode override for the level by appropriate launch parameters when opening the level.