Lets imagine that a new user goes to your site and he/she will need to download 100kb of scripts and images, plus the XHTML page. If you have 50.000 requests, you’ll serve a significant quantity of bandwidth. And you may even serve static content to old users if you don’t configure correctly your static content headers.

Step 1 – Decouple the static content from the dynamic content

First you need to prepare your game to be able to get your images/scripts from anywhere. Instead of linking like:

<img src="/Images/Sample.png" />

You need to code your application to link like:

<img src="http://some_host/Images/Sample.png" />

And have the http://some_host easily configurable somewhere. That way you’ll be able to change the location of your static content and make use of content distribution networks. This can be a complex task if you leave it to the end, so you should start as soon as possible using this strategy. Note that this way you may still use your main server URL for static content.

Step 2 – Use a Content Distribution Network

Now that you have a configurable static content location, you have several options to consider. For example, if your game is open source, you may create an account at SourceForge.net and then you’ll have your own web space to use. You could then configure your game to use as a location for static content something like:

http://your_game_name.sourceforge.net

And that’s it! You’d save a lot of bandwidth and server load just by changing some configuration. But having an open source game isn’t always an option. Fortunately, there’s a free content distribution network named Coral CDN that is very easy to use. Imagine that your game is at the http://your_game_name.com url and that you configured your static content location to http://your_game_name.com. To use Coral CDN you’d have just to change the static location to:

http://your_game_name.com.nyud.net

Appending the “.nyud.net” will make Coral to automatically act as a proxy to your content and cache it. For example, you can try it at this site: buildingbrowsergames.com.nyud.net.

There are other CDN solutions out there, some will cost more money and will be better. A great advantage of CDNs is that they have servers all over the world and will sync your data all over them. So, if your server is in England but you have a user from Japan, the CDN will serve the static content from the nearest server, and your user won’t need to fetch content from the other part of the world.

Step 3 – Configure Static Content Headers

So, by now you don’t have to worry about bandwidth, because you’ll have a third party serving it for you. But there’s something more you can do to improve user experience. When a browser requests content it may cache it according to the server configuration. But if you don’t configure the server properly, the browser may ask for the same static file over and over again.

This won’t be costly for you, but for the user experience. If a user makes a request to your game and the browser has everything cached, the request will be almost instantaneous! However, if the browser needs to refresh data, it may ask for the static content again, and that may implicate that your user will have to wait a second and see loading images.

Resources

This article is just an introduction to make you aware of static content problems and how to solve them. To learn more about client side performance, you can study the Yahoo’s Best Practices for Speeding Up Your Web Site. They have a lot of useful tips, and if you use Firefox, you may install YSlow, an extension that will rate your site in terms of client side performance.

Another great tool to use is something like Fiddler, that allows you to see all requests made by the browser, headers, and so on. By using it you’ll see where you can improve.

1. We get a completely ‘fresh’ version of our code – there won’t be any changes or differences between the versions that someone else and I am both using(assuming we checked out the same revision).
2. You should be keeping all of your changes in a repository – which is why after we have made our changes, they’re committed back.

Now, this is all well and good – but how are you deploying your projects?

Typically, I see people deploying their projects by opening up their favorite FTP client, connecting to their server, and uploading the files – and then afterwards, testing their changes to make sure they didn’t break anything. However, one of the other advantages of keeping things under source control is that you can check out your code from anywhere, as long as you have configured it properly. What this means is that you can also use source control to deploy your projects, making it much easier to keep track of which version of the game is currently deployed(and also do updates as necessary).

To begin with, you will need to have your source control repositories hosted at a location which you can access from your server – I prefer hosted source control, and typically use either Unfuddle or Beanstalk. Beanstalk is prettier, but Unfuddle gives you an infinite number of repositories for free(while Beanstalk will only give you one before you have to pay).

After setting up your repository and importing your project, you can do source control-based deploys by logging into your server and checking out a copy of your code(Subversion command shown):

svn co svn://your-repo-name.repohost.com /www/yoursite.com/game

Once that command has been issued(and any required authentication has been done), you should have a brand new, fresh copy of all of your game’s code sitting on your server.

Now, thus far you may have been reading along and thinking “this is cool and all, but why would I ever need this? Deploying by FTP works fine for me.”. And, to be fair, if you prefer to deploy by FTP you can do that. But deploying from source control becomes useful after the initial deploy, for two big reasons(and one smaller one):

1. You can see exactly which version of your codebase you are currently running.
2. As long as you’re strict enough about it, the code running on your server will be exactly the same as any code you have access to; so if something goes wrong with the currently deployed version, you can retrieve the exact same code, and then sort the problem out.
3. Updating your game requires less bandwidth – as only the files that have changed will be downloaded to your server.

How do you figure out which version of your code is currently checked out? Just go to a directory with the checked out code inside, and run this command:

svn info

Once you’ve done that, you should see a bunch of information about the version of your code that you are running the command on:

Path: .
URL: svn://your-repo-name.repohost.com/trunk
Repository Root: svn://your-repo-name.repohost.com
Repository UUID: 28cb6aaa-c762-4a6a-b8a9-6d82464dce74
Revision: 252
Node Kind: directory
Schedule: normal
Last Changed Author: Luke
Last Changed Rev: 249
Last Changed Date: 2008-11-20 14:08:31 -0700 (Thu, 20 Nov 2008)

And if you’d like to see the commit message for the revision that is currently checked out:

svn log --limit 1

You can change the value that you pass to limit(or remove it entirely) if you’d like to see more log messages.

However, as cool as all of this is, it doesn’t really get us to the nicest part of deploying this way: the ability to update and roll back files easily and instantaneously.

Let’s say that you’ve been updating little bits and pieces of your game, and you’ve noticed that combat.php has a bug in it that is currently preventing users from picking up items. Now, if you were using FTP to deploy your game, you would need to make the fix, upload the new file, and hope for the best. But what would happens if by fixing that bug, you introduce a new one that breaks things even more? If you’ve only been using FTP to deploy your game, there is no way to roll back. But if you’ve been using source control, rolling back to a previous version is easy:

svn up combat.php -r 26

Now, assuming that revision 26 had a working combat.php, your version of combat.php would revert back to the old, working version – giving you time to fix the bug. After you had fixed the bug, you’d be able to easily bring combat.php back up to date:

svn up combat.php

As you can see, deploying your game using source control gives you a lot more flexibility when it comes to rolling out updates to your game – you can use files from different revisions, keep track of which version of your game is deployed, and easily roll back to a previous version(or deploy a fixed version) if something goes wrong – without having to worry about accidentally over-writing anything.

Deploying with source control also makes it easy for you to keep multiple versions of your game available: for example, if you wanted to have a testing ground for new features, the version of the game that was currently playable by your users, and an older, legacy version – all you would need to do is check out different revisions of your code in each of the directories you were planning to put those versions in.

As you can see, source control is an extremely useful tool, even if you aren’t using it for collaboration – and when you have more than one developer, having source control in place is virtually the only way to collaborate with them effectively.