Cool I code my game in AS3 and still make it a desktop game! It was great at first until I finally got to the part where I needed to turn my code into a desktop experience. An experience that would look like any other game out there …

Oh it’s very possible and it’s quite easy in fact … once you know how … The problem is that the info I needed was all over the Interweb and it was quite annoying to put the pieces together. So hopefully this post might help others. Note that for now these tips are only about Windows games. Other platforms might come later.

Getting started

Download FlashDevelop and start a new AIR project. Save yourself the trouble of having to configure everything yourself. FlashDevelop will give you all the required files to get started. If you don’t like FlashDevelop you can always switch editor once your project is created.

Writing files

Save games? Settings? Anything? DON’T WRITE IN THE GAME’S DIRECTORY!!! Why? Windows User Account Crontrol … Oh you knew that? Well I didn’t because I’m still on Windows XP and everything was working just fine. First player that tested the game was on Windows 7 and UAC kicked-in creating all kind of problems (as you can’t expect people to run every application as an admin).

The solution is to use AIR applications storage directory. This is basically the “documents and settings/user/applicationdata/ … ” directory in which you can write/delete all you want.

You can access this like that:

var testMe:File = File.applicationStorageDirectory;

testMe = testDirectory.resolvePath(“test.txt”);

Creating the EXE file

What you want to do here is to create a captive runtime bundle. You don’t want players to download an AIR file that will confuse a lot of users so using this technique you’ll get a pretty EXE file. This bundle will include AIR and isolate it from any other AIR installation on the user’s computer. That way you don’t have to fear a bad AIR update that might mess with your game.

So create the package you’ll have to switch to the command line (or create a BAT file) that looks like my command:

adt -package -keystore D:\Dave\SpaceVermin\bat\TalesGalaxy.p12 -storetype pkcs12 -target bundle testexe application.xml -C bin TAG.swf icons/TalesGalaxy16.png icons/TalesGalaxy29.png icons/TalesGalaxy32.png icons/TalesGalaxy36.png icons/TalesGalaxy48.png icons/TalesGalaxy57.png icons/TalesGalaxy72.png icons/TalesGalaxy128.png icons/TalesGalaxy512.png

I execute this command at the root of my project and I have an “icons” folder in the “bin” folder. You have to include icons (not sure you really need all size but better safe than sorry) in this command if you want your EXE illustrated with it. Took me some time to figure this out so don’t forget the icons.

Step by step:

adt -package -keystore D:\Dave\SpaceVermin\bat\TalesGalaxy.p12 -storetype pkcs12

You see here the keystore. Hopefully your FlashDevelop projet will have included everything you need to create the P12 file.

-target bundle

This is where you specify that you want a captive runtime bundle. If you indicate “native” instead of “bundle” than the user will still have to install AIR on top of installing your game and you don’t want that.

testexe

This is just the name of the folder where you want to put the bundle. Type anything you like here.

application.xml

Here you indicate where is the application.xml file of your project. If your application.xml is at the root of your FlashDevelop project then just put its name without anything else like I do.

-C bin TAG.swf

The -C changes directory so here I tell the command to go to the “bin” directory to get the SWF file. Following this you just need to include all the files you want in your package (like icons).

Once you get this to work you’ll get a folder with an EXE file that will execute the SWF that you still have to include in your package.

Fullscreen

AIR can’t change the screen resolution of the computer BUT you can still have your game in fullscreen and get decent results. It might however require some changes in your code to adjust the interface so make sure that everything appearing on the screen is positioned relatively. It will make everything much easier.

To activate fullscreen here’s the code I use (explanation below):

switch (stage.fullScreenWidth / stage.fullScreenHeight)
{
case 5 / 4:
stage.fullScreenSourceRect = new Rectangle(0,0,1024,768);
break;
case 16 / 9:
stage.fullScreenSourceRect = new Rectangle(0,0,1024,576);
break;
case 4 / 3:
stage.fullScreenSourceRect = new Rectangle(0,0,1024,768);
break;
default:
stage.fullScreenSourceRect = new Rectangle(0,0,1024,768);
break;
}
// Catch all weird resolutions
if (stage.fullScreenWidth / stage.fullScreenHeight > 16 / 9)
{
stage.fullScreenSourceRect = new Rectangle(0,0,1024,576);
}
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;

The first thing to know here is that my game “normal” size is 1024×768. I check the screen resolution and use stage.fullScreenSourceRect to make sure the game stays at the size I want it to be. If you just activate fullscreen without that then either your game won’t fill the whole screen (even if it will be fullscreen) or everything will be stretched/cropped and you don’t want that.

So here most of the time my game will appear as 1024×768 while possibily creating some small black borders at the top and bottom. The borders are barely noticeable so in these case I tolerate them. For a 16:9 resolution however I have no choice but change how the game appears a bit.

First thing I do is to change the viewport to a 16:9 resolution small enough to have no performance drop. I went with 1024×576 which is enough for this game. It do means that now I have some stuff that appears outside the screen. Lucky me it’s only some menus. Here I had to do some coding to move stuff around in case the game is run at 16:9. There’s no escaping it and if you did have all your stuff positioned relatively it shouldn’t be much of a problem.

Creating an installer (MSI)

I’m guessing the popular answer here is to use NSIS but me I had no interest to learn how to script for this so I went with a free, easy to use solution: http://www.advancedinstaller.com/

The free version is limited but good enough for my needs. If you’re feeling more adventurous than me then feel free to use NSIS but I wasn’t really in the mood to get into trouble by learning something new so late in the process of releasing my game.

Note that you should also have the Microsoft tool IEXPRESS.EXE installed on your computer that might also be a viable solution.

Auto updater

If you have the paid version of http://www.advancedinstaller.com/auto-updater.html then it’s probably not a problem for you. If you don’t here how I do this.

On my server there is an XML file containing the info for the new update. The file looks like this:

<?xml version=”1.0″ encoding=”utf-8″?>

<update>

<version>BETA 0.9.2</version>

<url>http://www.machine22.com/tag/update/</url>

<updatelist>

<file>TAG.swf</file>

</updatelist>

</update>

This file tells the game which file to download to update the game. Most of the time you’ll only need to update the SWF file but I’ve given myself the possibility to also update the mission files of the game in case these have problems. All I have to do is to add new <file>newfile</file> entries.

You can easily google for code to read XML and download files so I won’t include this here but once again you need to be careful about Windows UAC otherwise users won’t be able to update the game.

When the user tries to update the game I first do a writing test in the game’s directory. If it fails I warn the user to run the game as an administrator to be able to update the game. It’s not great but so far that’s the only way I found to have my auto updater to work.

If there was a way to store the SWF file in the AIR applications storage directory and still have the EXE file to know where it is then it could be a way to avoid annoying users to run the game as an administrator.

If anyone have any clue how I could handle the auto updater please let me know.

Share