Showing posts with label html5. Show all posts
Showing posts with label html5. Show all posts

Tuesday, April 9, 2013

GDC2013 - WiiU Application Development with HTML5 and Javascript


  • Nintendo announces the Nintendo Web Framework (NWF), a framework that allows you to create applications for the WiiU with HTML5 and Javascript.
  • The WiiU offers dual screens (your tv and the gamepad), an internet browser, touchscreen, gyroscope, accelerometer, and support for Wii remote controllers.
  • WiiU also launched with web service apps such as Hulu Plus, Amazon, and Youtube.
  • Wii Street U is a new app by Google created using the NWF.
  • The NWF offers a great way to prototype traditional native games.
  • "Gunman Clive" is a 2D platformer game that was released on 3DS and in one month, outsold both its iOS and Android versions. There is marketing value in Nintendo hardware and people demand better controls that the WiiU can offer.
  • NWF runs on a Windows PC and is based on the Webkit framework. With Javascript extensions, it allows use of the touchscreen, gyroscope, accelerometer, and any of the WiiU-supported controls. It also supports save data, file I/O, software keyboards, video playback, and access to the Miiverse.
  • You can use standard HTML5 libraries like jQuery in your applications. The NWF Dashboard interfaces between your code and the WiiU hardwre. It will convert your gamepad touch inputs to mouse clicks. The Dashboard also comes with a web debugger/inspector.
  • NWF uses a fast Javascript virtual machine, GPA accelerated graphics, and a great bitmap/sprite renderer. The hardware can run GUI Mark 3 (a benchmarking program) at 60 FPS even when you increase the number of sprites drawn by 10.
  • The logo of NWF contains an image of a bamboo because the codename of the project was Bamboo. A bamboo's roots sprout from the ground very quickly, but it has a solid framework to support its fast growth. Likewise, NWF is a solid framework that supports quick development growth.
  • NWF is free to use after getting a WiiU devkit and they have a special introductory program for new developers.
  • Their business policy
    • No concept approval
    • Price and release date are independently set by developers
    • Distribution will be following industry standard models
  • ​In the future, NWF will also support Unity. Unity for WiiU will be distributed for free to all WiiU developers.

Monday, April 8, 2013

​​The Future of Mobile Gaming: A Conversation with Nickelodeon and EA

Nate Altschul from Nickelodeon talked about a bunch of HTML5 game engines and what he recommends.
  • 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.