- Why use HTML5? It has high reach, ease of development, avoids 30% tax, it's a Flash replacement on mobile browsers, and it offers quick iteration.
- There are a few problems with HTML5 right now though. The tech is a moving target (DOM -> Canvas -> WebGL), it's fragmented, there's few "real" games, there are no big success stories yet, and many tech challenges (audio, animations, etc.)
- There are many HTML5 game engines available today. In fact, there are more HTML5 engines than there are "real" games. When choosing an engine, you should evaluate its traction (how is its growth?), your team size, its toolchain (what IDE, visual editors, debugging tools does it use?), its features (canvas, WebAudio, physics), its reach, the languages you can code in, and its price.
- There are many deal breakers that make some HTML5 engines useless. These include no links or examples of real games developed using the engine, no multiplatform targeting, no WebAudio support, no canvas, no lazy loading, no Flash animation integration, closed source, unresponsive development team, large unoptimized sprite sheets, no language support other than Javascript, no screen scaling without affecting aspect ratio, bloated keyframe animations, no cutscenes, no object pooling, inefficient memory management, missing abstractions from browser quirks, no multiple renderers, no localization, and no embeddable entry point JS file.
- Javascript sucks for development. It has no strong typing, can't cross-compile to native code, it doesn't scale well for big complex teams, it has no compile-time error checking, no code auto-completion, no code navigation, no abstraction layer for browser differences, difficult debugging tools, and it's just plain ugly.
- Here are some HTML5 game engines that are actually recommendable because they have minimal deal breakers.
- PlayN - cross-platform engine, uses Java, optimized for Android browsers, free and open-source, uses Eclipse IDE. Gotchas - buggy Flash and iOS backend, installation and setup is a challenge, no more support from Google, GWT overhead, has about twice as many lines of code. Recommended for Java developers targeting Android.
- CreateJS - deep Adobe CS integration, supports Javascript/TypeScript/Haxe, free, uses MIT license, done by Grant Skinner (Flash expert), toolchain (Adobe Flash CS6, Zoe Spritesheet Exporter, EasleJS). Gotchas - big spritesheets, not multiplatform, no SWF export, relies on Flash's DisplayList metaphor which adds overhead. Recommended for Flash developers.
- ImpactJS - features Canvas/WebAudio/Physics, easy to put into native wrappers, uses Javascript, $100, lots of indie games but no professional games yet, has Weltmeister (visual editor), supports Ejecta (iOS wrapper). Gotchas - large animation files, limited screensize support, not open sourced. Recommended for indie developers who want to make side-scrolling platformers.
- Construct 2 - best visual editor, $390, lots of indie games, requires no programming knowledge. Gotchas - lack of fine control, hard to optimize, large animation files. Recommended for beginners with no programming experience.
- Cocos2D HTML5 - familiar API to Cocos2D, high reach (HTML5, iOS, Android), uses Javascript/Haxe, free, supported by Zynga, toolchain inludes CocosBuilder/PhysicsEditor and other Cocos2D pipeline tools. Gotchas - still early, very small community (but will grow very fast), large animation files. Recommended for Cocos2D developers.
- Spaceport.io - supports vector graphics, features over-the-air updates, reach (native iOS and Android), supports Actionscript 3, a few real games developed using this engine, toolchain (Adobe Flash CS6, FlashBuilder, FlashDevelop), very similar to Adobe AIR. Gotchas - only native support, no HTML5 browser support. Recommended for Flash and Air developers.
- Haxe - cross-platform SDK, reach includes HTML5/Flash/iOS/Android/Win8, free, language is ECMAScript (similar to AS3), the only engine that's truly multiplatform, toolchain includes IntelliJ/FlashDevelop/FDT/SublimeText, integrates Adobe CS6, uses Stencyl visual editor, can create cutscenes using Flash-like timelines, backed by Blackberry.
- Honorable mentions (good engines, but has a few deal breakers) - Tresensa, Ludei CAAT, CocoonJS, Playcraft, Turbulenz, PixilJS, LimeJS.
Aron Sagon from EA also gave a talk about games as service. I'm not really sure what the point of his talk was... outside of complaining how difficult it is to make them.
- Aron is a chief engineer who worked on Pogo, Sims 3, Star Wars: The Old Republic, and most recently, Simpsons: Tapped Out.
- He compares the old business model (sell shiny disks) to the new model (sell a service). The service model can be broken down into three steps: identify the user, collect money, and then deliver the experience.
- In the service model, you have to keep track of the users and what they've bought, then make sure you deliver the service to them. In the traditional model, you didn't have to track users. Once they've bought your product, your relationship with the customer is pretty much over.
- It's very, very hard to track your users. Users don't want to register new accounts and even if they do, they are unlikely to remember their account info. Even with iTunes, Apple does not provide information about who is purchasing or using your app. There is a lot of extra overhead to put in analytic and tracking data into your games.
- Building service games is very difficult. Before, you would develop the game and then ship it. Now, you often ship the game and then develop it. Development timelines can be as long as 5 years. And because of the massive volume of players, small mistakes can become big deals.
- Making a pretty game is important, making a fun game is important... but there is much, much more that goes into game development. You need to integrate monetization, virality, engineer databases, etc.
No comments:
Post a Comment