Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 24, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
The Poor Indie's Update Distribution System
by Scott MacLean on 02/16/13 12:11:00 pm

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Introductions

Since this is my first post, let me briefly introduce myself. I'm Scott, and I run a one-man company called Green-Eyed Games in my spare bedroom. I'm just about to release my first game, "Last Train to Timbuktu!". Gamasutra has been a great resource for me as I first dreamed about, and then actually started Green-Eyed Games, so I hope to be able to contribute back to it in whatever small ways I can.

As a start, I'd like to describe a simple, cheap system I came up with for distributing software updates in the hope that 1) some of you will find it useful, and 2) I'll get some feedback and find out if I'm making a hideous mistake.

Why an update system?

A week or two ago as I was working on Last Train to Timbuktu, I started asking myself some inevitable panic-inducing questions: "what if the game turns out to not be balanced as well as I thought? What if people want more difficulty settings? What if there's a bunch of weird bugs I haven't found?" The modern answer to these questions is to just release free downloadable updates as necessary. This is easy if you're working with an app store - Steam and iPhone games update themselves all the time. But Last Train to Timbuktu is going to be sold from my website through FastSpring (though of course I do plan to get it into as many stores as possible). FastSpring has a lot of features, but unfortunately distributing software updates isn't one of them. So, I wanted a way to distribute updates myself.

I run Green-Eyed Games on a shoestring budget, and I don't mean a nice, waxed shoestring for your dress shoes. More like the dirty old one with knots that you never untie and have been meaning to replace for a year. That kind of shoestring. So there's not a lot of money for things like server infrastructure. There's also only one of me, and I'm only doing this during evenings and weekends until I finish grad school, so I don't have a lot of time either.

No time, no money. Good combination. Oh well - creativity thrives with constraints, they say. I came up with a solution that uses four services:

  • my webhost, which lets me create databases and run arbitrary PHP scripts
  • Amazon S3
  • YourMailingListProvider (any mail service that supports mail-merge would do)
  • FastSpring's purchase notification service (most payment processors seem to have something like this)

How it works

There are three operations in my approach: recording purchases, releasing updates, and notifying customers.

Recording purchases

On FastSpring, I added a custom field to my order form to let people choose whether they want to be notified by email about product updates. On my server, I created a database to track products, customers, purchases, and downloads.

When somebody makes a purchase, FastSpring sends a notification to a PHP script on my server. This script checks whether the purchaser wanted to be notified about updates. If they did, it records their email address and the product they purchased, along with a random string that acts as a purchase key.

Releasing updates

When I release an update, I upload the installer to a private Amazon S3 bucket and create a new "version" of the product in the database. The version consists of the product id, a string identifying the version, and the canonicalized S3 URL.

A second PHP script facilitates downloads. It accepts three GET parameters: the product, the version, and the random purchase key. The script verifies the purchase by looking up the purchase key. It then looks up the product's S3 address, constructs a query-string authenticated URL with a short expiry time, and redirects the customer's browser to the download. After three download attempts for the same product update with a given purchase key, the script stops redirecting and starts displaying an error.

Notifying customers

To notify customers about a product update, I export all the email addresses and purchase keys associated with the product in the database. Then I import that data into a mailing list with a custom field for the purchase key. After writing an email that includes a link to the download script, a mail merge inserts the purchase keys into the download links. Every customer who wanted to hear about the update receives a link with their purchase key and is only one click away from the download.

The good and bad

This system has a lot going for it:

  1. It respects customers' privacy. I only record their email address if they opt in, and I never send their name or payment details over the Internet.
  2. It doesn't slow down my somewhat sensitive shared server if I get a lot of customers. Amazon S3 is about as cheap as it gets, and all my server does is check a database and redirect customers to the download.
  3. It makes security simple. Instead of using S3, you could redirect customers to a file stored on your web server. But then you would either need to authenticate customers or leave the file globally readable. In my method, the random string is basically a disposable key granting access to a resource protected by Amazon's security features.
  4. It is easy and non-invasive for customers. They don't have to type in license keys or verify their identity, they just click a link in their email.

Of course, it isn't perfect. In particular, it doesn't handle returns or refunds. This is because FastSpring's notification system doesn't distinguish between full and partial refunds, and it bundles multiple returns into a single notification. I don't expect returns to be common enough to warrant writing more complicated code to figure out whether to remove purchases from the database. I'll just do it manually as necessary.

Well, there it is!

So, that's at least one poor indie's update distribution system. If there's any interest in this, I'd be happy to put my PHP scripts up on GitHub with more detailed documentation. For those of you with experience in such things, does this seem like a reasonable system to use? Is there a better, more standard way of distributing updates that I've overlooked?


Related Jobs

Activision Publishing
Activision Publishing — Santa Monica, California, United States
[10.24.14]

Tools Programmer-Central Team
Bluepoint Games, Inc.
Bluepoint Games, Inc. — Austin, Texas, United States
[10.23.14]

Senior Graphics (or Generalist) Engineer
Intel
Intel — Folsom, California, United States
[10.23.14]

Senior Graphics Software Engineer
Wargaming.net
Wargaming.net — Hunt Valley, Maryland, United States
[10.23.14]

Graphics Software Engineer






Comments


Lex Allen
profile image
I've found that retrieving data from Amazon is painfully slow, but is it just me?

Scott MacLean
profile image
Thanks for the tip. I haven't experienced that myself. I wonder if it's related to your location vs. the region the data is stored in, or whether the data is stored in a slower service tier.


none
 
Comment: