In addition to what Trinitia has already said, I like to think of the main sections of my game (say, an RPG) as a 'state machine'. That's just a funky word for me having one big loop that basically says:
#constant Intro 1
#constant Menu 2
#constant LoadLevel 3
If gamestate = Intro
'do intro stuff
else if gamestate = Menu
'do menu stuff
else if gamestate = LoadLevel
'load all the level media etc
endif
endif
endif
(I'd actually use select/case for this, but if/thens are more basic in DBPro). Basically, the game keeps a single number 'gamestate' and that number remembers what state it's in at any one time. Parts of those 'do stuff sections would jump between states - for example, when it's loaded all the level, it would change the gamestate to 'StartLevel' or similar. Or when the player selects 'New Game' in the menu gamestate, it would take note of the level and change the gamestate to LoadLevel.
Loading media between levels really depends on how long you want the player to wait. Deleting models has traditionally been very slow, but I think there may have been some work-arounds put into the latest version of DBPro to make it a little faster. Loading media is also quite slow, so you'd want to make your media as fast as possible to load - using DBO's instead of .X, or .X instead of .3DS.
If you're changing the actual way you move from one level to the next, then you're going to have to have a 'state' for each control method, and then have gamestates like "DrivingLevel" or "FPSLevel". If you're just adding in extra features like a rocketpack to a standard FPS movement, then you can just do an 'if' in the standard "PlayLevel" state to check if they have a rocketpack or not, and deal with the controls accordingly.
Well, I've waffled too much - hope I've been of some help.