Cross posted at the Google Code blog

This post almost wasn’t written.

I’ve been a bit too busy playing and testing new browser-based games such as Monster Dash, Angry Birds, and the newly released SONAR. Bigger and better games are coming to the browser rapidly (and just wait until Native Client with 3D lands in Chrome), and it’s hard to keep up with the technology and scene. So what better way to bring everyone together to share stories and keep up to date than to hold a conference dedicated to HTML5 game development?

New Game, the first North American conference for HTML5 game developers, is now open for registration. You are invited to join hundreds of HTML5 game developers for two days of technical sessions and case studies from developers and publishers who brought their games to the open web platform. The event will take place November 1-2, 2011 at the beautiful Yerba Buena Center for the Arts in San Francisco, CA.

This year, New Game looks at what is possible in the browser today. Sessions will focus on the technologies that have elevated the browser-based gaming experience, such as WebGL, Canvas, and JavaScript performance techniques. In addition, the conference will feature sessions exploring and analyzing lessons-learned from recent HTML5 game launches.

New Game is honored to have Rich Hilleman, EA’s Chief Creative Officer, keynote the event. The schedule also includes sessions from Mozilla, Spil, Opera, Google, Bocoup, GameSalad, Moblyng, and others. After the first day, we’ll network with our colleagues and share high scores at the New Game party, open to all registered attendees.

For more information on New Game, including session and speaker details, please visit www.newgameconf.com and follow @newgameconf for the latest news. Google, the premier sponsor, and conference director Bocoup invite you to take advantage of early bird registration pricing, available for a limited time.

The future of gaming is in your browser, so I’ll see you at New Game! Now if you’ll excuse me, it’s time to get back to my SONAR tab.

Posted by Seth Ladd, Developer Advocate

Wouldn’t it be great if you could create web apps using your existing C and C++ code? Native Client lets you do just that, and it is now enabled for Chrome Web Store apps in Google Chrome’s beta channel.

Native Client apps live on the web platform, so you don’t need to create separate versions of your app for each operating system. Rather than relying on OS-specific APIs, Native Client apps use Pepper, a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. This means that once you’ve ported your code to Native Client, it will work across different operating systems, and you only need to maintain one code base.

Today Native Client supports the Pepper APIs for 2D graphics, stereo audio, URL fetching, sandboxed local file access (File API), and asynchronous message passing to and from JavaScript. In future releases we will be adding support for hardware accelerated 3D graphics (OpenGL ES 2.0), fullscreen mode, networking (WebSockets and peer-to-peer connections), and much more. As new capabilities are added to HTML5 and Pepper, they will become available to Native Client.

This functionality does not come at the expense of security. To ensure that Native Client is as safe as JavaScript, Native Client code is isolated from the operating system by two nested security sandboxes: the Native Client sandbox and the Chrome sandbox. And unlike NPAPI plugins or ActiveX controls, Native Client apps do not have access to the underlying OS APIs.

We encourage you to start developing apps with Native Client. You can download the SDK and find tutorials, examples, API documentation, and our FAQ on the Native Client site. Once version 14 of Chrome hits stable channel, you’ll be able to upload your Native Client apps to the Chrome Web Store, where you can reach Chrome’s 160 million users.

The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. Until then the Chrome Web Store will be the only distribution channel for Native Client apps. This will help us ensure that all Native Client apps are updated to PNaCl when it’s ready – and in the meantime avoid the spread of instruction set architecture dependent apps on the web. We’ll be providing updates on the progress of PNaCl on this blog.

Posted by Christian Stefansen, Product Manager

In today’s browser ecosystem, web apps are completely disconnected or require the use of complicated APIs in order to make use of a third-party service, e.g., posting a comment to Twitter from your custom publishing domain. What if we could give sites the ability to leverage these services without any knowledge of the chosen service, except that it provides some set of predefined functionality?

Android OS addresses this problem with Intents, a facility for late run-time binding between components in the same or different applications. In the Intents system, the client application requests a generic action, e.g. share, and specifies the data to pass to the selected service application. The user is given a list of applications which have registered that they can handle the requested intent. The user-selected application is created in a new context and passed the data sent from the client, the format of which is predefined for each specific intent type.

We are hard at work designing an analogous system for the web: Web Intents. This web platform API will provide the same benefits of Android Intents, but better suited for web applications. When designing the system, we have first and foremost been interested in creating a simple, easy-to-use API. With Web Intents, you will be able to connect your web app to a service with as little as two lines of code! Chrome will perform the heavy lifting for you. As with Android, Web Intents documents an initial set of intent actions (edit, view, share, etc.) that likely cover the majority of use cases on the web today; however, as the web grows and sites provide more functionality, new intent actions will be added by services that document these intents, some more popular than others. To foster development and use of intents, we plan to create a site to browse existing intents and add new intents.

Consider an online photo storage site run by a cash-strapped startup: the developers don’t have the resources to add image editing abilities to their app, but they feel the site won’t be a hit without it. The Web Intent system will make it easy for them to offer this with little effort.

var intent = new Intent(Intent.EDIT, ‘image/png’, getImageDataURI());
window.navigator.startActivity(intent, loadEditedImage);

// This callback will be called when the service replies with the edited
// image data.
function loadEditedImage(data) {
var image = document.getElementById(‘image’);
setImageData(image, data);
}

When the user visits her favorite memegen service, the site will request registration to handle the EDIT intent for files of type ‘image/*’ using the following declaration:


<intent
action=”http://webintents.org/edit”
type=”image/*”
/>

When the user initiates the EDIT action, this service is presented to the user, along with other registered image editors. Once the user selects Meme Generator, the referenced site is opened in a new context and is able to load the image data from the intent payload:

var intent = window.intent;
memeImg.src = intent.data;

memegenForm. {
// Transform the image - meme it.
addMemeTaglines(memeImg, memeTopText, memeBottomText);

// Send the generated meme back to the client.
intent.postResult(getImageData(memeImg));
};

Once postResult() is called, the Meme Generator context is closed and the output data is sent back to the client via the callback passed to startActivity().

Mozilla is also actively exploring this problem space. In fact we’re working closely with Mozilla engineers to unify our two proposals into one simple, useful API. Visit the examples page to try out the feature in any current browser. To explore using the API in your site, check out out the JavaScript shim, which provides an implementation of the API for browsers that have not implemented this feature. We are rapidly prototyping this feature, so check back soon for an announcement when Web Intents is available behind a flag in Chrome.

Posted by James Hawkins, Software Engineer

Posted by Takeshi Yoshino, Software Engineer

Since Google I/O, we’ve been working hard to make the Chrome Web Store available to more users around the world as well as to provide additional monetization opportunities for developers. Today, we're happy to share progress in both of these areas.

We recently launched the much awaited In App Payments API in the US. This API provides a simple and effective way to monetize your apps in the Chrome Web Store, allowing you to complete transactions with buyers from 140 countries. Integration is simple - all you need is to do is to insert a few lines of code. An even more exciting feature of the API is the 5% flat transaction fee pricing. To learn more about In-App Payments, check out our docs and a sample app complete with source code or watch our short video. We look forward to expanding this service to additional developer locations as quickly as possible.


With our in-store payments, developers in Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Hong Kong, Italy, Japan, Netherlands, New Zealand, Norway, Portugal, Singapore, Spain, Sweden, Switzerland, United Kingdom can now complete merchant account sign up and start adding their paid apps to the Chrome Web Store. Paid apps will be published to international users later this year. In the meantime, you can localize your app listing to make it accessible to more people and be eligible for promotion in local store fronts.

We’ve also added the ability to target or exclude specific markets. In this launch, Chrome Web Store developers can publish their apps to the following regions: Argentina, Australia, Austria (new), Belgium (new), Brazil, Canada, Czech Republic (new), Denmark (new), Finland (new), France, Germany, Hong Kong (new), India, Indonesia (new), Israel (new), Italy, Japan, Mexico, Netherlands, New Zealand (new), Norway (new), Philippines (new), Poland, Portugal, Russia (new), Singapore (new), Spain, Sweden (new), Switzerland (new), United Kingdom and United States. Our users will only see apps that were published for their market. We also added support for our various featured lists to be targeted by market, allowing users to see the best apps for their market.

If you have additional questions, please join our developer discussion group.

Posted by Elvin Lee, Software Engineer