Jump to content
  • Advertisement
Sign in to follow this  
cephalo

Organizing Game Logic

This topic is 1121 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
Advertisement

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!