I would divide states into two categories: application states and game states. Application states would have access only to the “core” subsystems, like window subsystem, sound subsystem, etc. Game would be one of these application states, however this state would also have its “substates” - game states. Game states would be initialised with a pointer to a Game/GameWorld/GameLevel/etc. Object.
That's one option. You could also use the Model-View-Controller pattern. When you look at a map you're just changing the way the world is shown to the user. Model would be the shared game data and game logic. View would be responsible only for rendering correct stuff on the screen. Controller would be responsible for reading input and deciding which View to activate.