Proper way to handle logic in a game?

[Jumbajumby]

My question is: What would be the proper way to handle logic in a video game? Here is an example of how ive been doing it:

 
int handle_logic(){
          if(gamemode == in_game){
                         character.handle_logic();
                         enemy.handle_logic();
          }
          else if(gamemode == pause_screen){
                         pause_screen.handle_input();
          }
          return 0;
}

int main(){
           while(program_quit == false){
                         handle_logic();
                         //any other items in game loop like input and rendering
           }
         return 0;
}

The problem with this is once the game got much bigger, wouldnt this way of handling get really complicated with all the

if(gamemode == /*whatever gamemode*/){
                       //do whatever
}

I tried making a general class for handling logic by passing functions to it and storing them in lists. But then i came upon the problem of say... when an enemy gets killed: i wouldnt have much of a way of tracking which logic function to remove. Overall this system of handling logic seemed really pointless as if there were a better way to do it. So... is there a better way to do it? or should i just go with my first example?

(if i put this in the wrong section then im sorry, i had a hard time deciding whether im a begginer or not)

[ModShop]

I like to think of it as a tree of sorts, with a function/class representing each mode. main() would call the top menu, which would call the user chosen mode's function/class and so on. The "proper" way to do it depends on the game itself.

[Athar]

Yeah, a huge "handle_logic" function is rarely a good way. Logic should be handled by the objects it concerns, which can be achieved by using an event-driven and object-oriented approach. Key presses and other events are sent to the currently active objects (mouse events might be restricted to the object the mouse pointer touches and keyboard events to the object that has the focus), who can handle them as they see fit.

The menu screen would be an object and handle all events that apply to it - it could also contain more objects (buttons etc.). When you start a game, the menu screen can be destroyed (or hidden) and the game screen is created, which handles in-game events. There can also be timer events (sent in periodic intervals on request) or tick events (sent every logic tick) to allow objects to act without user input (enemies, for example).

[Jumbajumby]

@athar
oh so you mean like... to have a a handle_logic function like so?

if(game_mode == in_game){
                      game_screen.handle_logic();
}
else if(game_mode == pause){
                      pause_screen.handle_logic();
}

and in the game_screen one have stuff like "handle_character_logic();".... I think i get it now.
Would it be better to do something like this?

int game_screen::handle_logic(){
           for(int enemy_number = 0; enemy_number<enemy_storage.size(); enemy_number++){
                                                   // enemy_storage is my vector for storing enemies
                                                   enemy_storage[enemy_number].handle_logic();
                                                   }
                             return 0;
                    }

or, have it like this:

int handle_enemy_logic(){
 for(int enemy_number = 0; enemy_number<enemy_storage.size(); enemy_number++){
                                                   enemy_storage[enemy_number].handle_logic();
                                                   }
                             return 0;
}

int game_screen::handle_logic(){
                              handle_enemy_logic();
return 0;
}

the second one i would think would be far less cluttered if the project got big. Is that near what you were saying, or did i miss the point completely?

[Athar]

Not exactly (meaning your first code snippet, the other two can make sense if you don't want enemies and stored objects to be part of the normal event loop). The event dispatching should be mostly automatic, the most simple form looking approximately like this:

foreach(event,pendingEvents)
    foreach(obj,objects)
        obj->handleEvent(event);

Each object only handles the events it cares for and ignores the others (alternatively: it must register itself as a listener for a specific event type before it receives any event notifications).

If it makes sense in your project, handleEvent can then pass the events to virtual functions à la onKeyDown etc., which you then override in derived classes. With the introduction of std::function and lambda functions in C++11, function pointers have become a viable alternative to inheritance.

Generally speaking, what you want here is an application of the observer pattern. Searching for that keyword should return a lot of hits.

Edit: on second thought, if it's just a small project, maybe you don't need a full widget and event system.
As long as the various parts of your logic are kept in separate functions, this should already help a great deal in achieving a clear code structure.

[Jumbajumby]

Ok thanks, i'll search up observer pattern right now. I think i tried something similar to what your saying, but i was being an idiot and made some stupid design mistakes that made me have to go through a round-about way to do it, which i thought was too complicated so i abandoned the theory.

Edit: mmk well, thanks for the info. For now ill keep it simple, although ill bookmark an observer pattern page i found for later when i find that my code is getting far too cluttered. Although this wasnt a complete waste, it made me think about a few ways that i can keep my code a bit cleaner. Overall, thanks for the help :)