Games, apps and runtimes come to Native Client
Friday, December 09, 2011
Labels: native client
Updated on December 14th with the video of the event.
Since we launched Native Client late last summer, our team has been working hard to make the technology more useful to developers. Yesterday at an event held at Google we shared the progress we’ve made towards this goal and showcased work from some of the early adopters of the technology, including Square Enix, Unity Technologies, and Bungie.
One code base for all OSs
In September, we started supporting a set of core Pepper interfaces, suited for 2D graphics, audio, and compute-intensive applications. Since that release, we’ve shipped additional APIs and capabilities, providing native code with more of the capabilities available from JavaScript. These include hardware-accelerated 3D graphics via OpenGL ES 2.0, a mouse lock API, a full-screen API, and much more. One example of the kind of experience Native Client can currently support is Bastion, an award-winning role-playing game from Supergiant Games. Previously limited to Microsoft Windows® and Xbox® systems, the Native Client port of Bastion allows Supergiant to reach users on all popular desktop operating systems, with the safety and simplicity of the web.
Easy porting of previous work
If you have existing code bases in C, C++, or C#, Native Client now allows you to port your existing apps to the web while maintaining just one code base. This was particularly appealing to Spacetime Studios. They ported their multiplayer online game Star Legends to the web in less than two weeks from an existing code base of more than half a million lines of code. The side benefit of being able to maintain their existing development and testing infrastructure further accelerated their delivery of a shipping title.
More choices of programming languages
The community is actively involved in Native Client, porting some of the most popular application middleware. Ports include Unity and Moai game engines, programming language environments Mono and Lua, audio middleware such as fmod and Wwise, as well as the Bullet physics engine. These Native Client ports make the web more accessible to hundreds of thousands of application developers. At the event, we showcased upcoming applications from Heartwood, Silvertree, Exit Strategy, and Dedalord, who used those tools to bring their apps to the web with very little effort. We’ll continue to work with the community to get even more languages and middleware systems ported to Native Client.
We recognize that building a Native Client app is only the start of a successful app. That’s why we’ve enabled distribution of Native Client-based apps via the Chrome Web Store. The Chrome Web Store gives developers a simple, effective strategy to reach over 200 million active users of Google Chrome.
If all this sounds exciting, please visit our new documentation site at gonacl.com. There you’ll find a growing collection of tutorials, examples, videos, reference documentation, and much more.
Questions or suggestions? Join us in the discussion forums. We look forward to seeing some great new apps from Native Client developers.

6 comments:
erlend_sh said...
What about a port to Java? I'm sure a lot of jMonkeyEngine developers would be very happy to experiment with Native Client for web deployment as opposed to messing about with Applets and Webstarts.
And where does PlayN fit into this?
December 9, 2011 1:27 PM
Mike said...
Um, "gonacl"? There's a man who's really got confidence in kerning algorithms...
December 9, 2011 2:29 PM
Dr. Insano said...
How is this different from the approach that Microsoft did with ActiveX? I mean, not from a tech point of view, but from the fact that only one vendor implements it.
I really hope that this tech does not succeed, since it could bring the web back to the 'best viewed in browser X' era.
December 9, 2011 3:37 PM
Bob Hazard said...
Dr: It's open source
December 10, 2011 12:16 AM
Darin Fisher said...
Dr:
ActiveX creates a dependency on Windows operating system APIs.
NaCl creates a dependency on the Pepper API.
The Pepper API is a relatively small API. It is minuscule compared to the Windows operating system APIs, and Pepper is explicitly designed for portability. Pepper is also built on the same technology that powers HTML5 support.
It is very possible for other browsers to support NaCl.
One could even write an ActiveX plugin to support NaCl in IE, or a NPAPI plugin to support NaCl in Firefox/Opera/Safari. In contrast, it is virtually impossible for browsers on non-Windows operating systems to properly support ActiveX.
December 10, 2011 9:58 PM
s3051024 said...
Why no Java or Other JVM Language
December 12, 2011 9:39 PM
Post a Comment