Sign in to follow this  

Organizing Game Logic

This topic is 817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites

Read the basics about 'Classes'

 

You dont have to rediculously overengineer into too many classes, but there should be obvious dividing lines between different parts of your game where organizing them has some utility.     Terrain/props/units/AI/interfaces/logging/network(if)/rendering/game-loop

 

You may find that your game logic will dwarf what you have so far  (you will want to reorganize first to limit rework later)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 smile.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

This topic is 817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this