If I'm not mistaken, you basically ask how to divide the game into the Model-View-Controller paradigm.
Simply put, a model is the state of your game. In terms of OO, you can think of Models as objects in your game.
A controller is a set of rules that apply to your game state (in this case, all game objects) in each update cycle. This can be implemented as a method called update () in all of your objects, or it can be a function called in your game loop that systematically goes through all the objects that need updating and, well, updates them. You can also think of the controller as the game loop itself. It calls everything for updating, and then draws it on the screen and repeats, if any conditions are not met, then it tells the program to do something else. So you almost have two nested MVC structures. One controls the flow of the program through the menu, etc., and the other is dedicated to the game itself.
Preview is just a graphical representation of your game. It may be as simple as the text on the screen, but in your case it is 2D graphics. To implement this, you can have every object that also contains its graphical state, either directly or by encapsulation. A view would do a little more than query all the objects for their graphical state, and then shunt it onto the screen. Again, this can be implemented on the basis of each object, for example, the draw () method or another systematic function that must be called directly from the game loop. It is common practice to create an object called "Sptite" or something similar to store graphic information, and each drawn object in the game has a personal copy. Also note that the View does not have to be an object for itself. One function called in the game loop will be enough, although sometimes it is necessary to store information that directly affects the viewing operation (for example, window size), in which case the presentation may be an object. The same goes for the controller.
Also keep in mind that these units can be further separated to make life easier. For example: The controller can be divided into AI processing, motion updates, and collision checking. The view can be divided into the display of the game object and HUD, and the model can be all objects + the entire state independent of game objects (for example, game settings for resolution, window size, key configuration, etc.).
I know this may be a little redundant, and probably has more information, but I hope it answers your question and gives you ideas on where to start.