I’m still getting acquainted with blueprint scripting and especially GameModes, and I was wondering what is the “correct” way to do what I’m trying to make, which is something similar to the Civilization-series. For the click and drag-camera, I made a ControlPawn with a camera attached that handles movement, zooming and some effects. In hindsight, that seems a bit silly, especially as elements keep piling up into something that doesn’t seem to be made for them.
How should I divide the game logic between different classes? I’ve been examining the StrategyGame-demo project, but all the classes are pure C++ and I can’t seem to be able to open them. Where should I store and handle grid data and units? The documentation suggests that GameModeBase should contain server logic which GameMode then reads to do things in the client, however I would want to make sure of everything here before I start building logic.
There really no “correct” way (which i assume you mean only one way) to use class, there only there code inside them which you put your code on top of them, generally you should keep there role but you don’t need to if you think it’s better for your case, it’s matter of your design thought.
GameMode (as well as GameModeBase) should contain main game logic, be like a jurge of the game. GameMode don’t exist in the client at all for security reasons, as users have complete power of there PC including memory manipulation, that why they should be least trusted and gamemode should only be on server (which can also be run on user PC, but we assume that user running server wants a fair match, or be the jurge).
GameModeBase is strip down version of GameMode and GameMode extends from GameModeBase, so GameMode is also GameModeBase. GameModeBase was introduce to reduce the code from original GameMode and let devloper have more low level control and don’t enforce ready code on them which might be useless for there case either way. You can only have one GameMode (in theory) object.
Considering you talk about GameMode and GameModeBase you might be not aware about class tree and how classes actually work, you could watch my old video on that matter:
As for where you should hold grid data, i think in unit actors themselves, they should have position information and be in proper location based of that grid position.