Introduction

Most of the time, when creating a game as a hobby or in an indie setting, creating the installer and making it available on your website is a last minute decision or an afterthought, once the game is finished and ready for release. It is normal to bundle the game and its assets within a simple zip file, or worse, a "WinRAR" file, requiring the player to possibly install extra third party software to even start to play your game.

Generally, this is acceptable during initial testing, but as the game becomes more popular, or you just want to appeal to a wider audience, wrapping your game in a friendly installer can make the difference between a download or a drive-by visitor.

In this short article we will go into the detail of how to package your game into an installer, correctly sign your game's code, and get it to your website in an automated fashion. I will be using the windows tool "Inno Setup" as it is very user-friendly, completely free to use, simple to set up and can be run from the command line very effectively. There are many other programs out there, some free and some paid, such as NSIS (Nullsoft install system), and WISE Installation Studio. Each of these also has their individual advantages and disadvantages.

I will also be using some free open source tools such as "SCP", and the free Windows 8 SDK tools such as "SignTool".

Advantages of automating your releases

• It's faster - you just run a batch file, walk away and have some coffee.
• There's less margain for error - If it's right the first time, chances are it'll always be right
• It allows you to put out releases more often - If you can do it faster, there's no reason to put off a release until you're not busy, you can leave your PC doing it whilst you continue to code.
• It presents a more professional appearance to your game - Games which are nicely packaged, digitally signed and available quickly are always a plus.

When might I NOT automate my release in this way?

This guide assumes you are self-hosting your game on your own website, with your own resources. If you are hosting your game through steam, desura, or other such service, or if it is not a windows game, many of these steps will likely not apply. For the purposes of this article I will assume that you are self-hosting your own windows game on your own website and not via any form of third party distributor, who might perform a lot of these steps for you.

Prerequisites

Download the required programs

Firstly, you need to download and install the required install file building tools to your hard disk. To do this visit the inno setup download page, then download and install the isetup-5.5.5.exe (or later) package.

Once this is done, you will have the various utilities avaialble for bundling your game into an installer. For this article's example scripts, I will assume you have installed it to its default location, "C:\program Files (x86)\Inno Setup 5". If you are not using this location, please adjust my example paths accordingly for your own needs.

The install script

Inno setup functions much like most install packages in that you must write a simple script to tell its compiler what files belong where within your game. It will then use this to compress the content into a self extracting executable file.

The simple script below will work well for any simple games which do not have external dependencies. This example is taken from my game, please feel free to re-use and adapt it as you wish.

As you can see below, most of the configuration is made up of a set of #define macros at the top of the file which indicate the BuildDir (where to write the completed installer exe which you will upload to your website), the MyAppName to specify the name of the game, and various other meta-data.

Within this is an AppId value which is a GUID (globally unique identifier) which must be unique to every application, game or otherwise, installed within windows. The one I provide here is simply a humorous but valid example - you should change it using a GUID generator to be one unique to each new program you release.

Something else important to note here is the MinVersion directive. Here, I have set this to "0,6.0.6000" which means my program will only install on Windows Vista or later. This may or may not be something you require, and if you do not require it you should comment the line out or remove it.

#define BuildDir "."
#define MyAppName "Firework Factory"
#define MyAppVersion "1.0.1"
#define MyAppPublisher "Brainbox.cc"
#define MyAppURL "http://brainbox.cc/fireworkfactory"
#define MyAppExeName "dx11fireworks.exe"

[Setup]
AppId={{C0CAC01A-DEAD-BEEF-CAFE-E0B1ABEEFC0B}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#MyAppURL}
AppSupportURL={#MyAppURL}
AppUpdatesURL={#MyAppURL}
DefaultDirName={pf}\{#MyAppName}
DefaultGroupName={#MyAppName}
AllowNoIcons=true
OutputBaseFilename=fwf-earlyaccess
Compression=lzma/ultra64
SolidCompression=true
OutputDir={#BuildDir}
InternalCompressLevel=ultra64
SourceDir=..\Release
MinVersion=0,6.0.6000

[Languages]
Name: english; MessagesFile: compiler:Default.isl

[Tasks]
Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons}; Flags: unchecked

[Files]
Source: {#BuildDir}\dx11fireworks.exe; DestDir: {app}; Flags: ignoreversion
Source: {#BuildDir}\fmod.dll; DestDir: {app}; Flags: ignoreversion
Source: {#BuildDir}\Gamedata.fwf; DestDir: {app}; Flags: ignoreversion
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

[Icons]
Name: {group}\{#MyAppName}; Filename: {app}\{#MyAppExeName}
Name: {group}\{cm:ProgramOnTheWeb,{#MyAppName}}; Filename: {#MyAppURL}
Name: {group}\{cm:UninstallProgram,{#MyAppName}}; Filename: {uninstallexe}
Name: {commondesktop}\{#MyAppName}; Filename: {app}\{#MyAppExeName}; Tasks: desktopicon

[Run]
Filename: {app}\{#MyAppExeName}; Description: {cm:LaunchProgram,{#MyAppName}}; Flags: nowait postinstall skipifsilent

Another important value within this file is the SourceDir value which represents a relative path to where to find the files from which to build the installer. In my instance, I package just three files, as shown within the [Files] section of the configuration file:

{#BuildDir}\dx11fireworks.exe
{#BuildDir}\fmod.dll
{#BuildDir}\Gamedata.fwf

There are many optional flags you can include here to package entire directories, check versions on DLLs etc. If you require these values, they are thoroughly documented within the help file for Inno Setup, or in the help website for the program.

Automating the creation of the installer

Once you have written this script, you can easily create a batch file which can then be used within your deployment process to create the installer:

@echo off
@echo Building installer...
"C:\Program Files (x86)\Inno Setup 5\iscc.exe" fireworkfactory.iss

When run, the batch file with this inside will automatically create the executable file you configured, so it is ready to upload to your website.

Further steps you can take

Once you have generated an installer, you can automatically deploy it to your website. This can be done securely with SCP, SFTP, or insecurely with FTP, or by any other means that you wish to automate. Here is an example of what you can put in your batch file to automatically upload the files via SCP:

@echo Uploading installer...
scp -i J:/private.key ../Release/fwf-earlyaccess.exe webuser@www.mysite.com:/home/webuser/mysite.com/downloads/

There are some important gotchas to note here; Firstly, please be aware that this is only as secure as how and where you store your private key file. The private key file can't be password protected unless you either (A) want to enter it every time you run your deployment process, meaning it can't be fully automated, or (B) you want to use some other facility like PuTTY Pageant, which is advisable, but outside of the scope of this tutorial.

Personally, to secure my private key I store it on a USB flash drive which I only insert into the machine when I want to deploy my game to my website. This way, anybody obtaining access to my machine, source repositories, or anywhere else, has no physical access to the private key and so can do nothing. If you take this approach, remember to remove the USB key once you are done!

The subject of private keys and encryption leads me now conveniently on to the last and final thing you can do to your installer to help you get players...

Extra Polish: Signing your installer

As part of the process, before you upload your file to your web server, you might want to cryptographically sign and timestamp your game's installer to add security and reputation to your installer.

This is a rather advanced subject, and it comes at a financial cost, and takes time as you will have to apply to a certificate authority and submit some forms of personal photo ID (or in the case of a business, forms of business identification) and pay some money up front to obtain a code signing certificate.

In my mind this is more than worth it though, as the price of this has come down drastically over the past few years and the advantage to you as a developer is massive.

Many antivirus products, malware filters, and other programs such as smartscreen filter give a weighted advantage to signed executables, simply because if the application is signed, the reputation and popularity of the executable is determined against the signer's reputation instead of on a per-executable basis, as it would have to be for unknown, unsiged code whose author could not be determined reliably.

For this reason I recommend it, if only to cut down on dealing with and responding to emails about false alarms from your player's antivirus apps, and accusations that your game is a virus, which can harm your reputation no matter how baseless.

Once you have your certificate, you should import it into your registry, marking it as 'not exportable'. You should use the PFX file your certificate authority have provided to you, or you can make such a file from your .crt and .key file using openssl if your certificate authority provided this form of file instead.

You can then add this to your batch file, before the portion which uploads it to your website:

@echo Signing installer...
"C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe" sign /d "Firework Factory" /tr http://www.startssl.com/timestamp /a ..\Release\fwf-earlyaccess.exe

Note that this code snippet is very simple. We are telling windows to use the signtool.exe binary which comes with the windows 8 development kit. There will likely be several copies of this executable on your disk and any one of them will do fine for this task.

We specify the "friendly name" of our program using the /d parameter, as shown above, and the /tr parameter specifies a timestamp server. The timestamp server is important for making sure that the signature can still be validated correctly even after it has expired, and you should use the timestamp server provided by your certificate authority within this command.

Specifying the /a parameter to the signtool command simply tells it to use the first valid code signing certificate held within your registry to sign the file.

I store my code signing certificate here as it is generally a secure place to put it, where you don't risk accidentally putting it into your code repository or into your network drives, encrypted or decrypted.

Conclusion

Hopefully, this article will have demonstrated how you can automate your deployment process, and make it more secure at the same time. When you have done this once, you can re-use the scripts you have created from game to game, and will likely need to do much less work each time to fully deploy your games to your website on demand. This should cut down creating a new installer from possibly hours in some complex cases, to mere minutes, and most of that should be waiting for uploads to complete and files to compress.

Article Update Log

2 Apr 2015: Initial release