MVP in developing simple text-based game

I am trying to master design patterns and for this reason I am trying to implement (using Python language and asciimatics package) simple text-interface game using a MVP design pattern. While the concept of separating presentation and domain logic is clear to me I have stumbled upon few problems that I'm not really sure how to address. Let me first describe high-level functionallity and flow of the application I intend to write. In the main loop the application should ask user whether he/she wants to play a new game or quit. After selecting new game, the new instance of the game should be created and user should be able to interact with it. The game I want to implement is a simple variant of 2048 but it doesn't matter, as for different game the below questions would be the same. After the game finishes app should again ask whether users wants to quit or start a new game and so on.

What I already know and decisions I made until now I choosed to use MVP in supervising presenter variant. I know I should have a view that displays a game and "knows" when to refresh by using an observer pattern. For this view I should have a presenter which observes events happening in the view (user pressing keys etc.) and acting on the game accordingly. The model is, of course, the game itself - as required in MVP it does not have any knowledge about the view and the presenter, and interacts with them by exposing some set of methods and events that can be observed. Up to this point everything is mostly clear to me.

What I don't know First question arises when we want to add the "main loop". Where should I display the menu? I considered the following options, all of which are somewhat unsatisfying to me:

1. Having the separate view for the main loop. It does not seem right, as we don't have a model from the start, so it seems to me it violates MVP principles in the first place,
2. Using the same view as with game and having the presenter set the view in one of the modes basing on app state (either display menu if there is no game, or game if there is one). This approach however seems to be violating principle of separation of concerns, as our view is now not only tasked with displaying the game but also the menu.
3. Using composite in the views, i.e. have a topl-level view (possibly with some title of the game being displayed) and add its compoments on demand - it will be the view for the menu and the view for the game when it is started. Here we have the same problem as with the first option, as again for neither top-level nor menu view there is a model attached to it.

The second thing is: in which direction should the objects be instantiated? Should I create the view first, and inside of it instantiate its presenter, or the other way around? I know this specific question has been already addressed but I am asking it here in my specific context, as I suppose the answer might depend on the answer to the first question.

The third thing is dependent on the answer to the first question. If I choose to have separate views for new game/quit menu and game itself where to I instantiate them? In the presenter, or should some third-party (main app object?) do it? And should I have different presenters for those views, or manage all of them from the single presenter?

I know that some of my questions may not have a definite answer but I would greatly appreciate if you can share your thoughts and opinions on them.