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.

Now, you may be wondering exactly why I made the switch – and it’s a fair question to ask. Previously, I was running Building Browsergames off of a single Linux server, affectionately referred to as “Max”.

While dedicated hosting allows you to find everything you need in a webhost, it also introduces a few things that you need to worry about – namely, supporting your hardware. If a hard-drive fails, or a system goes down and won’t come back up, or your website gets slashdotted/dugg and your server starts to melt, that’s your webhost’s problem – except for when you’re running your own dedicated server. In that situation, anything that goes wrong with your system is your responsibility.

I’m not ready for that responsibility. I have better things to do with my time than work out optimal RAID configurations to make sure there is 0 downtime in the event of a drive failure. But at the same time, I like the flexibility that’s afforded to me by running a dedicated server – if I ever need something non-standard, or I want to install a piece of software, I don’t need to ask anyone – I simply log in to my server, and install the software. Piece of cake.

Slicehost provides the best of both worlds; I get the reliability of having a company managing my server so that I don’t need to worry about drive failures or server meltdowns or anything, but I also get the freedom of having a dedicated system – only virtualized.

The ‘virtualized’ part is a pretty big deal. It means that from Slicehost’s handy web interface, I can do a lot of mundane(but still useful) things – things like backing up my slice(their word for ’server’), rebooting it, dynamically scaling it up or down, and even giving it a handy name to remember it by(my slice is named ‘Max’, just like the server it’s replacing).

There are lots of neat (and handy) things that you can do with Slicehost – but one of the biggest ones is that you can dynamically scale your slices.

What does that mean? For a developer who’s building a game on the cheap, it means Great Things. You can start your game with their basic slice, for $20/month – and run as many websites as you want to off of that single slice. You can even have a single slice for a single website, if you want to. At least to begin with, the starter slice will probably be more than enough for a fledgling browsergame – and with the ability to size it up as you need to, it’s the perfect way to expand without any of the hassle of re-configuring servers.

Want to know about some other cool features? With all but Slicehost’s biggest slice size, you can get a backups plan – for a little bit extra every month, you can keep 3 exact images of your slice. You get one daily backup, one weekly backup, and the ability to create ’snapshots’ of your slice – essentially allowing you to roll-back to any time that you want to(I took one just after I finished the server migration, as an insurance policy in case anything went wrong afterwards).

You can also dynamically add slices to your slicehost account – although each slice does have a monthly cost associated with it. And if you’ve also purchased the backups option, you can create slices based off of your other slices – which means that should I ever want a slice with the exact same configuration as my “Max” slice has, all I need to do is go to “Add a Slice”, and select a snapshot of Max to use as the system Image(If you don’t have a snapshot or want a fresh system, you can choose from a few Linux distributions – Ubuntu 6/7/8, Arch 2007.08, CentOS, Debian, Fedora, and Gentoo).

I had Slicehost recommended to me by someone I respect very much, who justified his choice by saying “if your core competency isn’t hosting, why are you focusing on it?” – and he’s right. And if your core competency is building browsergames, you should be focusing on that – not on getting niggling hardware details in place for your servers. I will warn you that you need at least some experience with the command line in Linux to get started – but if you’re really stuck, there are some great tutorials on HowToForge that will get you up and running in no time.

If you’re thinking about signing up for Slicehost, consider using my referrer link – while it (unfortunately) won’t result in any discounts for you, it will get me a slight reduction in the costs for my slice. If you’d rather register without giving me anything, you can use this non-referral link – or just visit their website to learn more.

To begin with, you don’t need dedicated hosting. Shared hosting will work just fine for both testing and the initial game – it’s only once you hit massive numbers of users that you will need dedicated hosting.

One thing you need to make absolutely sure of is that your host has some sort of database, and supports your choice of server-side language. Make sure to confirm that the version of the language that they have is the one you need – I know people who have needed PHP 5 but accidentally started a web hosting contract with a company that only had PHP 4 – it caused them a lot of headaches before they finally switched.

Filespace and bandwidth are something people will always argue about. At the core of it, as long as you have enough filespace for your files, and enough bandwidth to get them out to your audience, you’re fine. What does that mean? If your browsergame is purely code and your browsergame is the only thing on that hosting plan, you’re probably safe with 50MB. If you have a lot of images in your game or your game is absolutely massive(Wordpress is under 2MB of PHP), then you might need more – but for most cases, 50MB will be fine.

When it comes to bandwidth, go with something that seems ‘big enough’. To begin with, you’ll never get close to using as much bandwidth as you have available. When you do start coming close or hitting your cap, it’s a sign that you should upgrade.

Another important thing to consider is stats packages. You should check to see what sort of stats package your web host makes available – this will be important after you launch your game, so that you can keep track of how many visitors you have, what time of the day most people play your game, and other neat statistics.

One last consideration is databases. Some hosts will give you an unlimited number of databases, and some will cap you at a number like 5. If your browsergame is the only thing on that hosting plan, you’d be fine with one – the general consensus is one database per project, unless you don’t have enough available. So as long as your host provides one or more databases, you should be fine in this regard.

There are a few other options that web hosts will offer you – things like Fantastico(which is an automated installer for a bunch of popular website tools), POP Accounts, FTP Accounts, and a whole bunch of other things. As long as your host gives you at least one FTP account, you’ll be fine.

With all that being said, it sounds like choosing a web host is a difficult task. But it’s actually very easy. Here’s the condensed list of what you need:

• Support for your server-side language(the language and the version you will be using)
• Databases(at least one)
• Enough filespace to host your project – anything at or over 50MB should be fine to start with
• At least one FTP account, so you can upload your files
• Some sort of stats package(although if they don’t provide one, you could use Google Analytics)

One last thing that I haven’t mentioned here is price. That’s because it’s entirely up to you what you pay for hosting. I would recommend something cheaper to begin with, because even if your game has a business model behind it, you probably won’t be making any income from it for at least the first few months – so you should choose a web hosting plan you can afford to pay out of your own pocket.

And that’s all there is to it. If you’re still not sure which host to use, I recommend Atomhost – before I started hosting my own websites, they were the host I used and their support team is top-notch – they have a good understanding of any technical problem you may have. Also, if you keep a close eye on their homepage you can sometimes find promo codes that will knock down the price of whatever plan you are considering.