If you have already created your game for iOS or Android (for example) in GameMaker:Studio and now wish to port it over to the Windows Phone platform, there are some things that you should be aware of.
Once that is all taken care of, you can boot up GameMaker:Studio and start to port your game.
The Global Game Settings
The global Game Settings window within GameMaker:Studio has a specific Tab for setting up how your Windows Phone game will look and behave. This tab is split into three “sub-tabs” which are explained below:
The first thing to do on the General tab is to fill in the details of your game, with the following fields available:
Display Name: Specifies the friendly name for the app that is displayed to users (this string is localizable).
Description: This should be a ''short'' descriptive text for your game.
Author: The name of the person (or company) that created the game.
Publisher: The name of the person (or company) that is publishing the game.
Version: The version number of your game.
NOTE: Make sure your details in this tab match what you put in your Marketplace registration for the game when you are submitting to the Windows Store!
After filling in these details, you should then select the Orientation and Supported Resolutions. The orientation section can be used to lock the game to one, some, or all of the available orientations. These are:
On devices that can be rotated, such as tablets, the game won't be redrawn for orientations that aren't specified with this property - for example, the game won't rotate if the device is rotated to a Portrait orientation but the property specifies only Landscape and Landscape-flipped orientations. On devices that can't be rotated, a game might be shown in that device's default orientation, and the game's preferred orientation will be ignored, however, your game's preferred rotation will be honoured on devices on which a rotation lock has been activated. These orientation preference choices apply to both the splash screen and the game itself every time a new instance is launched.
Finally, the resolution section is used to target your game at specific displays. As with the orientation, you can select one or more of these options, but if you select various, you must make sure that your game is scalable in all resolutions. The following table shows the resolutions and ratios supported:
480 * 800
480 * 800
768 * 1280
480 * 800
720 * 1280
480 * 853
This tab is where you can set the Splash Screen which will be shown when the game is loading, as well as assign an icon to identify your game. The Splash Screen must be in JPG format and be the exact sizes given, while the icon can be either PNG or JPG (PNG is recommended).
Here you can also find the option to set the size of the Texture Page. The default (and most compatible) size is 1024x1024, but you can choose from anywhere between 256x256 up to 2048x2048. There is also a button marked Preview which will generate the texture pages for this platform and then open a window so that you can see how they look. This can be very useful if you wish to see how the texture pages are structured and to prevent having texture pages larger (or smaller) than necessary.
NOTE: Be aware that the larger the size of the texture page, the less compatible your game may be.
The Tiles sub-tab is further split into three separate groups, of which you should choose one to represent how the Live Tile that represents your game or app will be shown on the device:
Flip tiles are ones that will change from one "side" to another every few seconds, and here you can add the different images that you wish each "side" to show. Note that the smallest possible tile size does not flip and so you only need to supply one 159x159px image for that, while the other two sizes (medium 336x336px and wide 691x336px) will.
Beneath the images you can also supply two Content strings. These will be shown on the back tile only, with the first string being for the medium size and the second one being for the wide size. Should you wish text on the front of the tile you will need to use the special win8_* tile functions that are part of the GameMaker:Studio programming language GML.
The Iconic tile setting uses two images (small at 110x110px and medium at 202x202px) and a series of different text messages to display information about your game. If the user has reduced the tile size to the smallest or the medium size, then the respective images will be shown only, however when the user has a wide tile size selected, then the image will be displayed as an icon in the lower right of the tile and various lines of text will be displayed starting at the top right of the tile. The image below illustrates this:
The final tile type is the Cyclic one. This permits you to specify a small image (159x159px for the small size) and a series of 9 different wide tile images (691 x 336px) that will be cycled using various different transitions. These images will also be used for the medium tile, only they will be cropped automatically by the Windows Phone OS, so make sure that the images chosen work aon both possible sizes.
One important part of porting your game to the Windows Phone platform is making sure that the game scales correctly to the resolution(s) available. When you upload your game to the store, you can choose which Windows Phone platform to target, with the following table showing the available sizes:
480px by 800px
Windows Phone OS 7.1
Windows Phone 8
768px by 1280px
Windows Phone 8
720px by 1280px
Windows Phone 8
How you prepare your game for these resolution is up to you, and will depend on whether you have a single small game room, or a large number of interconnected ones, or even whether you use views or not. However, in general, if you app has not been coded for these resolutions you will need to use views to scale to them, probably loosing a little on the top and bottom of the image (or the sides, depending on whether your game is landscape or portrait).
NOTE: GameMaker:Studio creates a universal xap and your game should be compatible with all platforms, but that doesn't mean it will look good and work correctly! Make sure to test using the emulator before submitting to the store.
Porting your games with advertising over to the Windows Phone target is an incredibly simple task, with the main difficulty coming from the fact that you will need to sign up for the Microsoft PubCenter and register your app before they will work.
We have a complete article that takes you through this process (here) and once you have it set up you can then use the same functions within your code that you would use for any other platform and they will be shown correctly.
Be aware that if you porting from a target resolution different to that of any of the Windows Phone targets, then ads may be positioned differently, due to them being based on the absolute GUI size, and not on the relative view size.
How you deal with this will depend on the game you are porting, but it's a good idea to always use the available functions for getting the current display size, rather than rely on the absolute coordinates that you may have been testing with, or have found to work on other platforms. An example of a good technique would be the following code:
var ads_x = display_get_gui_width() - (ads_get_display_width(0) / 2);
var ads_y = display_get_gui_height() - ads_get_display_width(0);
ads_enable(ads_x, ads_y, 0);
This code will get the relative display coordinates of the device and place the advert at the bottom of the screen and centered. Note that there are no “magic numbers” here! The functions used will ensure that your ad is always correctly positioned. The only thing you should be aware of is the maximum width and height of the ad to be received (defined by you in the Global Game Settings for your ad provider) and plan the layout of your game screens accordingly.
As with the Ads functions, any In App Purchases functions that you have in your game, should also automatically work with the Windows Phone target module. However, note that you must have switched on the “sandbox” mode in the appropriate tab of the Global Game Settings if you wish to test you game before submission to the store.
NOTE: You can also do full IAP testing on the Windows Phone Store itself by marking your app as a “beta” when uploading.
The Back Button
It is worth noting that the use of the back-button on Windows Phone devices must be consistent. For example, on Android, the back button can do whatever you want, with some apps permitting multiple presses of it to skip back through menus or even exit the app, while others may use the back button to “toggle” between pages.
However, the Windows Phone target has some very strict rules on how this button should be used, and your app will be rejected if it does not follow them.
For games, when the back button is pressed during gameplay, your game can choose to present a pause menu or a dialog or even navigate the user to a prior menu screen, however pressing the back button again while in a paused menu or dialogue must close the menu or dialogue and return the game to the previous state.
So, if you pause your game and bring up a series of options, pressing the back button again should remove the pause and return the player to the game.
To use the back button in GameMaker:Studio you have to check for a keypress event from the key constant vk_backspace. A practical example of this would be when you have an instance captures the back button within your game to create a message asking the player if they really want to quit. A simple summary of the code would be:
That will capture the back button and create the message object (and you would probably want to pause your game here too). Now, you may have coded this object with two options: one for “Yes” and one for “No”, but you will also want to code it to respond to the back button as well.
Typically, it would be “Yes” to quit to the main menu (ending the current room etc...) and “No” to open a pause menu... but the back button? Well on either iOS or Android you could have it do either of those options, but not on Windows Phone. In this case the back button must return the player to the game itself (destroying the message instance), as that was the state the game was in the first time it was pressed. Think of the back button like a toggle between two different game states.
One last thing to note when porting your game to the Windows Phone target is that you will have access to the windows phone functions in GameMaker:Studio. These specialist functions can be found in the manual and will give you control over the Live Tile for your app, permitting you to change it's Title as well as add or remove text and change it's image.
This is an incredibly versatile system and it's worth taking the time to create interesting and dynamic live tiles for your games so that they take full advantage of this feature - for example, code the live tiles to show the current health and gold of a character, or have it change images based on the achievements received etc...