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.

I always like to prototype my projects before I start them – I start with the template, and then start building quick mockups of functionality I plan to have. Usually, the code that I used to build my prototype can be cleaned up and used to build whatever I’m building anyways, so I’m still writing code towards my goal – with the benefit of having something to show for it a little faster.

With that in mind, I set out to build a simple tester page that shows off some of the Javascript that will be behind Working Title’s ‘play’ page – while it doesn’t do any posting back, it demonstrates what the functionality is supposed to look and feel like(albeit a little faster than it would be in the actual game). Here’s the Working Title test page, which will let you see how I’m planning on having the game behave.

One interesting element that has recently come into play in the realm of Javascript is the canvas element – it allows a user to draw whatever they want to inside of it, using nothing but Javascript. The canvas element is still in it’s infancy at the moment – and therefore, not supported 100% across every browser. However, that doesn’t mean that you can’t do cool things with it(and Firefox 3 supports it, so there’s no reason not to encourage your users to upgrade).

Sebastian Schaetz, a Building Browsergames reader, has recently created something using the canvas element that I thought was pretty cool: a 3D starmap prototype.

You can take a look at the prototype itself here, and read Sebastian’s blog post about it here. It’s important to note that the code to create the starmap is open source, under an MIT license – which means that as long as you preserve the licensing information, you are free to do whatever you want to with the code.

Now, if you’re building a browsergame based around the mafia or a medieval-styled RPG, this might not be all that useful to you – but if you’re planning on building a game that’s space-oriented, you might want to keep this in mind.

Hey, have you built something cool that you think other browsergame creators could benefit from? Send me an e-mail about it at buildingbrowsergames@gmail.com!

It’s actually a very simple feature to add – all you need is three lines of Javascript:

1
2
3

window.onload = function() {
	document.getElementById('username').focus();	
}

The HTML you need to use looks like this:

<input type='text' id='username' />

And as long as you have both of those pieces, whenever a user visits the page the username input box will automatically get focused into. It’s a small and easy change to implement, and it makes a huge difference to how easy it is to use your game’s forms. For example, visit Urban Dead and Kingdom of Loathing and start typing the moment the page loads up – as you can see, on Kingdom of Loathing you’ve been focused into the text box, and can therefore just start typing to log in. On Urban Dead, you need to find the textbox, and then move your mouse over to it and click on it. It’s just not quite as nice and easy as having the field auto-selected for you.