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.

It’s important to choose a templating system before you start building any functionality more complex than your registration and login system – it will help you speed up your development time, and keep your code and your design separate. If you’re like me, that means that you can safely pass your template off to someone who actually can design, and get them to work their magic on your template – without having to worry about your code breaking.

To that end, what Perl templating systems are there out there?

There are a lot of Perl templating systems available. There’s Template::Toolkit, and HTML::Template, and scores of others. For the sake of this quick guide, I’ve chosen to use HTML::Template – although really, you can use whatever templating system you want to(although my examples will all use HTML::Template).

To begin with, we need to install HTML::Template. There are a number of ways to go about this, and if you’ve never installed a Perl module before I recommend that you read this guide to installing CPAN modules, and then install HTML::Template on your system. Alternately, a lot of systems with Perl on them come with the cpan shell – at which point all you need to do to install the module is run this command:

1

cpan install HTML::Template

At this point, HTML::Template is installed – so let’s build a quick tester script to take advantage of that. First off, we’ll set up the template for the index page that our login page from earlier sends non-administrator users to:

1
2
3
4
5
6
7
8

<html>
<head>
	<title>My Index Page</title>
</head>
<body>
	<p>Hello, <!--tmpl_var name='username'-->!</p>
</body>
</html>

It looks like a regular HTML file, doesn’t it? And that’s the great thing about templating systems. With a templating system, you can write regular HTML and just intersperse markers for whatever content you’re going to dynamically add, instead of hard-coding your content into your template.

We’ll call that template file index.tmpl – our index page will load it in when it outputs the user’s information. Really, you can use whatever extension you like – I just like .tmpl.

The next thing we need to do is write the code for the page that actually loads in and outputs the template. Here’s what that looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#!/usr/bin/perl -w
 
use strict;
use CGI qw(:cgi);
use HTML::Template;
 
my $query = new CGI;
my $cookie = $query->cookie('username+password');
 
my ($username) = split(/\+/,$cookie);
 
my $template = HTML::Template->new(
		filename	=>	'index.tmpl',
	);
$template->param(username	=>	$username);
print $query->header(), $template->output;

All we do in this code is load in the value of the cookie that we set in our login page – named ‘username+password’. Then, we split it based on ‘+’, to return our username and password – because we only need the username, we discard the password:

10

my ($username) = split(/\+/,$cookie);

This obviously shows us that there’s a bit of a problem with our cookie – if a user signs up with a ‘+’ in their username, our split will no longer work! One good way to work around this is to use something a little more complex to divide our username and password, or modify our code slightly to use a regular expression capture instead of split:

10
11

$cookie =~ /(.+)\+/;
my $username = $1;

This way, we’ll retrieve all information that comes before the last ‘+’ sign – because crypt returns characters in the set [./0-9A-Za-z], we don’t need to worry about a ‘+’ sign cropping up and wrecking our regular expression.

Once that’s done, all we do is create a new template object, tell it where to load our template from, and then populate the paramater ‘username’ with the value we pulled out of our cookie. And then we’re finished!

As you can see, working with a templating system isn’t that hard – and the gains you make by being able to instantly use the same template accross many pages are huge. There’s really no reason not to be using some sort of templating system – whether you roll your own, or use a pre-existing system.

If you want to see the example code in action, register, and then login, and you’ll be redirected to the index page – which will display the value out of our cookie.

The answer is that you can – and should. It will help you separate your design from your code, which(if you’re anything like me) means that you can have someone with actual designing skills come through and fix up your template before you push your site out to the rest of the world.

This will be a brief rundown on how to get up and running with a templating engine, which is what we will be using to build all of the other parts of our browsergame in progress. For a PHP templating engine, I’ve chosen Smarty. I did this by taking a look at Smarty’s list of features, and deciding whether I liked them or not – when you choose a templating engine, that’s really all the forethought you need to put into it – will it work for you, and are you okay with working with it? As an aside, if you don’t like your templating system you can always switch systems for your next project.

A lot of developers are fans of “rolling their own” templating system. While this can definitely work, you’re probably going to make larger gains by simply using an existing one – if you need anyone to help you with your game later(or it really takes off and you hire someone), it will be a benefit to be using a system that they might already know as opposed to a proprietary system. Also, why do all that work when it’s already been done for you?

The Smarty website has a smarty quick start tutorial, which you can use to get yourself up and running with Smarty.

Once you’ve gotten Smarty set up on your system, we’ll be building the index page that our login page from earlier redirects to for non-administrator users. To start off with, we’ll just use the testing index.tpl file from the Smarty quick start:

1
2
3
4
5
6
7
8

<html>
<head>
	<title>My Index Page</title>
</head>
<body>
	<p>Hello, {$name}!</p>
</body>
</html>

Next, we’ll use the index.php file from the Smarty quick start, and modify it so that it displays the currently authenticated user’s username:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
 
// put full path to Smarty.class.php
require('/usr/local/lib/php/Smarty/Smarty.class.php');
$smarty = new Smarty();
 
$smarty->template_dir = '/web/www.domain.com/smarty/templates';
$smarty->compile_dir = '/web/www.domain.com/smarty/templates_c';
$smarty->cache_dir = '/web/www.domain.com/smarty/cache';
$smarty->config_dir = '/web/www.domain.com/smarty/configs';
 
session_start();
$smarty->assign('name', $_SESSION['username']);
$smarty->display('index.tpl');
 
?>

As you can see, there isn’t that much of a change made – we add a call to session_start() to load up our previously stored session values, and then we use one of them to display the user’s username. If you visit your testing page, you should see the username that you logged in with – which means that Smarty is working! With Smarty we’ll be able to make sure that our code and designs no longer have to be intermingled – meaning that there’s less chance of accidentally screwing up one while working on the other.

If you want to see it in action, you can first register, then login to get redirected to the index page – which will show you the username you’re currently logged in with.

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.