I helped beta test the exporter so I thought I'd pass on some (hopefully) useful info which I learned during the process. I haven't tried using the exporter for Windows Phone yet, so for now this just covers the Xbox side of things. Some of this might be covered in the documentation, but I'll share it anyway.
First off, you'll be creating games for Xbox Live Indie Games, or XBLIG: http://marketplace.xbox.com/en-GB/Games/XboxIndieGames
The main difference between these and something like the iOS app store is that with XBLIG, your game is peer reviewed by the community before it can appear on the store.
There's some good things about this process; you'll often get useful feedback by people who have not only played your game, but make them. As a member you can also review games yourself. If you have a game waiting to be reviewed by others, you can often offer to review other people's games in exchange for them to review yours. This speeds along the review process, which is completely dependent on how quickly people decide to review your game. Expect it to take from 1 week to 1 month.
You can also submit your game to the community for play testing, which I've found really useful. Once you submit your game, it will automatically create a forum post for people with a developer account to comment on your game.
These checklists are a good place to start when you work with the XNA exporter to make sure your game will pass the requirements. They are what your peers will use to review your game.
This is the so called 'evil checklist'. Basically, if your game fails anything on here, it will fail- meaning you'll have to correct it and resubmit the game. So before you submit anything for review, test it against this yourself.
This is the 'not so evil checklist'. Think of them as guidelines. Things on here won't fail your game, but they are recommended.
I'll cover some things that you probably won't have encountered with before working with MMF.
Safe Area: Because everyone's tv is different, you must avoid putting important elements of your game too close to the edge of the visible screen. This usually affects the UI & HUD the most. Leave a gap between the edges of the screen and where your HUD begins. This is important because some tvs cut off portions of the screen.
Trial Mode: With XBLIG, trial modes are built into the game. All XBLIG have a trial mode, which people can download for free- then if they decide to get the full version, the game will switch to normal mode. You can access this flag with the XNA object. So you'll want to check for the trial mode and then limit the content accordingly. You can also call up the purchase interface with the gamer services object- so you can make a 'buy' button.
Control: You have to make your game respond to all controllers when the player first starts it. So just testing controller 1 is not enough. Most people include a start screen with a 'press start' type instruction. Then whichever controller presses start- the game will assign control to that controller. You'll have to code this into your games too.
The player index and the index you use to test the controllers are not the same. The player index is 1-4 as you might expect- this refers to the possible slots of the players. But because you can test more than 1 controller at once, the system to test buttons is a bit different. For this you use a 1-15 system. I've noted all the possible combinations here- the value on the left is the 1-15 index, the other numbers are the numbers of the controllers.
With this, you can test all possible combination of controllers. So for example if you had a 2 player game, you would probably want the menu to be able to controlled by both the controllers assigned to the 2 players playing. So you would have a selection screen which gathered the info on the controllers first. Then you could store this as a 1-15 value using a global value. So if controllers 1 & 3 were the ones being used to play, you would store the value 5. Then use this global value to test against with the controller object for the controls in your menu.1: 1
Save Data: If your game uses an ini or other data saving object, you need the player to be signed in to access it. If the player is not signed in and the ini is called, visual studio will present you with an error. So you need to test if a player is signed in before accessing or writing to an ini. To test if a specific player is signed in, you can use 'compare two values' then compare
Where 1 is the player index. So comparing the length of the player's alias- if it's above 0 then they're signed in. At the moment I think this is the only way to see if a specific player is signed in, but correct me if I'm wrong.Len( Alias$( "Gamer Services", 1) )
Things do get more complicated with more than 1 player, as you have to code which player's save data to use by setting the 'system player' in the XNA object. Hopefully this gives you a good enough overview to understand the process behind it though.
So hopefully this is useful. I'm gonna go make some games now