Yesterday I went to London’s Old Street to talk about HTML5 and the web at the Mozilla Labs Gaming Special. Here are the slides, the audio and my extensive notes of what I had to say.
The audio recording of the talk is available at archive.org:
Notes and background
When I grew up there was a big discussion about what the coolest toys are – Playmobil or Lego. Playmobil was already built for you – cars, ships, planes, houses and so on – whilst Lego needed assembly first. This resulted in most of the cases in Playmobil being much sturdier – ships actually swam rather than gradually sink because of the gaps in between the Lego bricks. It also meant though that you were limited in what you play with. It fired the imagination of kids to come up with stories that the final product plays a part in but it meant that the kid did not get the satisfaction of building something from more or less nothing.
The benefit of Lego over Playmobil became apparent when the new toy got boring – we’ve played a lot of scenarios where the police motorbike can be a part of. In the case of Playmobil this meant the kid wanted a new toy and the parents had to buy a new one. Good for Playmobil – bad for the parents. Also, bad for the toy as it got discarded and last but not least bad for the kid as it learnt from the get-go that life is about using and throwing away things rather than re-using.
Building with smaller, easily available components
And this is where Lego is awesome – when you are tired of the truck, dismantle it and turn it into a ship, a lamp, a race car, a dinosaur – whatever you can come up with. Much like open web technologies are. Instead of having an application that is a packed executable binary you build your systems from smaller, reusable components that can be mixed and matched to allow the system to mutate and cover different needs.
Lack of access to cool features
One argument against open technologies is that native code and closed systems give us more access and more systems to play with. You can access the camera, the address book and the compass of systems when writing native code and in HTML5 a lot of the things are still beyond your reach.
The question however is if you really need all these features or if it isn’t a better idea to concentrate on what makes most sense for the end users. I for one am spooked out by a lot of games wanting full access to features of my phone they don’t use but may need later on and want to avoid having to renew the question of access. A Tetris clone really doesn’t need to access my address book.
Of course things are cooler if you can access the physical features of a phone – many a time in Angry birds for example I tilted my phone backwards when I didn’t want the bird to fly too far. In essence though this would be cheating physics and the Angry Birds developers didn’t want to allow me to do that.
You have to ask yourself though – if you build a game is it important to use a lot of cool new features and have a short-lived “Ohhhh” effect or is it more beneficial to build a solid, long-lasting game. Making things complicated doesn’t make them good.
Take Canabalt for example. A simple, fast-paced, pretty addictive game that was built for the web first. The developers then ported the game to iPhone and wrote a great write-up how they tuned it to run smoothly. This game needs one button to work – that’s it. Later on adult swim took the same feature and wrote Robot Unicorn Attack which has the same idea but quite a different style.
Some games appear amazingly simple – take PacMan for example. If you peek under the hood though as Jamey Pittman did in the PacMan Dossier then you will find that the original PacMan had quite an amount of artificial intelligence in it – the way the Ghosts (which all have quite a back-story and personality) behave. I am not sure if this logic was included in Google’s HTML5 version of PacMan – would be good to find out.
If Angry Birds were web-based
Which brings me to the phenomenon Angry Birds. An amazingly addictive game (I solved all levels once and then bricked my Nexus One so I had to play them again) and already a viral and social web phenomenon. There are Angry Bird meetups, people dress as them and there are viral videos of peace treaties between the pigs and the birds. Talking of videos, when you get stuck then there are lots of YouTube videos of how to solve a certain level (which saved me quite a few times).
Angry Birds is not a complex game – there are some physics involved but nothing too amazing. It works though – it leverages the quality of touch interfaces and it looks just great. The pigs laughing at you when you failed to bash their forts make you go on. Freeing more and more bird species with different skills (Boomerang birds FTW!) makes it interesting and the designers have done a wonderful job keeping the pig forts hard to crack and visually pleasing. Most importantly – there is no text in the whole game – as everything explains itself.
However as I expressed on Twitter wouldn’t it be cool if you could edit your own levels? This could blossom into a big community of Angry Birds designers. Rovio answered me they have been thinking about it for a while but are not there yet. However, as you can’t stop the signal some people already decompiled the game and wrote an own level editor in HTML5 – something that could have happened with the consent of the company, too. Here are a few other things a web/open tech version of Angry Birds could have that would make it even more engaging:
- Multiplayer – one player builds fort with pigs, the other plays the birds.
- Comments and hints – explaining how to solve the level the best way
- Voting and indexing levels by frustration level – you could sort the levels by complexity and give people a quick one to solve on the train between stations or a brain teaser to spice up a boring meeting
- Fan-built levels – with prizes and official endorsement for the best ones
- Simple re-use across platforms – just compile the web version to native code
HTML5 for truly open gaming
HTML5 is not about having some cool new tags. It is about having higher fidelity of interfaces with web technologies and still not sacrificing the ideas of being open, reusable and modular pieces that work together. We can have audio and video for our games without having to bend over backwards to access parts of them or modify them. We have a canvas which is like a stage in other systems.
If you use HTML5 on the web you already get the viral and linked experience of systems for free. People can also learn from your games by looking at the source but even better would be to write a blog post sharing the information on how you tweaked and scaled your game. All this information has been assembled at least five times before. Old school game development on low spec platforms (Commodore 64, Spectrum, 286 PCs, Gameboys) and especially Flash games had exactly the same issues to face. Now we can take all this knowledge, put it in a very promising and supported new technology and make everybody a potential game designer – not only big companies who charge you for building something with their SDK. The hacked level editor for Angry Birds shows that people can create what they want already – why not harness that energy and do good together?
Another benefit of the web is that upgrades and fixes are easily deployed – no need to upgrade an app or remove/install a new one that you have to download as a whole. This should be the normal case, but right now if you are out of the range of your free data plan on a mobile you have to download quite an expensive chunk – not a nice experience.
The best thing about HTML5 is that the documentation comes for free and there is currently a massive community forming based on the principles of sharing knowledge rather than charging you for information that is outdated by the time you get the printed book.
So, pick your bricks, connect them and play!