This is a fundamental and organizational but basic type of question(s) that I’m trying to wrap my head around. I’ve read the documentation on Game Modes, and watched a few videos but it’s still unclear to me how to answer your own questions on when and what to do when adjusting Game Modes. So in an effort to better understand how Unreal manages data, I’ll try and make more specific questions here and hopefully get some insight from you awesome people.
Can and should a game contain more than one Game Mode Blueprint? Why?
Do you create a new game mode for pause menus and start menus? Does this also mean you need new pawn classes to control said menus?
When isolating and organizing work, is it a good practice to place menu systems in their own levels/maps? How does this correlate with pause menus or inventory menus that need to exist in-game; do those exist on separate maps as well? If this is the case (as many youtube videos suggest) how do you call these menus without significant lag?
I have more questions regarding the organization of these blueprints but I’ll start here. Any reading or insight would be really helpful, as I’m not sure how to ask these types of questions in documentation or video hunting on youtube.
My project only has one GameMode, and its main purpose is to be a container that sets all the other gameplay-critical stuff like which GameState Class, default Playercontroller etc. although it does handle a few things for managing players, starting stuff on levels etc.
This is largely
because my project is a multiplayer only game so Gamestate is doing most of what you would use GameMode for but in a multiplayer scenario.
My menus stand alone. I have a level mainly for menus to setup the game options but i also have some of these same menu widgets pop up during gameplay on other levels. It is the Viewport, not the level which contains them, unless youre using 3D widget actor components (those exist in the level). But even those dont have to be tied to the level, you can just spawn, show/hide, enable/disable or destroy them at will regardess of what level or how you are using them.
This is the best video I’ve seen so far to help shine some light on these questions. Thank you @mightyenigma for your response. This does help too.
I still don’t know the answer to all these questions, but the video at least implies that you don’t have to have different game modes just to do a menu. You can utilize Unreal UI Input nodes to activate or deactivate how the player inputs with the game.
Level Streaming menus do appear to make the most sense in this use case, but I’d be curious how to do this with various game designs that don’t focus on level streaming, so all the questions still kinda stand. @mightyenigma, maybe a better question is “When should you use multiple Game Mode blueprints?” Are there good examples of this anywhere I can look?
A game can contain more than 1 Game Mode blueprint. Because you can use game mode to set current level player controller, hud and spawn actor type, so with one level, you can have DeathMatch game mode, with DeathMatch player controller, while on another level, you can have CaptureFlag game mode, with CaptureFlag player controller, each game mode can has it’s own game rule and win/lose condition, etc etc… So in short, it is to divide your blueprint into smaller module, for ease of coding/update/ understanding…
No you don’t have to create game mode for pause menu and start menu. And this also mean you don’t need pawn class to control said menu, in fact you can choose to have none as your game mode pawn class.
Unless it is a big menu like main menu, or some task that require user to work purely on menu, or you would love to implement level streaming system, then I would recommend you do that. Pause menu and inventory menu typical doesn’t exist on separate map, unless again, there is some task that user need to work purely on menu, I usually just implement some widget and add them to viewport whenever I need them and remove/ hide them from viewport when I done with them. The point is that it cost less to create 1 widget then show/hide or add to viewport/remove it 100 times than create 100 widget every time you need it, especially if you also use Tick function inside each widget.
Thank you for your reply! This helps a ton. So as an example… Let’s say I have a 3rd Person Action game that has a mini-game in it to access a secret area. Would the mini-game be better served as a self contained, separate Game Mode with different rules and conditions? Or should the global aspects of the game mode simply be added to the primary one? Can these Game Modes be called and changed at any time? On the fly?
I am not sure when to use multiple game modes, except in unreal tournament for example, you want Deathmatch to have different rules than Capture the Flag, because in CTF you count the kills but the flag captures are the only thing that actually wins or loses the game, and it also changes how and where and when you can respawn and which Levels it would use.
In your example, it will depend on how complex that mini game is, if it simple enough to be implement with 2 or 3 blueprint function then i wouldn’t bother create a separate game mode, and i would put those rule of the mini game into the current level game mode. On the other hand, with a really complex mini game, then sure, i would love to put those game into a separate level with it’s own game mode, rule and condition. Note that you can still pass data between different game mode, using GameInstance, which is a kind of global blueprint that can be access from anywhere.
And it is a shame but each level can only have one GameMode and you can’t change it on the fly, at least from Blueprint side, i think there is a topic on AnswerHub about switch GameMode with C++. But you can assign a GameMode as GameMode for the entire project, or you can have a different GameMode for each and every level.
The below tutorial series develop a system where multiple GameMode was used for each stage of an multiplayer game, from finding match->waitting room->select character->in game
