So, I have a lot of the technical stuff in my game finished, such as graphics and pathfinding and it's all completely separated from the game itself. I am now starting to develop the game logic. Up until now, all of my game logic has been in a single class dealing mainly with game map generation. Now that I'm ready to experiment with actual game rules, AI and units moving around, I'm afraid my 'GameLogic' class is just going to become huge and unmanageable.

Is there any conventional wisdom regarding the division of labor at this stage that I should be aware of? I know I don't want a giant, confusing lump of code, but my predictions for what would make things cleaner often don't pan out.

If I couldn't porsue a scripiting system I would definately implement the game logic in a game state and switch between game states. In this sense, the game logic data would live inside a specific game state. By the other hand, persistent data would obviously live inside the game class.

In the most basic form, the engine would manage the graphics, and low level stuff, and the game itself other things such physics, AI, monetization, etc.

You should learn about OOP and code design,

There are many ways to seperate your game logic from your map generation, for example a simple class which includes both of them and gives "points" instead of the entire map class, the point of it is having an object which would seperate both of them.

You should start by seperating your huge map generation class into smaller classes,

smallar tasks are much easier to develop, test and produce.

Once you've done that you can see how your smaller tasks can integrate with your logic,

maybe some stage is relevant to one state of the game but not the other? It is up to you to think about that.

Good luck

Thanks for the replies. I'm fairly decent at OOP, but for most of my programming life I've always dealt with graphics and system oriented stuff. I haven't done much actual 'this is what the game part of the game needs to do' programming.

Game states are something I forgot about. Really, map generation happens in it's own game state. Separating the states into different classes is a great start. There will be subdivisions of labor beyond that, but those will probably be somewhat fluid. When you're in uncharted territory, sometimes things that seem separate end up being intricately related, and things that seem related end up needing to be forcibly separated.