Interview on HTML5 Game Development

Here’s an interview on HTML5 gaming and the Chrome Web Store which took place at Casual Connect, Kiev, last October. Excerpt:

HTML5 speaks to what games are very well – and the opportunities Canvass presents means good things for gamers. That combined with the new avenues to purchase new apps and content through PCs and mobile, when you combine that delivery with the development environment for the industry there is a real opportunity.

Letters from a Gaming Newbie

I was pleased to attend Casual Connect this week and talked about how HTML5 is becoming viable for games development, alongside my colleague Mark, who covered the Chrome Web Store in general. I was definitively there in a purely web geek capacity, as gaming is not an industry I’m very familiar with. So here are a few things I learned:

  • Casual gaming is quite distinct from “hardcore” gaming. (as @Eastmad reminded me on Twitter.)
  • Casual gaming is heavily intertwined with “social” gaming these days – games on Facebook et al.
  • The social network is just “the graph”. At least for some games, they’re architected to separate “the graph” from the core game logic, so you can swap in and out different social networks. The graph is of course essential for gameplay with social games as well as viral adoption.
  • The industry is mature – there is a clear ecosystem of companies with different roles. Studios make games, publishers distribute them, portals aggregate them, social networks provide the graph. And then there are ad networks, analytics, hosts/caches, development tools, virtual currency providers, consultants. (Very cool seeing how any vertical quickly evolves into a distinct industry structure. Adam Smith approves.)
  • The industry is sophisticated. There is a big aspect of number-crunching, analytics-driven, thinking, e.g. pinning down the cost of customer acquisition. There’s a feeling that monetization is the best growth opportunity right now, more so than increasing the number of players. 1-2% of people spend, whereas with Massive Multiplayer Online games and in Asian markets, 5-10% is more common.
  • Trends to watch: Streaming games (Gaikai, Onlive) – It’s amazing it actually works, but these are technologies that treat the user’s computer/browser as a dumb terminal and stream the game’s video down to them; location based games, merging real and virtual worlds; embedding games into the fabric of the web (e.g. through widgets etc), so they’re not just isolated in social network sites and dedicated game portals; combining genres, so that hardcore gamers can interact with their casual gamer friends; using multiple channels in clever ways, rather than just porting the same game to ten different platforms.

Live Blogging Open Source Show and Tell (OSSAT) at TheTeam, November, 2009 (Part 2)

standard live blogging warning

Continuing on from part 1

Phil Hawksworth: Playing with Each Others’ Toys

Phil describes the open source spectrum, from open-fan to open-curious to open-skeptic.

Open source is about sharing, so in that spirit, he’s going to show us some toys he’s made.

First up, Polaroiderizer. One of his lessons from this was don’t register a domain name that can be spelt and pronounced in many different ways! But back to Polariser…

The tool is made with simple technologies, requiring nothing more than some text files. HTML and CSS, JQuery, Flickr API. Able to be put together in just a couple of evening’s work.

Next specimen is Pinboard. Similar tech. This time, there’s a server, so he’s used the excellent Sinatra. Along with Ruby and SQLite. He did the whole thing in Heroku, pushing to it via Git.

And then there’s vlolly, Phil’s ticket to an early retirement as soon as it goes viral. Another open source project with Ruby, using base62 gem to generate unique IDs.

Rain Ashford: Open Source Gaming for Handhelds

Having convinced us she is a true gaming geek, Rain walks through a few of the nicer open source games out there, including:

  • Malice
  • Lemmings
  • Word Up!
  • Meteorea
  • Setsuzoku no Puzzle (hosted on “DS Scene” so it must be cool)
  • Pocket Physics
  • NitroTracker
  • FreeDroid Classic (based on C64 “Paradroid”)
  • XRoar (Dragon emulator for DS and GP32)
  • Nethack (DS and GP32 ports)- still going on strong

This session yielded the most challenging question of the night: Can you smell a wumpus?

Robbie Clutton: iPhone Dev

What’s all this objective C? A bit like C and C++, but also message based like Smalltalk, which is dynamic but not, and object-based like Java. In other words, it’s a different paradigm to what you’re probably used to and it gets tricky working out which languages to take design patterns from.

When Robbie started looking at how developers can embed a web view into their app, he started wondering about the possibilities of developing an app that’s mostly a plain old web app. Doing this would make development incredibly easy and you could get data from the local device in addition to the cloud. However, you don’t get any device integration, and some events like gestures don’t translate well.

Enter Phonegap. It’s open source, cross device, and gives you integration with native features like vibration and the accelerometer. The way they do this is quite neat – your app basically connects to a phonegap server. So you do things like vibration by making standard Ajax calls. (The calls actually go to URLs with “gap://” protocol). Demonstrating the power of open source with a strong community, Robbie’s submitted patches which have gone back into the product.

HTML 5 is a better way to do it in some respects. One of the obvious downsides is it doesn’t show up as a native app, though you can still provide a HTML5 manifest so the app loads straight from the phone. There’s also the question of talking to specific device features. You can do it in a limited form with device-specific meta-tags, but of course it ruins the whole standards-based approach to web development; move to another phone and you’ve got a port job ahead of you.

One of the nice things about this approach is you can use it elsewhere too, e.g. if you can put the whole thing in standard HTML, CSS, and Javascript, you just create a simple XML file, run “adl application.xml”, and you now have an Adobe Air powered desktop app.

Another DHTML “Game”

A new DHTML boxing “game” from the Man In Blue. Not quite DHTML Lemmings or Super Maryo World, but still more fun than it should be. A bit like the Ruby On Rael thing in reverse.

Also from the same presentation is an eerily lifelike OSX clone (Firefox-only). More evidence that Ajax might be useful in prototyping desktop apps. And since prototypes usually go on to become the real thing …

Thanks to the Web Essentials organisers for podcasting the talks. Safran on Sunday will have to go on hold for a while.

Ajax Periodic Refresh, Chat, and Multiplayer Gaming

First, a quick update on yesterday’s book anouncement: Thanks for your interest. Yes, it will be published as a physical book. In the O’Reilly animal format. And no, I don’t know which animal.

Periodic Refresh is a pattern where the page runs a loop to continuously grab fresh data from the server (Ajaxify Time Demo).

As that pattern explains, there are quite a few chat systems that work that way. And a slashdot poster pointed out that many Japanese chat apps worked the same way in the late-90s, albeit with full page refreshes instead of [XMLHttpRequest](XMLHttpRequest Calls), because the web handled the character set better than desktop GUIs.

When I first heard of Google Talk, I thought “Hello, Google’s doing Ajaxian chat”. But, no, the text/IM component for now is a windows-only Jabber client. There’s a great opportunity for a hybrid approach here – provide a rich client which will stay on 24×7, pop up when a message occurs, and show an appropriate icon in the system tray, and also provide a web client which can be used wherever you are. Google is well-placed to do it because (a) they certainly know how to Ajaxify; (b) they need to Ajaxify – windows clients are fine and dandy, but in order to sustain its advantage, Google has to change the rules of the game by establishing the web as the platform, not the desktop; (c) Periodic Refresh is expensive because frequent requests must be handled and Google, well, they can take the hit better than most.

So in a way, I feel like Google’s missed a trick here (but then, you can never be sure what they have up their sleeves). There’s already JWChat, an open-source Ajaxian Jabber Client. While JWChat’s demo is really just a demo, I wouldn’t be surprised to see someone picking it up and creating a serious public website based on it. Meanwhile, there are offerings like QWAD Chat which are taking the business model for Ajaxian chat very seriously.

Yesterday, another interesting announcement:

We are working on an open source project to develop a peer to peer graphical adventure game, using AJAX! Looking for AJAX developers of any skill level who want to pitch in and help out! Interested? Download the first version (single player) at http://www.p2pmud.com

With Periodic Refresh, Ajaxian multi-player is feasible. I’m curious to see how far it can go. There’s a few game examples already, including Crisp’s stupendous DHTML Lemmings effort. In their inaugural Ajaxian podcast, the Ajaxians discuss SVG, which is finally about to become a reality on Firefox 1.1. Combine SVG with Periodic Refresh and we’ll be gaming like it’s 1995. (But without the sound effects. Playstation and X-Box have nothing to fear.)

As an aside, a thread a while back on Google Groups discussed whether unique URLs are worthwhile for Ajax apps. The argument was, why bookmark your state within an app? Of course, one answer is that you want to bookmark a particular object, like a location in Google Maps. But, when you think about it, why not bookmark the state in an app. I mention this because it would be sweet if you could have a unique URL for a position in a game. So you just bookmark it instead of saving it or you can mail it to your mates.

As another aside, I’m glad Google Talk went with Jabber and I hope they really do move to SIP for voice as they’ve hinted. IM today is popular, but it could easily have been ubiquitous by now if not for the fragmentation caused by AIM/ICQ/MSN/Yahoo/IRC/Jabber splitting the market, thus exponentially dropping the value of using a given solution. Now, voice has skype, Gizmo (SIP-based), Google Talk, as well as the offerings from the IM incumbents.