Proper Class type for Derived GameModes all in One Level?

[markcham]

I’m creating an aim training game. I have a seperate level for the main menu, and the shooting range. These both have their own GameModes that I’ve created that work fine, called MainMenuGameModeBase and RangeGameModeBase. They switch between the two when I press start game or quit game using the user interface in game.

My aim training game only has one “game mode” currently, but I want to add more that the player can choose from in the menus. I know that there will be a lot of shared functionality between them, so I want a parent class that can implement those shared functions, and make child classes for each individual “game mode”.

However, I don’t know if it’s good practice to derive from RangeGameModeBase for these child “game modes”. From my searching, it looks like one GameMode per level is the standard practice, but creating 20 identical levels just so they can be assigned their own game mode seems like a waste of resources. Is there a way to implement child classes derived from RangeGameModeBase without creating more levels? Or should I change the class type to something besides GameMode?

Thanks,
Mark

[BlackmarsGames]

Your game mode classes should all derive from RangeGameModeBase if it contains base class functions the derived class will need to use.

To dynamically specify which game mode to open a level with, you can use the options parameter to change the game mode you want the level to use.

This forum question should get you moving in the right direction.

Changing gamemode at runtime.

I just wanted to check what was needed to change the gamemode at runtime. I setup a dummy level with all of the current gamemode options desired, and can’t get GetWorld()->SetGamMode(url) to change the current GameMode through C++. Being able to change the GameMode at runtime would vastly simplify having to setup hud management, and controls. I’m trying to change from the normal combat based GemeMode to one that has settings for navigating through text menus. My current code for changing the …

[jwatte]

GameMode is generally pretty limited, it’s mainly concerned with player spawning and management of members in networked games. You don’t want to put too much game logic in there in my experience.

In general, deriving to share implementation is cumbersome and fragile. It’s generally much better to decompose the behavior into separate delegated objects. Perhaps you can build Actors that implement various parts of the game, and place appropriately blueprinted actors in the level for the appropriate behavior?

[markcham]

I see. Since this is a single player game I guess there isn’t much to do inside of GameMode.

The individual modes within my game don’t really need to be any specific type and they don’t need to be spawned physically necessarily since I have a separate actor handling spawning. I think making actors would work just fine.

I have a follow up question. If I use actors for my individual modes within my game, would it be a good idea to also handle scoring within these actor classes since some modes are scored differently than others? And then probably store player scores in GameInstance. I know I can probably handle the scoring anywhere, but I’m trying to set up good practices for myself in the future.

Thanks!

[jwatte]

Typically you’ll store player scores in PlayerState. Although GameInstance works, too, at least for single player games.