How to organize the structure of the game?

Question

Game development

Game type - realtime strategy
There was a problem of organizing the game code, I want to write correctly right away, but I don’t know how, maybe there are some patterns?
The game has game screens, with Update and Render functions that run indefinitely. Also in the game there are game objects such as maps, units and buildings. The question is how to manage all this?
I have two code structure options.
1) Game screen controls objects directly. But I highly doubt it.
2) The game screen controls objects indirectly, through a special class, such as Engine. That is, the Screen controls the Engine, and the Engine controls the objects. But even in this version, I strongly doubt it, it painfully resembles the film "Inception", also here, class in class in the third grade.
Perhaps you have your own options? Please do not advise literature, I have already read a couple of books on this issue, I just need to urgently know the answer.

Answer 1

1. There is no single correct answer.
2. No one has ever written anything correctly right away, no need to hope and / or worry. If the project is educational, then just write.
3. If the “screen” is what is responsible for rendering the game, then it definitely should not control the logic.
4. If you have problems with determining how to manage a set of objects, the easiest way is to introduce an additional abstraction (like your option 2), just call it not Engine (too general), but, for example, UnitsManager - send all commands related to units, but he's already inside let him figure it out. This will allow you to divide all the logic into two independent parts (one does everything with units, the other does nothing with them), which will simplify the perception of the architecture.
This is, of course, approximately.

Answer 2

I can be wrong, because. In general, at the moment I am experimenting in the same direction.
For myself, I implemented it approximately as follows:
1) GUI - apparently what you understood by "screens". Graphical interface with rendering and entry points for user actions (KeyListener and others). There is no logic here, only the appropriate rendering.
2) Engine, roughly speaking - "engine": all game logic is contained here. Maps, units, items, states and more. All interactions between objects and class instances are described here.
3) Directly Game - a direct "thread", included on the launch of the application, which determines the interaction between the GUI and the Engine. Here, the launch of the Engine and GUI is initialized, and then, as information is received from the engine and / or "screens", the interaction is processed as needed.
But, as I said, I do not pretend to the correctness of such a division.

Answer 3

gameprogrammingpatterns.com
https://drive.google.com/open?id=0B4Mt9VV3phXydHZ2...
https://drive.google.com/open?id=0B4Mt9VV3phXyTnJr...