This guest article is fromÂ Tim Stoddard, a Windows Games Ambassador currently studying at Staffordshire University.
Spending months or years working on your game can be stressful enough, without having to fix bugs, making sure the graphics/audio play correctly and working up to deadlines. However, when submitting to any platform, there is one process that can be made even more stressful if everything doesn’t go well; the submission process. Once the game passes, everything is great. You can publish the game when the time is right and any issues that arise can be resolved with updates, but the first time publishing a game can be a nightmare.
This was the case for me after my HTML5 game, BOOM: Fireworks Defence Unit, was ported to Windows Phone 8 and released back in June. While the process of porting my game was made almost seamless with the thanks of Construct2 and Henry Hoffmanâ€™s Windows Phone plugin, the submission process was almost agonising due to this message:
I believe every developer has received a message like this when they have submitted to any sort of marketplace. While on some occasions this can be due to a fault with the compiled build of a game, sometimes it’s because of little things that have been missed out in the submission form or in the game itself, which makes the errors more irritating because youâ€™d have to wait for up to a week to see if the game gets certified again.
BOOM: Fireworks Defence Unit was a really bad case for me, as it was my first Windows Phone game submission, and the process was surprisingly different to the Windows Store submission process.
Therefore, Iâ€™d like to share the things that caused my game to be rejected, as well as what I would recommend all game developers check before they make the same mistakes as me.
1. Market Distribution
While this may sound like something where you’d simply check the top option and ignore the rest, this isn’t something to overlook. Depending on the content of your game, you may not be allowed to have it published because it doesn’t meet the requirements of certain countries. It is also a good opportunity to check what price tier you want to set the game at for individual countries.
2. Age Rating Certificates
As mentioned earlier, you may not be allowed to certify your game if it doesn’t meet requirements of certain countries; this includes age rating certificates. While games that do not contain certain levels of violence, sexual content and particular references do not need to be age rated, Iâ€™d recommend you submit them even if the game is perfectly suitable for all ages. Itâ€™s professional, specifically targets your market groups and prevents your app from being possibly rejected because one country required a rating certificate that you haven’t provided.
The next question is: where do I get an age rating certificate, and which one should I get? The latter depends on what country you want to play your game. The United Kingdom, as well as most countries in Europe with particular exception to Germany, use the PEGI. United States of America and Canada use the ESRB rating system. It’s best to obtain certificates from these two ratings boards, not just because of the market size, but also because they both provide free online tools to create certificates from!
Brazil also approves both these tools for their age rating system, so feel free to submit your ESRB or PEGI form in the DJCTQ field.
Some other countries have their own ratings system, which require a more lengthy approval process, such as USK for Germany and CERO for Japan. Whether or not you want to market to these other countries is up to you, but if you want to, go and find which ratings board they use and how you can submit your game.
3. The Back Button
This was one issue that I never realised until it was listed as one of the functional errors in the app submission report. The function of the back button is to close the app, or take it back to the main menu. One of my builds had the back button simply exit the game, and it was rejected.
Therefore when building your game, make sure your back button does the following:
- If in Gameplay (Not Paused) â€“ Pause Gameplay
- If in Gameplay (Paused) â€“ Go to Main Menu
- If not in Main Menu â€“ Go to Main Menu
- If in Main Menu â€“ Exit Game
If you follow these correctly, you shouldn’t get any problems with regarding the back button. If your game isn’t built to follow this structure for any reason, make sure your game is clear about what the back button does.
4. Non-Game Functions (i.e. Web Browser)
While this follows the Back Button, it’s worth making sure that whatever non-game functionality is used, whether it is the web browser, geolocation or even Twitter or Facebook functionality, doesn’t force your game to close when leave it temporarily, and remains functional when you go back to it. An example of this in BOOM is when you press the Facebook, Twitter or WordPress Button to go into the Web Browser, and pressing back goes straight back into the game.
5. The Manifest Files
This one is rather important because it can be missed even by the Microsoftâ€™s App Approval team. The manifest file provides information regarding an apps name, icons, version type and other details that both an app and the Store use. While your app can be rejected for using generic icons or having a generic name, there was a time BOOM was approved and published, but appeared in the store as â€śWindowsPhonePluginforConstruct2â€ť. This is the reason why you should check the manifest file, particularly the title, author and descriptions of your game, so you can avoid having to wait one week for the game to update.
These were the biggest issues I had when I submitted BOOM: Fireworks Defence Unit. Everyone will have a few frustrations over submission processes, but hopefully my advice will avoid some of the big ones.