However, in putting together my latest endeavour (a hack-n-slash isometric multi-player RPG in HTML5 canvas), I’ve learned a few more things and want to share them.

TLDR; I’ve pushed the code I’m currently using to Github and it can be found here: https://github.com/robashton/swallow

Anyway – moving on we can discover some of these learnings:

Simply waiting for requested assets to load via HTTP on start-up isn’t always enough

In my earlier post, I suggested if you had a resource caretaker which you requested resources like textures, sounds, models, shaders etc from – then it could take care of loading the data and return promises rather than the real things, this looked something like this:

1
2
3
4
5
6
7
8
9
10
11

var modelOne = resources.find('models/hovercraft.json');
var modelTwo = resources.find('models/missile.json');
var explosionSound = resources.find('sounds/explosion.wav');
 
resources.on('fullyLoaded', function() {
  game.start();
 
  // use the resources
  modelOne.get();
  modelTwo.get();
});

And the world is a happy place to live in, we rely on those assets coming down via HTTP, rely on HTTP caching and everything else given to us and it works well.

However, we also rely on the initial state of the game indicating which resources it is going to need – and doesn’t account for other resources that might be requested once the game is under way (for example, explosions, other models/textures further in the world, sounds, etc).

This results in negative artifacts like ‘popping’, or sounds being played after the special effect has finished (or in bad cases, the player walking on an empty background!)

Therefore the answer is to pre-load, but how…?

The Application Cache

Now, I’m not going to give a full description of this, but essentially you can tell the browser “Hey, these are my resources, please download and cache them”, for example:

1
2
3
4
5
6
7
8
9

CACHE MANIFEST
# 2012-03-11:v1
 
CACHE:
/favicon.ico
game.html
models/hovercraft.json
models/missile.json
sounds/explosion.wav

We can generate this kind of application cache automatically as part of our deploy process by enumerating through the assets, and we can choose not to re-generate it if none of the files have changed.

When we re-generate it, we can set the timestamp (therefore indicating to the browser that because the manifest has changed it might like to go through those assets on the server and see which ones it needs to download).

We also have similar code to write against this, “Update the resources if necessary, wait for this process to complete”

1
2
3

appCache.addEventListener('updateready', function() {
  game.start();
}, false);

Ace.

This has its share of issues though – the biggest one is probably that it doesn’t really allow for any granularity in your app.

In this modern age of the internet, our users have short attention spans and a long initial load may well mean losing out on users – if you have different levels for example, you probably want to download each level and the assets for that level before you play that level – not at the beginning of the whole game.

In short, the Application Cache is great if you have a small self contained game (such as puzzle games), or if you want to fully support the game being playable offline immediately after download;  it does however come with its share of issues.

That brings us onto another option

Write your own Application Cache

We can easily emulate what the AppCache does for us by writing our own manifest definition and using that to pre-load files from the server. We can then rely on the browser-cache to carry on working the way it always has (so if files haven’t changed, don’t fetch them etc).

This is essentially like our first solution again, except we now have manifest files which describe what data needs pre-loading.

1
2
3
4
5
6
7
8
9
10
11
12

resources.preloadFromManifest('levels/levelOne.json');
var modelOne = resources.find('models/hovercraft.json');
var modelTwo = resources.find('models/missile.json');
var explosionSound = resources.find('sounds/explosion.wav');
 
resources.on('fullyLoaded', function() {
  game.start();
 
  // use the resources
  modelOne.get();
  modelTwo.get();
});

This still causes some issues – the browser may choose to not cache some objects, may decide that some things aren’t available offline, and weirdly give us some issues with sounds.

For example: One issue I discovered with sounds in my last Ludum Dare attempt was that you have to create a new Audio object every-time you play a sound – and the browser re-requests the asset from the URL you give it each time that happens!

Another problem with this approach is again it doesn’t scale too well – if you’ve got 500 textures, 500 HTTP requests is not really appropriate at with the current technology stack (Until SPDY or something similar is supported universally at least).

That brings us to where I am at the moment with my hack-n-slash multiplayer canvas RPG…

Bundle everything up into a single file!

How things come full circle – desktop game developers have been inventing and consuming package formats since time began, and now web-game developers can get in on that action too.

So hence writing a command line utility in NodeJS to scan a directory and package various files into a JSON file.

1
2
3
4

.json -> keep it as JSON
.png -> Base64 encode it
.wav -> Base64 encode it
.shader -> add it as a string

This works well, as on the client loading these assets means writing a small amount of code like so:

1
2

var image = new Image();
image.src = "data:image/png;base64," + imageResource.get();

In actuality, what we end up doing is loading an entire asset package, say ‘assets.json’ and writing the following code before loading the game.

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

$.getJSON('assets.json', function(rawData) {
  preloadAssets(rawData);
});
 
function preloadAssets(rawData) {
    forEachResourceInRawData(rawData, preloadItem);
};
 
function preloadItem(key, itemData) {
  var loader = findLoaderForFiletype(key);
  increaseAwaitCounter();
  loader(key, itemData, decreaseAwaitcounter);
};
 
resources.on('complete', startGame);

Where an implementation of a handler for a PNG might do this

1
2
3
4
5
6

function preloadPng(key, itemData, cb) {
    var preloadedImage = new Image();
    preloadedImage.src = "data:image/png;base64," + itemData;
    preloadedAssets[key] = preloadedImage;
    preloadedImage.onload = cb;
};

This means that once the assets file is loaded, the game can start and there are no delays in playing audio, displaying textures and so on and so forth.

Clearly this is massively simplified, because in the real world yet again what we actually do is.

Do the hybrid approach

• Load the assets for the current land
• Request an asset
• Is the asset in the preloaded package?
• Yes? -> Return a promise containing the asset
• No? -> Return a promise without that asset
• -> Make an HTTP request to get the asset
• -> Cache the asset

For example, my little RPG pre-loads most of the textures and models used across the land, but downloads the actual tile information (where is a tile, what is on that tile) as the player walks around.

This is similar to the streaming that takes places in any reasonable desktop game, and offers a good compromise in a connected multiplayer game (and would work well for a disconnected one too).

I’ll push out the client code I’m using as a library at some point, but that’s not really a suitable candidate for ‘frameworking’, because homogenising something like asset management on the client side can do more harm than good.

That’s the commit history for the project, starting off as an exercise in trying to do some TDD  with some basic WebGL code to somehow ending up building a game of hovercraft, neon-blue grids, and explosions (I’m not good with assets, so making everything glow seems like the cheapest way to make it pretty).

What has been interesting throughout this project (for me) has been the at times subconscious attempts to carry on ‘doing things the way I do it in most of my day to day software’, and finding out that some of the rules don’t apply in this particular space – and some surprising ones do. (or at least, in this specific game in this specific space).

First to go, TDD

Ah yes, TDD – this is a principle I’m beginning to lose my love for in both worlds for a multitude of reasons, but when I started this project I thought I’d applying this way of working to this side of the fence . I created a walking skeleton of the basic technology I was to be using (JavaScript, a browser, WebGL, a server with NodeJS) and started to write tests for each feature as I I wanted to add them.

This started falling over pretty quickly as most of the first features required fundamental integration tasks to be carried out before writing the higher level code (manipulating the DOM, playing with WebGL, loading shaders, connecting to servers) – each of these things requiring a tiny amount of code applied in just the right order in just the right way for the particular feature. As far as feedback cycles go, it was faster to hit ctrl-f5 in a browser and watch the actual code do what it was meant to do or fail pitifully than it was to try automating the running and assertions on those problems.

In essence, these things could have been solved by heading off into a blank project and doing a formal spike, before coming back to the main project and laying out the tests for them to help with the design. It would have given little value however, as they were already-solved problems and the code would change little if I designed it from the perspective of testability or otherwise. I decided to treat the entire project as one giant spike into this domain and just roll with the punches.

Next up the behaviour itself, this is where the formal TDD approach probably would have been a bit beneficial, but I was already feeling headstrong about my initial progress and wanted to just start spitting out features – this led me down a bit of a dark alley as the code I produced wasn’t written or designed for testability and too heavily relied on there being a heap of external components being present therefore making it too expensive to automate the running of the behaviour. Funny how that happens accidentally even though I supposedly know that a de-coupled system looks like.

I actually sorted that out eventually, arriving at a good, clean, testable design when solving a different problem entirely – making it possible to write tests that looked like this:

test(“Hovercrafts can acquire targets when only one target is around”, function() {

  var context = GivenAnEmptyScene()
    .WithAHovercraftCalled("one")
    .WithAHovercraftCalled("two")
    .WhereNotPointingAtEachOther("one", "two")
    .Build();

  var targettingCraft = context.FindCraft("one");
  var targettedCraft = context.FindCraft("two");

  targettingCraft.AimAt(targettedCraft);

  ok(targettingCraft.RaisedTargetAcquiredEventForCraftWithId("two"));
});

Or something along those lines anyway – note how I said “made it possible” – I found that the biggest value tests I could write were the ones describing  complex interactions between entities in the scene (but ignoring external components) but because the system is relatively small and because I’m the only developer and because I was changing everything all of the time to make it more fun to play that they simply weren’t worth writing.

If I had been part of a team or the system was larger and more complex I think it would have been worth it – and the lesson on how to arrive at this point was a valuable one, I’ll be writing tests for my next game at about this level and not worrying about the fluff.

The big difference here is I guess not one of games development, but of mentality and because I’m unused to working on projects where I’m the sole owner and I’m not going to have to ship it off to another developer in six months – I think apart from the core integration code there could be a lot of value in writing tests around gameplay interactions in most games dev, in this I don’t think our two worlds differ all that much.

Messaging

Push, don’t pull – that’s the mantra in most of the software worlds I work on – send a command, forget about it, raise an event, forget about it – deal with your own problems, maintain your own consistency, and let everybody else do the same.

I messed this up big time, turns out dealing with messaging in an interactive simulation across multiple clients and a server can throw up some pretty interesting issues at times, at one point I was cursing my decision to go with a push based architecture because it was becoming such a nightmare to deal with.

Now, other than duplication of data (and there certainly is some, memory is not my bottleneck), the biggest issue was just trying to work out which event had come from where and why it arrived in the order it had and why it had made something happen that shouldn’t have happened.

My mistake, was to consider this system like any other piece of business software I have worked on – when most of the software I have worked on in the business world has been of minimal behavioural complexity. Going back to my above statement on “maintain your own consistency, and let everybody else do likewise”, I wasn’t paying anywhere near enough attention to this and ended up with inconsistency everywhere, I was capturing events at the wrong level, I was dealing with state at the wrong level – I was … well yeah, doing it wrong.

I spent a few days tidying up this mess, and formalising heavily between the different types of messages – commands being external inputs to the system telling it to do something and events being things that have happened, and anything that goes over the wire or between entities are going to be one of these things.

I switched a lot of the code so that entities that raised events also listened to those events to update their own state, and every other unit or subsystem did likewise on receiving those events, effectively turning each event-listener into a de-normalised view around its specific area of functionality.

Turns out I by accident ended up with a system not unlike this: http://martinfowler.com/eaaDev/EventSourcing.html which is where my testability came from, also giving me a system that was easy to onion ring new functionality onto.

A retrospective however, I think in a larger system I’ll have to be a lot more careful about this if I want to run on more portable devices which are more constrained on memory usage – I don’t think I’ll move away from ‘push’ just yet though, just move it up a level so I minimise the number of de-normalised views in existence for pulling by the clients that need them.

Client vs Server

One of my biggest mistakes was in how I tried to at first distinguish between code that the client had permission to execute and code that only the server had permission to execute. (For example, killing a player is something that the client can witness, but it can’t take place until the server has deemed it acceptable).

I tried to deal with this by having different endpoints on the client and server, containing the different logic and messaging each other before proxying the relevant commands back into the scene. It looked a bit like this:

I then when bootstrapping entities into the world would attach different components to them if they were in the client to if they were in the server, supposedly making it easier to control who had permissions to do what.

Computer says no.

Turns out that this was a recipe for disaster, going back to the part where I talk about “maintain your own consistency, and let everybody else do likewise”, this is completely counter to that goal, the receivers in between the two worlds got fatter and fatter, and pulled more of the logic out of that world and the entities that were driving the game and made it once again hard to work out what was going on. We have a name for this in our general software world, an “anaemic domain model”.

Going back to the messaging aspect above, it ended up being much easier to push everything into the world (including score management etc) and have them as entities that could raise events, and handle other entities events and therefore contain their logic and guard their state more appropriately. To do this in a ‘safe’ manner, I’d just have two methods on an entity

• raiseEvent
• raiseServerEvent

And the entity component would be responsible for determining what it considered to be a special event that only the server could raise – the rest of the logic would be completely identical. As I’ve already suggested, having entities listen to their own events to react to change is a part of this – once raiseServerEvent is called on the server and the event automatically proxied through to the client, the code on the client carries on as if it was itself that raised the event.

This model looks something like this:

And is suddenly much easier to test and maintain – not to mention that now I have the possibility of running offline games by flicking a flag that allows server events to be raised locally. Perhaps a rename of the method to “raiseProtectedEvent’

Next steps

My next steps are to go through the 10 issues written down on a pad of paper next to my desk, wait for the domain name to propagate and push it out onto the internet on its own domain name (without publicising it too much as my client code isn’t too optimal and more than 30 players will probably kill most browsers, oops). I’m pleased with the learning achieved with this project and it is a real joy to see that my time building software that isn’t games hasn’t been completely wasted (lots of principles carry across it seems, although it pays to be more mindful of your state).

I have some profiling to do too, I seem to spend 5% of my time in the garbage collector and 15% rendering particles and a whole lot of other things that really shouldn’t be sucking that much time. This will be fun and no doubt result in yet another blog entry about JavaScript performance.

And then onwards to the next game, I have some ideas about what challenges I want to set for myself in this space and a game that I want to build that will set them for me.

Asynchrony

First things first, this is a really interesting cookie – what is the following code actually doing?

var image = new Image();
var texture = gl.createTexture();
texture.image = image;
image.onload = function(){
// Set up the gl texture
};
image.src = "texture.gif";


And how about this code?

var model = new Model();
$.get('/models/teapot.js', function(data) {
model.setData(data);
});


If you’re familiar with how Javascript works then you’ll know that after image.src, code is going to carry on being executed while the resource loads, and then in the callback provided you’ll get given the data which you can then do stuff with.

Think about that for a second, what we’re saying here is that the game can start while content streams in the background and when those resources have loaded they’ll magically start being used?

Well no – not really, WebGL itself is quite tolerant and while you can set null buffers and null textures all over the place with no dire consequences, it’s not really recommended and you get a truly awful user experience while this all happens.

Most of the WebGL games I’ve come across fall into this pit, and for a few minutes you’re sat there wondering what all the pretty colours and odd shapes on the screen are supposed to represent as the game carries on running oblivious to the fact that none of its assets are loaded yet.

Asset Management

So it’s obvious that you have to actually think about asset management when writing browser based games (especially with WebGL when you have large models and textures to download).

My strategy for this is no different to the strategy used when dealing with assets like these in an offline game, I wrap the resources in types (Model and Texture), and stick code for pulling those assets out (or pushing them in) to a resource manager of some sort which can report back to the application the number of textures/models currently waiting download, so some sort of loading screen can be presented to the user.

All in all, this takes about 50 lines of code for a minimal implementation, because the code for actually loading those assets, the code for actually creating the textures, dealing with the memory, dealing with the fact that they’re all being loaded in the background (potentially on different threads) has already been written for you in the engine executing the JavaScript.

var texture = resources.getTexture('texture.gif');
var model = resources.getModel('teapot.js');

resources.onAllAssetsLoaded(function(){
game.Start();
});


Packaging your resources

So this is an interesting one, in most games I’ve looked at, you tend to have a specialised packed file format in order to have a single handle to a single file which you can easily seek through without going through the expense of seeking multiple files, perhaps compressed – all to minimise loading time when pulling data off disk and sticking it in ram.

You’re limited here to a certain extent, but we can learn from some of this in that we can sensibly package our data.

So, here are some largely uninteresting suggestions that should be obvious to most of us :-)

• We can package our models up via minification/packaging scripts
• We can package our code up similarly
• You can do the same with textures (mega-textures in the browser, has anybody investigated the performance of this?)

The art of unloading your resources

So, what happens when you download your resources What are you actually doing? And just what is a resource anyway?

Now we’re into vaguely interesting territory, if you’re writing a game where all your resources fit comfortably into memory then you haven’t got to worry about anything I have to say here, but if you’re planning on writing something that will be open for more than 15 minutes of casual gaming, and traverse a few miles of level then you’ll want to think about stuff like this when dealing with your resources.

The lifecycle of a resource looks something like this:

1. Load the resource from the server/cache as a file [Disk space]
2. Load that resource into memory as an meaningful object [Ram]
3. Use that resource wherever it is needed
4. Dispose of that resource when you no longer need it
5. Go to 1 or 2 again when necessary

So, 1, 2 and 3 are well covered by all the tutorials out there on the web, but what of 4 and 5? What do we have to take into consideration when working in our browser with these?

First up, you don’t have deterministic garbage collection in Javascript, you have methods on your WebGL context to create and destroy resources like so:

gl.createBuffer();
gl.deleteBuffer();
gl.createTexture();
gl.deleteTexture();


Which is nice, because it gives us a way of clearing up the memory used between the device and the host, but it doesn’t actually clear up the memory used in loading those textures/buffers in the first place.

Consider the following:

var vertexData = new Float32Array(10000 * 3);

How do you clear that up? How do you delete it? Well it’s quite obvious really when you think about it, with a simple call to

vertexData = null;

Now, this is overly simplistic, garbage collection is up to the individual implementation of the engine concerned, and they’re hardly simple reference counting implementations – but my point is simply that you should be careful with how you’re loading your resources, and who is referencing what. (Another point towards wrapping the big pieces of data behind some nice classes and a resource manager).

This does however make the way we download these models somewhat important.

Consider the following model format that the WebGL exporter gives us (Note: I need to commit some changes to those soon, I have quite a few additions)

var BlenderExport = BlenderExport || {};
BlenderExport.Cube = {};
BlenderExport.Cube.Vertices = [3,3, etc]
BlenderExport.Cube.Indices = [0,1,etc]


What actually happens when you include this file into the application? Well – the file is executed, and when it is excecuted, we’re given a global variable called BlenderExport which contains a variable called Cube which contains a big pile of data as arrays of primitives.

Will this ever get cleared up? Any code could potentially reference this at some point, so it’s unlikely, it’s in the global namespace – anything could reference it at any time, I don’t think it’s going to go out of scope (Please correct me if I’m wrong here! hah – challenge my ignorance indeed).

What I prefer to do is to stick my models in plain old JSON format like so:

{
Vertices: [3,4,3, etc],
Indices: [3,3,4]
}

This can be pulled down via a call to $.get(”) and parsed with JSON.parse(), resulting in a local variable which can be given to my Model object containing the data it needs to hydate itself. The actual file will get cached so subsequent calls to $.get(”) will pull the data from wherever the browser stores such things, so the model can be destroyed if it isn’t used any more, but also safely re-requested whenever it is needed.

Textures are obviously simple enough, because we have no control over them (Remove the reference to the image, say goodbye to the memory).

Summary

Anyway, all I’m saying is that you need to think a tad if you’re going to create anything other than a casual throw-away game in the browser with WebGL and JavaScript, it’s not actually all magic and you should be thinking about how you load/destroy your resources over time rather than just simply loading and letting things happen and not thinking about how you’re going to keep memory usage sane.

If you want to read some related material on various patterns for encapsulating state/logic safely, then wander over to http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth and enjoy.

Any thing I’ve missed out? Feel free to educate me.

Today’s entry will be a quick introduction to HTTP in the context of content delivery in games development.

I am personally writing code for WebGL (which sits in the browser), but this is generic enough that it can be applied to any browser-based game – and in fact, I’d put forward that it is generic enough for most mobile games too if you lot would hold back on re-inventing the wheel once in a while ;-).

[Insert tech here] is just yet another way of writing cross platform code that runs slower than everything else.

Before launching off on one, let’s understand why I ended up wanting to talk about this – one of the biggest questions I get asked by people is “What new do any of these browser based technologies really bring to the table?” (and why are you wasting your time with hovercraft when you could be making money?)

And they have a point, apart from the supposedly cross-platform nature of these technologies and having content delivery sorted out for you, there really isn’t much differentiating them from say, cross platform C* with OpenGL.

So let’s look at content delivery and see why this is a (nearly) automatically solved problem in our browser-based games.

*(if you can ever call it that)

Our old ‘new’ content delivery mechanism

HTTP is old and it was originally built to provide interaction with documents to various network clients.  It is also much more than simply “GET/POST url host: example.com” (Although judging by most of the awful abstractions built around it in the past decade you’d be forgiven for thinking otherwise).  It has built in support for caching, re-directs, updates, deletes and this has has been more widely realised of late – even in the largely enterprise IT world that I reside in (well, to an extent).

This greater realisation has brought with it a suite of fresh-faced, lightweight new web frameworks such as Sinatra, Node.js, etc, which rather than distort HTTP beyond recognition instead seek to provide a low level abstraction over the protocol itself, and augment that with helpful libraries and supporting code.

We also find ourselves with more developers potentially targeting the browser for their games with emerging technologies such as WebGL and Canvas coming into fruition,  and with those games getting larger and more complex we’re entering the territory where we need to know about content delivery and actually think about what is going on when we include files and textures into our games.

These two trends are rather supportive of each other as we’ll see.

Content delivery?

So, in games development, I have been led to believe that unless you’re doing everything procedurally, that games require assets – and indeed without exaggerating too much, I think that most games require an awful mega huge amount of assets.

If you’re working in JavaScript these assets will take the form of big blobs of JSON which can be brought into the client-side application via either ajax calls or simple include directives at the top of the HTML file, these assets will also include textures which take the form of standard viewable jpegs/pngs/whatever else your target clients support.

This is interesting, because you get an awful lot for free here, as browsers support (most) of the HTTP protocol and a good server supports more than enough of it to give you all the content delivery you need.

Here’s the thing though, you don’t have an awful lot of control over this process (sorry guys), compressing all of your assets to a single packed and compressed proprietary format and shipping it with your game via some magically efficient wizardry is quite impractical, although not entirely impossible.

What we’re saying really, is that if you want to get content into your browser-based-game you’re going to be downloading those assets via HTTP.

The content itself

There are only a few types of content you can download into your browser when creating a browser based game with the current technology stack and these take the form of:

• The code for the game itself (JavaScript)
• Models/data about your entities (JSON)
• Textures (Images)
• Sounds (WAV/whatever)

There really isn’t too much outside of this – and in fact it is all but impossible to envisage anything outside of this save for perhaps a few custom text formats which you might write parsers for in JavaScript (I don’t see this being a common use case if you’re wanting speed, JSON is native to JS after all).

Taking advantage of HTTP

If you’re writing a mobile game for any of the various mobile devices, you’ve probably hit the size limit for whatever application store you’re deploying to and realised you’re going to have to pull content down from a server somewhere (Or start to compress, compress, compress).

This is quite interesting, as there are many parallels to be drawn between delivering content for those games, and delivering content for our browser-based games – except that with browser based games we haven’t got to do any of this work ourselves because the client and server protocols are not just defined but we’re running in a sandbox which natively supports them.

So, for example:

I want to pull down resources I don’t have yet

In our client’s terms, this is an HTTP GET, and our server just needs to return the data requested – nothing more elaborate than that.  This is the request the browser will make whenever you download the initial page hosting the game,  include a script, attach an image to a resource or well, anything else in fact.

I don’t want to pull down resources I already have, but I do want new versions of those resources

In simplest terms, the HTTP protocol supports this, you make a request for a document with a specific version/date/etag/whatever and the server returns “304 not modified” - job’s a good’n.

I want to compress the data coming down

Surprise surprise, HTTP supports this too, and most browsers and servers implement gzip, which most clients will opt in to by sending “Accept-Encoding: gzip” to the sever on initial request. This means that you can tell your content providing server to compress content as it sends it, saving band-width, time and money.

Implications for browser based games

In a browser based game, you can safely just ask for all the JavaScript files you want, you can safely ask for all the images you want, you can safely ask for all the sound files you want and you can leave the caching of these assets to That Which Knows Best – the client (browser) and the server (whatever that may be).

If you haven’t got any multi-player and you don’t need to generate anything dynamically, then you can just stick your assets behind a minimal web server, and serve a static page which downloads those static resources and allows the user to play the game at their leisure.

If you have multi-player, or some other need to run code server-side, then you can use something more dynamic for this – I am personally using paperboy for all my static files in node.js, and I make sure that when delivering dynamic content from the server  (such as world-data that gets modified over time) that caching headers are set appropriately.

In a more intensive deployment I’d probably separate the two out, and have static files served via a CDN (Content distribution network), and dynamic files served from the node application. The technology itself is irrelevant as it’s just an illustration.

You don’t need to implement any client-side content caching yourself (I’ve seen people suggest using Local Storage for this – no, no and no), you don’t need to implement any transfer protocols of your own and you don’t need to get all elaborate with caching and e-tags – it’s all right there for you in the way the browser talks to the web server.

Other (non browser and specifically mobile) games

Given all of this, is there any real reason to go and write heaps of code for content-provision in your average mobile game? I would put forth the answer ‘no’, because HTTP seems to do quite nicely for the rest of us and wait for the inevitable “But I really needed X or Y so I wrote it all myself“.

Given the amount of off the shelf software available for doing HTTP both on the server and the client, it surely doesn’t make financial sense to be spending any more time on this than absolutely necessary.

(That’s Mike’s “Challenge your ignorance” challenge undertaken then) - I genuinely would be interested to hear if there are any reasons why HTTP isn’t good enough (raw performance is a hard sell, but feel free to try), as trying to come up with answers for any of these problems in a pure browser-based-world will be a useful exercise.

Next time…

I am going to post the second half of this entry (I split it in two because it got too big), and talk about specific browser-based  stuff – like strategies for loading resources, unloading resources and in general being a good citizen to both your users and to your bandwidth. I might even find time to talk about constant-loading/streaming worlds and how I think that works in a purely browser + standards based world.

Oh, and unlike this entry, there will be some code snippets.