Building Browsergames

Hosting Review: Slicehost

As you may or may not know, Building Browsergames was offline for a short while this weekend. I was transferring Building Browsergames from running off of my own, dedicated server to a Virtual Private Server from Slicehost.

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.

What you need to look for in a web host

There are a lot of web hosting companies out there, and all of them offer different things. It’s hard to decide which one to use, and which features you actually need when you’re choosing a web host for your browsergame.

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.