wouldn’t it be better to code this puzzle as a self contained actor, which you could place into any level, of any game, and be able to play it, without changing game modes, or loading levels, or unpossessing pawns? it seems like using Unreal framework classes for this puzzle is limiting its modularity, and not adding any benefit to what could otherwise just be a prop, which you could place on any shelf, in any VR game or RPG game, like a light switch or a vehicle.
the way GameModes are tied to the loaded level seems to be designed for arena combat games, like Unreal Tournament, and putting code inside a game mode seems to limit freedom in more open world sandbox scenarios. i think mini games and puzzles should be actors, instead of games, so you can mix multiple mini games in the same level.
if you design all games from the perspective of a sandbox RPG, you really don’t need game modes or game states, you can just put all the game rules inside actors spawned into the world. even in arena combat games, you don’t need capture the flag to be a game mode, you could keep track of points in goal actors or a score board actor or the player state.
i feel like game modes and level blueprints are vestigial remnants of unreal engine 3, and they became obsolete as soon as blueprints were introduced. why tie any logic to a level, when it could be reused by putting that logic in an actor blueprint, which can be placed in any level?
i should be able to play poker, in the same room as someone who is playing a slot machine, while a third person plays roulette. putting any mini game logic into a game mode just gets in the way of that. each poker table can keep track of its own score.
also, all of your buttons could have been the same actor, reusing the same mesh, with its pivot at the center of the sphere, so its easy to rotate to any point on the surface. if 2 actors behave the same, but look different ( or in your case, look identical, but rotated), they should not be separate actor types, they should be instances of the same actor, in different states. or, it could be even more efficient, if those buttons were just static mesh components that get their materials set by the ball actor. then you don’t need to create separate dynamic material instances for every button, and you don’t even need to keep track of their state with booleans: when you want to toggle a button, you can just check which material is applied to the static mesh, and use that to select the other material to apply.
