On the 22nd and 23rd of September Warsaw was host to the first ever HTML5 games conference; OnGameStart. While game development in HTML5 is a relatively new area, the conference managed to bring together almost 300 people from all over the world to discuss the future of gaming and game development in the browser. Among those 300 people were 19 great speakers, a large group of organizers and the 4 major browser vendors.
The talks ranged from how to publish and monetize games online to technical discussions on Oct-Trees and how to implement them. The variety of talks made it apparent that we who are interested in making games in HTML5 is a large and diverse group. There were several large companies present who had invested considerable time and money into making games in HTML5, investments which are only just becoming profitable. Some of these companies make game engines (for example ImpactJS and enchant.js) while others focused on the publishing possibilities of HTML5 games (Spil Games).
Microsoft, Opera, Mozilla and Google all had representatives present to evangelize their browser and boast about gaming on their platform. Even the W3C showed up to discuss features which could be included in HTML5 to make games in browsers even better (Mouse Lock is one such feature soon to make its way into the browser). With such major players all interested in game development in HTML5, the future of browser games looks very bright.
Several unsolved issues with HTML5 gaming were discussed, and especially Rob Hawkes (of Rawkets.com) brought up some interesting points about cheaters and multiplayer games. Since the source code of HTML5 games are sent to all the players, and this code can be edited while the game is running, it becomes very easy to cheat in almost all HTML5 games. This is a major problem with realtime multiplayer games, where a JavaScript hacker can quickly ruin the game for all the other players. Rob discussed measures to prevent this by running the game engine on the server side, which introduced new problems due to the network implementation of WebSockets. Because WebSockets use TCP, packets are guaranteed to arrive in the correct order, at the cost of transmission delay. In a realtime game the delay should be as low as possible, and the value of a packet arriving quickly depreciates. Very few people have looked into this problem for WebSockets, and because it uses TCP instead of UDP, it is still uncertain how much can be borrowed from other multiplayer engines (reddit discussion).
Several demos of games in HTML5 were presented, including the Isogenic engine by Rob Evans, and Team Fortress 2 in WebGL by Brandon Jones. These demos show not only what is possible today, but what is possible in the near future. Based on these demos it is impossible to predict what will be available to gamers in 2 years time, when the technology has matured even further. There was also a large focus on mobile gaming, and several games were shown running on tablets and mobile phones, either in the browser or through technology like PhoneGap. The latter is especially interesting, as it enables game developers to release the same native game for several platforms without any further work.
My talk at OnGameStart2011 was titled "How to build a 3D engine in HTML5" and with it I wanted to show how the Canvas element can be combined with JavaScript to create a simple 3D engine in HTML5. A video of the talk is available at Vimeo, the slides can be found online, and the source code to each of the demos are available in my repository (my SVN server crashed, so I have uploaded the presentation to GitHub). The talk was to be less than an hour long, so I decided to focus on the absolute basics of making a 3D engine, completely from scratch. Instead of using WebGL, I wanted to show how a 3D engine could be made using only 2D API calls. While such an engine would not be as powerful as Brandons Source/Quake/Rage engines, it would demonstrate how 3D engines work, and how to optimize drawing in the 2D context.
In the short time since OnGameStart, several conferences have been held where HTML5 game dev has been discussed, including JSConf.eu, a W3C event and in the beginning of November San Francisco will host the New Game Conf. With all of this focus on browser game development, the future of HTML5 games looks really bright, and with the rapid development of modern browsers, things which were impossible two years ago is now easy in all of the browsers. By extrapolating from this it is obvious that nobody can predict what browser games will look like in a few years.
