I already have an idea for a game. I also have a few years of experience with casual programming and game dev, and I know the messy while loop I had until now will not be enough for my next project.
The game I want to make is a top down tile based puzzle game. Some elements are buttons activated by boxes pushed on top of them and doors that open as a response. The player can also use a mechanic to "warp" to a different level, taking things with him to the other level and using these to solve the puzzle that's in there. It's not that simple, but I don't want to over complicate anything. I also have a lot more ideas but lets start with the core of the game.
I already implemented some of the mechanics as a prototype but it's too unorganized and I don't think it is worth coding how I did. For that reason I am thinking about game architecture. Multiple articles I read suggest that I should use a messaging / event system that connects between different systems of the game. Those could be the renderer, sound, game logic, physics, etc...
These systems are very general and I am wondering where are the game objects themselves? Do I have a separate system for the player, another one for the level elements? and one just for GUI? or are they all in one system?
Another aspect of the systems is the communication between one another. If I have a separate system for the player and for the renderer, then how does the renderer know where the player is? Having different systems seems logical at some cases but complete nonsense in others. so to summarize: Which systems are required for the type of box-pushing puzzle game I'm making?