Social Games Are a Constant Deployment Environment
There’s an old saying that goes something like this: Hidden inside of every blessing is a curse.
And the greatest blessing of Social Game to developers is this: You can deploy any revisions to your game to 100% of your audience at any time.
It’s an incredible amount of freedom compared to how things used to work, and it’s a switch that separates social games from almost every form of game development that’s come before it.
When you compare it to way things used to be, the repercussions are fairly staggering. It wasn’t that long ago that you were shipping into the retail void, crossing your fingers that your audience would find you, and praying that you’d get some good reviews and word of mouth.
And then, if your game sold, you were stuck trying to find a way to deploy new versions to deal with bugs or play issues, with every minor change demanding a major new release before you moved all your resources into creating a sequel that would both fix all the issues with the previous produce, while creating a whole host of new ones.
But with social games that all goes away. You’re releasing constantly, and with every new version you can be absolutely sure that 100% your users are working on the same version of the software. You can even release a games “sequel” simply as another update.
For developers who are coming from the web side this may seem like business as usual, but for those of us coming from “traditional” game development this is a fundamental shift. And at first it seems like a dream come true, but there also isn’t a developer I’m speaking with who doesn’t have a list of fixes, updates, and features that’s far, far out ahead of the actual production time that they have to do the work in.
That means what we used to call “planning” now becomes “prioritizing”. Not only are internal pressures like infrastructure, monetization, and virality fighting for resources, but your audience is well aware that if they’re squeaky enough they’ll get the grease they’re looking for. In the constant deployment environment there is no “gold master”, and the only time your game is complete is when there’s no one playing it anymore.
It also means that everyone is working at a breakneck pace. Rather than shipping a game and taking a deep breath, your work has only just begun.
But one thing does remain similar to the old school development philosophy—building and relying on your underlying practices and structures is the best way to optimize your development strategy. Is your asset pipeline strong? Do you have a good set of processes for determining both the priority of work to be done and a way to quickly and effectively analyze the results?
And just like the old days, it’s easy to ignore the long-term value of building best-practices for the short term value of getting stuff out there as soon as possible.
Andrew Mayer is a Social Gaming and User Experience Consultant with over seventeen years of experience in the games industry.














June 8th, 2009 at 11:12 am
[...] My latest and greatest column is up over on ISG. [...]
June 8th, 2009 at 5:29 pm
That’s not really anything to do with social games particularly though, it’s worth pointing out. MUDs, Flash games, browser games, etc all work that way.
June 9th, 2009 at 3:54 am
Great post.
This is a lesson that I find, as an old school games industry person, that I am having to learn again and again, and it is hard. The terror is always with games that if you don’t do enough initial work that you will sink without trace, which is true in the retail environment. I keep forgetting and then re-remembering that social games are the furthest thing from retail that is possible.
Ship It!