This is going to be more of a high-level post. But it’s important, especially for my fellow XBLIG developers who are now targeting WP7, since it highlights some things you need to really think about before writing your game (or while porting it).
In order to provide a great user experience, all programs (games and apps alike) must display their first screen within 5 seconds of launch and must accept user input within 20 seconds of launch. (See: Windows Phone 7 Application Certification Requirements (PDF)). The recommended practice to meet the 5 second mark is to include a file in your game (in the game project itself, not your content project) that draws right on startup. In Silverlight, this can be done by adding an image called SplashScreenImage.jpg (yes, a JPG) which should be 480×800. Unfortunately, this doesn’t work in XNA games. Recommended solutions for XNA games can be found in this thread in the Windows Phone 7 forums. They aren’t quite as easy as just adding an image but they aren’t all that hard either.
Then there’s the 20 second input mark. If you’re frontloading using your main game class’s LoadContent method (or the threading based solution for drawing a splash screen given in the link above) to load all your content you could wind up accidentally blasting by this. It’s one of the reasons I like the GameStateManagement sample – you only load content where needed and as needed such that your main menu should easily come up in under 20 seconds (and quite possibly in under 5, though you should still implement a splash screen to be safe). Regardless of where you load content, though, your game cannot appear to “hang” or prevent the user from, e.g., taking a phone call. So any non-trivial amount of content loading should be threaded with a loading screen and an input handler that checks for a back button press at a minimum.
Speaking of which, go read the App Cert Reqs about how the Back button should behave in your game. I’ve decided to adopt the “return to menu with option to resume” for my simple puzzle game but will likely be adopting the “in-game pause screen” method for my next, more “action-y” game since that’ll fit the style of that better. Since the player can just decide to leave your game at any point (and can get interrupted by a phone call or can just hit the Start button to bring up their phone’s menu (thereby “tombstoning” your game) in order to go do something or check something, it’s really important to plan out the objects that represent the current state of your game and make them serializable/deserializable so that if the player decides to leave for whatever reason, you can write them out using, e.g., the XmlSerializer class and then (if/when they return) present them with the option of resuming their last game.
Lots of things to consider. They’re all easy enough to handle – but you must know that you need to handle them. So, like Cato with his Carthago delenda est, expect me to regularly include a link to the App Cert Reqs. They’re important in many ways beyond just what I’ve laid out in this post. They also contain all the prohibited content rules, for example. These are more restrictive than the XBLIG rules (and logically so since people don’t lug an Xbox and TV with them to play games while on a commuter train, for example). Short post (for me anyway). Good luck!