Introducing the CocoonJS Command Line interface and webview+ plugin for cordova

The main improvement of CocoonJS 2 was providing cordova compatibility to Ludei’s cloud compiler. With the cordova compiler, we also released the webview+, a chromium-based webview for android 4 and higher. You can use it directly from our cloud compiler.

The webview+ provides a chromium-based environment for your HTML5 hybrid apps. It will deliver same look’n feel across every android device on the market. As we promised, Android fragmentation is over!

The great news is that we want to share this development with the HTML5 and cordova community, so we are doing a public release of the main tools of our cloud compiler: the webview+ plugin for cordova and CocoonJS Command Line Interface.

The webview+ plugin for cordova enables your cordova-based apps to include a webview+ to run as the execution environment for your app. This plugin can be included in your current cordova android projects. What does this plugin provide?

  • Implements the cordova plugin API, so it interacts seamlessly with any cordova app
  • Webview+ provides remote debug for any cordova project. JS instrumentalization and live code changes, dynamic breakpoints, and all the power of the chrome developer tools
  • WebGL support for any android device running android 4 and higher.

Interested? You can get more info here. The project is hosted in our github here.

Other contribution we want to share with the community is the CocoonJS Command Line Interface. Standing on the shoulder of giants (cordova-cli), we’ve developed a Command Line Tool that eases the process of dealing with webview+ in Cordova projects. But, why another fork from cordova? Why another open source command line interface?

  1. Currently, installing webview+ manually is a bit tricky and the cocoonjs-cli eases the process, apart from reporting more meaningful error logs
  2. Cocoonjs-cli is cordova compliant, so the only difference you’ll notice is the command name, moving from cordova to cocoonjs
  3. The cocoonjs-cli also will be one of the remote interfaces for the cloud compiler. The cloud compiler enpoints are currently under development. We want to empower our users with tools that eases the process of managing their cloud projects
  4. Because we use extensively open source software and it’s time to give this love back to the community

Get more info abut the Cocoonjs-cli here. The source code is hosted in our github.

We encourage every HTML5 developer to download it, install, use, test and find bugs. We really would like to create a big community around these new projects.

Hail to open source!

 

Web starter kit running on webview+

Last week Google released their last creation to improve the web development: the web starter kit. This project is a set of tools, good practices and tutorials to create good web experiences. You can get more info about the web starter kit here.

At Ludei we love every project that helps the community of developers to create awesome HTML5 apps. We’ve tested internally, and we’re passionate on this set of tools. Unfortunately, they’re not supporting older version of Android’s webview.

Ludei’s mission is to help HTML5 community to create awesome apps and games. Fortunately, some time ago, we released the webview+, a custom webview based on the chromium project. Webview+ is available from our cloud compiler for any android  device running version 4 and higher.

We have already tested it in our devices using CocoonJS launcher with the webview+. The result can’t be better.

web

As you see, the web starter kit is fully supported on webview+. Yay! ^_^

We encourage every web app lover to use it, and adopt it for their HTML5 apps, since we fully support this new toolset.

CocoonJS 2.0.1.

Good news! The new version of CocoonJS is live! This time the version number is 2.0.1 and it comes with some very important bug fixes and improvements.

Improvements on Canvas+

  • Canvas+ now correctly handles HTML5/Web export from Construct 2. Get more info here.
  • Makes “text/plain;charset=UTF-8” the default content-type
  • Allows XHR responses to be saved to disk a new cocoonSetOutputFile extension
  • Page pageLoaded / pageFailed are correctly called now.
  • Fixed Audio System deadlock when alcOpenDevice fails.
  • Correct font-face CSS style handling in Canvas+. Font file download is now possible. Get more info here.
  • … and more!

Improvements on WebView+

  • Added check to avoid null pointer exceptions when destroying the webview
  • Implemented webView setNetworkAvailable method, which triggers ‘online’ event on the JavaScript side
  • Fixed viewport size problem which happened in some devices
  • Fixed some missing resources bugs

Cloud Compiler

  • Added support for Cordova 3.3 and 3.4.

Check out the full changelog for the CocoonJS 2.0.1 release. Remember your feedback is valuable to us so we can find bugs and determine what other improvements need to be made. Enjoy CocoonJS 2.0.1! 😉

CocoonJS and Construct2’s “Great HTML5 Gaming Performance Test: 2014 edition”

Scirra, the company behind Construct2, a great HTML5 game authoring framework, released “The Great HTML5 Gaming Performance Test: 2014 edition” weeks ago. In this test, they used a Construct2 based game demo and executed it in numerous environments. Surprisingly (and we want to think that by mistake), they did not include CocoonJS’ Canvas+ in the comparison, but to help Scirra provide as much information as possible, and to be fair to the Construct2 developer community that has been actively using CocoonJS, we have used the same demo in almost all of the same devices (and some interesting additional one like an iPad1 with iOS 5!). These are the results:

Device Canvas+ canvas2d Canvas+ webgl Chrome34 webgl Firefox webgl Safari 7 canvas2d Ejecta webgl
Nexus 4 58 60  59 58 N/A N/A
Nexus 7 52 60 59 51 N/A N/A
SGS3 58 59 58 58 N/A N/A
iPad 2 53 55 N/A N/A 46 55
iPad 1 20 35 N/A N/A N/A N/A
iPhone 4S 32 51  N/A N/A 40 51
iPhone 5 60 60 N/A N/A 60 N/A
Kindle 44 58  N/A N/A N/A N/A

As you can see Canvas+ is really efficient for both 2d and webgl contexts in all of the devices that were tested (even on an iPad1!!!).

It is also important to remember that Chrome, Firefox and Safari are not technologies to create native apps for iOS or Android. If someone wants to run a game on a mobile browser, this list gives a good glimps of what to expect, but not all of the final users/players have these browsers and their latest versions installed (specially on Android) and most of these technologies won’t be an option to create native apps for existing mobile markets. Moreover, Safari has Nitro JIT so the comparison is also biased. Bottom line is that CocoonJS is still the only technology that allows webgl native app deployment for both iOS and Android using the same execution environment, with no fragmentation and with an easy one click final deployment.

The good news is that the new CocoonJS release 2.0.1 is soon to be out and with it anyone will be able test these results on his/her own easily by installing the CocoonJS Launcher App for iOS and/or Android. This new version of CocoonJS will execute any Construct2 project exported for the web out of the box, so this perf test will also work just by pointing to the following URL (either typing it or using the provided QRCode for your convenience):

http://www.scirra.com/demos/c2/sbperftest/

ScirraPerfTestURL

Happy perf-testing! 😉

WebGL on iOS 8 Safari and WebView!

The long wait has ended: we can confirm that webgl is present by default on iOS 8 (and MacOSX) both in Safari and the system webview. We have downloaded and installed iOS 8 beta on an iPad2 and thanks to the CocoonJS Launcher App, that offers access to both the System WebView and to Canvas+, we have been able to confirm that WebGL support is for both mobile Safari and the webview.

IMG_0010

The CocoonJS Launcher App using the iOS 8 WebView running a WebGL demo @38FPS.

IMG_0008

 The CocoonJS Launcher App on iOS 8 using Canvas+ running a WebGL demo @ 60FPS.

These are the results of WebGL support in both Safari and the system webview in iOS 8 on the same iPad2 (website: BrowserLeaks.com)

Safari WebView
iOS 8 Safari WebGL support specs iOS 8 WebView WebGL support specs

CocoonJS has been actively supporting WebGL for more than a year now and developers are able to publish native apps/games with WebGL for both iOS 5.0+ and Android 2.3+ TODAY!. Download the CocoonJS Launcher App from iTunesGooglePlay or Amazon and check it out for yourself right now. No need to wait for iOS 8!

This move from Apple is definitively great news for the whole web based game and app development community (and the web in general).

All hail WebGL! 😉

iBasket HTML5

The past few weeks have been loaded with new developments at Ludei. In addition to the new release of CocoonJS, our client virtual machine, we announced the delivery of our new HTML5 version of iBasket. iBasket, originally a native game, has been completely re-written in HTML5 and JavaScript. The game has over 15M historical downloads.

This new version, launched simultaneously for the 1st time by any company on iTunes, Google Play, Facebook, Desktop Web Browsers, Chrome Store and Amazon (additional markets coming soon), incorporates many of the advantages of our games development platform. Some of the capabilities include our game acceleration technology, hardware accelerated physics, advertising, social features, in-app purchases and analytics, providing the Same as Native gaming experience.

Here’s a new video showcasing what we’ve accomplished with the new version and the platform.

Making HTML5 Games Work.

Yee-Haw!!!!

Read about iBasket on TechCrunch.

CocoonJS Launcher App Release (2012/06/29)

Ludei has just uploaded a new version of the CocoonJS Launcher App for Android in Google Play. Below is the list of new features added and bugs corrected in this new version:

CocoonJS new features

    • WebView support: This is one of the major improvements in CocoonJS for this release. Until now, CocoonJS has been a JavaScript interpreter that was highly optimized for Canvas rendering. With a native communication with the JavaScript virtual machine, we’re able to accelerate all the rendering primitives from HTML5 using OpenGLES. In this version we add the support for a webview in the sense that you can execute two different JavaScript contexts, one in a webview and another inside CocoonJS while both inter-communicating with each other. With this feature, developers will be able to have full DOM support in the webview to solve those UI related things like menus, on screen controls, showing full web pages, etc. On the other hand, your game can still run inside CocoonJS hardware accelerated environment at full speed while still getting commands from a webview and viceversa.

 

 

    • Camera support: Ludei always wants to provide full access to the same feature set in all the platforms that CocoonJS supports. The camera extension has been developed several months ago but Android has always delayed the launch of it because having full support for it in their devices is not an easy task (especially if the APIs change with the launch of new OS versions). But finally, you can access camera capturing from your JavaScript using this CocoonJS extension.

 

 

    • True type fonts: CocoonJS now can render text using a true type font file that you can provide inside a folder called “fonts” among your assets.

 

    • HTML file parser: CocoonJS now can read an HTML file and parse the script tags to either load .js files or evaluate inline javascript code. The convention is to have an “index.html” or “CocoonJS.html” file in the root directory of your zip file to load and parse this HTML file inside the native hardware accelerated environment. If you have a file called “WebView.html”, this file will be loaded and parsed using the webview.

 

CocoonJS Launcher App new features in Android

    • Execute your zip files from the SD card: This is a very cool feature if you want to show your applications to anyone without having to be connected to your computer or to a server. This CocoonJS Launcher App release does not erase the possibility of accessing your app zip files using an URL but simply allows you with the option to connect your device to your computer so you can upload as many .zip files as you want to the root folder of your SD card and the CocoonJS Launcher App will look for them and present them to you so you can execute them directly.

 

 

    • Console log access button: Everytime you execute the demos or your applications, the CocoonJS Launcher App shows the frames per second on the left top corner. What a lot of developers don’t know is that this text can be tapped and gives access to a console where javascript messages and system messages are shown. This text has been changed to a button now so it’s more obvious to the user. We really hope it will help you debug your applications and check what the problems could be.

 

    • Off-line mode: In this release, once you enter a registration code it will be checked against the server to verify that is valid. This code is securely saved and it will be used the next time without checking the server again so no connection will be needed. Anyway, the launcher allows you to enter a different code that will also be checked against the server. The last valid code will be stored only. This feature in addition to the new feature of executing the zip files you copy to the SD card, allows you to show your creations without having to be connected online.

 

  • New demos: Because this release includes cool new features, new demos have been added to the demo list to show the webview integration and the camera support. We hope you will like them!

Solved bugs

  • Websockets: There was a internal thread lock that has been solved. Some event callbacks did not receive the correct event parameters.
  • Touch Input: There were some problems with the touch input interface that have been solved in this version.
  • Render improvements: Some rendering problems have been solved, mainly related to composite operations and creating complex paths.
  • Some demo improvements: Some of the demos had some minor issues related to touch input events and sound reproduction that have been solved by modifying the JavaScript code.

The CocoonJS Launcher App: A simple tutorial

Updated information on the wiki

In order to let all the JavaScript HTML5 developers out there try our CocoonJS technology, we have developed a mobile application that allows you to check how smoothly your game can run on iOS and Android devices without major code changes. Although the application is simple to use (you can check it’s usage in this video), it might be useful to show how it is used and what the minor modifications you have to make in order to make your game run on CocoonJS.

Let’s start by executing the app. After a splash of Ludei’s logo, you will see the main menu.

You have two options in the menu: DEMOS and YOUR APP.

DEMOS

The CocoonJS Launcher app provides a complete list of simple demos that shows the possibilities of CocoonJS. We provide the list and full source code of these demos here. As you will be able to see, CocoonJS does not use any proprietary API-s nor any game engine by default. It is just a technology that accelerates standard JavaScript and HTML5 Canvas based games/apps.

Although some of the demos use our CAAT game engine (an open source project that can be found here), this complex project uses plain JavaScript and HTML5 Canvas, so it runs inside CocoonJS. You can play around with the demos, execute them, check the source code, modify them and retry, etc. Once a demo is selected to be launched, it’s code is downloaded and executed showing how CocoonJS performs.

The list of the demos will be updated from time to time (the demos are downloaded from our servers). We are working on providing new cool demos soon so stay tuned! 😉

Before explaining the YOUR APP option, let’s clarify some important matters.

Providing the real/final experience

One of the first “issues” that users experience when using the CocoonJS Launcher is that once a demo is launched (or once your app is launched), there is no way of getting back to the application menus. Instead, the easiest way of getting back to the CocoonJS Launcher app menu is to kill the application and then to relaunch it. Even though this behavior might seem to be annoying there is a reason for it: We wanted to offer the final user the same technology and experience that will run his/her final application. Once you try CocoonJS using the CocoonJS Launcher app and decided to ship your iOS or Android application using it, we will provide a final application that has nothing to do with the CocoonJS Launcher and it’s menus. You will get a standalone app (two apps to be true, one for iOS and one for Android) that will run as a native application. In native applications the options that you will face are pausing your app or killing it so that is exactly what we offer inside our launcher app too. We didn’t want to tweak the technology to behave differently for the launcher and for your app. Anyway, we understand that this behavior can be a little bit annoying and we will try to solve it somehow in future versions of the CocoonJS Launcher App.

In-app debugging tool

Once a demo or your app is running, the CocoonJS Launcher app provides the possibility of accessing a simple but useful tool for debugging. When it is enabled, you will be able to see the frames per second (FPS) that your game logic is running at. Apart of being a useful information, the FPS text can also be pressed to access the in-app debugging tool that shows a log of all the messages shown by either CocoonJS itself or by the JavaScript code of the application that is running (by using the text logging Console object’s methods: console.log, console.info, console.debug, console.warn, console.error).

Configuration options

The CocoonJS Launcher app provides some customization options by using the configuration button . The options are (please note that these options may vary depending on if you are trying to launch a demo or your application):

  • Enable/Disable the in-app debugging tool: It allows you to specify if the in-app debugging tool will be active or not while executing the demo or app.
  • Specify the position of the access to the in-app debugging tool: It can be useful to specify where the FPS text will be shown so it does not conflict with the application layout and manipulation. There are 4 different options:
    1. Top-Left
    2. Top-Right
    3. Bottom-Left
    4. Bottom-Right.
  • Orientation mode: It specifies the orientation that the application will be set to. There are 3 options:
    1. Portrait
    2. Landscape
    3. Both

YOUR APP

This option allows you to specify a ZIP file with your application JavaScript code and assets so CocoonJS can execute it. In order to be able to execute you app you need to register in our cloud based system. The registration does not need many information (mainly an email) and it will allow you to access future services around CocoonJS such as our soon to be released cloud based compilation system and more. The registration provides you with a code that you can enter inside the input field. The application will validate this code and it will allow you to specify the application you want to execute.

The initial form is:

The REGISTER button can be confusing. It redirects you to the registration form where you can obtain the validation code. It will be sent via email to you. All this process can be performed in the mobile device so you can register anywhere and don’t really need to switch to your desktop system.

Once you have your registration code, you can introduce it inside the given text edit field. To make the application to verify the code you must press DONE or “INTRO” in your device on screen keyboard. If the code is incorrect, a red spaceship icon  will appear. If the code is correct, a green spaceship icon  will appear.

   

Once a correct code is entered and verified, you can introduce a URL where your application should be.

Adapting your code to CocoonJS

We have developed a complete tutorial that explains how we modified the Onslaught Defense game to make it run in CocoonJS. We have also created a wiki that will be updated regularly to list all the features that CocoonJS supports. Although you might find all the information your need in these links, let’s review the most basic steps to modify your code in order to make it work inside CocoonJS:

  1. CocoonJS does not support DOM so no HTML file is needed (there is no problem if you still include it, the current version of CocoonJS does not use it). As the HTML file is not parsed, the Canvas object must be created from JavaScript. To do so, you have multiple options:
    1. Tell the document object to create the Canvas object.

      var canvas = document.createElement("canvas");

    2. Once the object is created, it has to be added to the document, usually by adding it to the document body.

      document.body.appendChild(canvas);

    3. Remember that you can specify the size of the canvas with the width and height properties.

      canvas.width = 1024;
      canvas.height = 768;

  2. The current version of CocoonJS prefers to read all the JavaScript code in just one .js file. If you are using fancy module loader APIs, you can just disable them.
  3. Create a zip file with .js file and all the assets (image files, audio files, etc.). Although the current version of CocoonJS allows remote asset loading, it makes more sense to reference all the resources locally.

And that’s pretty much it. The final .zip file can be uploaded to a web server and the URL to it would be the URL to be entered to the edit text field provided in the CocoonJS Launcher App. We hope it works well for testing your project. If not, please, do not hesitate contacting us using our support web form specifying the “Developers support” area.

Interview with Appoint Solutions

Appoint Solutions company, founded by Rob and Bert Boerman, is about to launch MonsterMove HTML5 game using our technology. We sent some questions to them and  the brothers talk about their experiences in launching complex applications.

How did you get started?

After closing some other projects, we started working on a mobile online multiplayer game in November 2011. Until that time most experts agreed that HTML5 was only usable for simple turn-based board games without much movement. We wanted to prove that it was feasible to create a mobile game with fast moving graphics, realtime multiplayer gameplay and interaction, and multichannel sound, all using HTML5 techniques. At the same time, the game should be deployed to iOS, Android and Facebook with a single code-base. Not an easy task, but hey, we do like a challenge.

What approach did you take?

To solve the many technical challenges we tried everything from game engines (Custom, ImpactJS, CAAT), server possibilities and deployment strategies. The almost weekly pivots made us a bit nervous (in fact, it was driving Bert crazy) but we decided to continue to anyway. The deployment was the most challenging. We already used PhoneGap for deployment to different app stores. PhoneGap solved some multichannel sound issues in standard HTML5, but to be honest, the solution felt uncomfortable. We also had a number of challenges that were left unsolved:

– Canvas rendering performance was below par. Even after extensive optimization we only achieved around 10 frames per second when we had many movements on screen. For 1990 this would have been great, but for 2012 perhaps not!

– Websockets were available, but because the rendering was so intensive on the browser and therefore CPU, packets were being delayed. This caused the realtime game functionality to be broken (we require around 20 packets/second minimum server rate).

– Sound was working, but hacked-in at best. We needed to create a separate sound player for browser deployment and a hook into PhoneGap for mobile.

– Ad-network integration in a HTML5 based game was buggy at best.

That meant: Back to the drawing board…

So, What did you do next?

We first tried appMobi’s services and tools, both commercial and open-source. AppMobi’s game developer tools solve a number of problems like rendering speed and multichannel sound (and from what I hear add integration as well). The Websockets however still work from the browser, as well as user input. Therefore as a developer you have 2 separated environments that have to communicate with eachother though serialized calls (EG. directCanvas.execute(“movePointer(“+x+”,”+y+”);”) ). That communication channel is a nasty bottleneck and is not usable for anything that requires fast updates. Aside from that, the game has to be separated into 2 environments for mobile, breaking our write-once-deploy-everywhere requirement.

So you decided to give CocoonJS a spin?

Yes. Through our CAAT experiences I (RB) got into contact with Ibon Tolosana and Ludei. The description of CocoonJS on the site, a seamless environment that runs HTML5 games without any changes, sounded too good to be true. Ibon emphasized however that that was exactly what was being created and told me about some other solutions that would be accompanied by it. He then offered me the chance to beta-test CocoonJS on our own game sources which I happily accepted. The current version of CocoonJS solves all our problems for us. In the most extreme cases we are still getting around 50 frames per second rendering speeds, multichannel sound and Websockets without delay. It also gives us easy ad-network integration and more. The best thing about that is that it hardly requires any work to make all this work in CocoonJS. Almost all HTML5 functionalities like sound, canvas operations, local storage and sockets are supported transparently. We can’t wait to launch our game ‘MonsterMove’ and start work on the next project using CAAT and CocoonJS!

About the company:

 

Appoint Solutions SARL is based out of Luxembourg due to it’s favorable VAT and IP legislation. The company was formally launched last year by the twin brothers Rob and Bert Boerman. The brothers share their passion for customer excellence and the use of smart technical solutions to solve complex client issues.

Rob has 15 years of experience in web development. He worked for 10 years as CTO and COO of a dutch company focused on large-scale online customer satisfaction research. In this period he designed and co-developed a realtime, open-source based, analytics database and tools for the hundreds of thousands of surveys handled each year. Bert has worked as an executive in a large banking corporation for 13 years. During this time he has set up 5 different business lines in Private banking, Corporate Banking and Institutional services.

Appoint Solutions currently creates custom applications and provides technical consultancy services for a number of clients, including other software houses and an international banking group. Besides that, the company also works on their our own projects in the field of game development and mobile applications.

The main expertise of Appoint Solutions is on the development of mobile and web-based-desktop applications using client- and serverside javascript and HTML5/CSS3 techniques.

Introducing CocoonJS

Around a year ago, our development team started to get curious about JavaScript and HTML5 capabilities for games across diferent platforms. It seemed that major companies like Google, Apple, Microsoft and Mozilla were really trying to push the standard and their web browsers started to introduce as many features as the standard committee was adding (each one at their own pace, of course). Canvas seemed a great feature for 2D gaming. It offers most of the basic capabilities needed: image rendering and transformations. We started to develop our own game toolkit for canvas and got really good results.

But not everything were sunshine and rainbows. The performance varied in different platforms and browsers. Some features like sound and video seemed to be supported in many different ways and formats depending on the browser developer. But most importantly, specially for Ludei, mobile devices had really poor performance while running simple 2D canvas based games. The rendering was done by software. Then, our tech department saw that CSS3 has 3D transformations and that many browsers (including Apple’s iOS Safari) supported these features using hardware acceleration. It was a great opportunity to try our game engine’s abstraction layer (Our development team is a true believer in abstraction when addressing software design) and see if we were able to make a transparent HTML5 rendering context that was able to use Canvas or CSS3 whenever available. It worked. But CSS3 didn’t turn out to be as flexible as it could seem at a first glance and although we added canvas and CSS3 rendering support to our game engine, the latter showed up as a non viable option for many animation needs in games. Moreover, only Apple mobile web browsers offered hardware acceleration, so our cross platform dream could still not be true.

Having our game engine rendering abstraction, we started to look at WebGL. After solving many difficulties related to this new web feature, we end up with a full game engine that supports rendering abstraction for Canvas, WebGL and CSS3. It worked like a charm in desktop web browsers, but mobile devices were a different story. We concluded that Canvas was the best option (at least nowadays) for our games in these platforms, as CSS3 had many problems and webGL support is nearly inexistent in mobile web browsers. But the performance was still really poor for real time animation and videogames. This was the moment when Ludei’s technology department started to look for an alternative.

There are different options out there to make a JavaScript HTML5 application go native in mobile platforms. Most of them offer non standard JavaScript API-s so the Canvas could be accelerated. It was not a option for us. We wanted to have exactly the same code base on all the platforms because that is our understanding of a true cross platform development. We started a new project to be able to get a JavaScript interpreter that would notify whenever a Canvas related feature was being used, and catch those calls and make our own native rendering. This way, the JavaScript application code would remain the same and only the rendering commands would be accelerated via openGL ES. This is how CocoonJS was born.

By that time, we already had our native multi-platform framework up and running, which by the way was called Cocoon. Once again, in our pursuit of abstraction, we developed most of our code in C/C++ (around 80%) with some parts in Objective-C for iOS and some parts in Java for Android (around 20%). It means that most of our code base is multiplatform. We also designed it as a service oriented framework that allowed us to include new features easily:

  • Ad network integration. There are multiple services that allows integration with some of the main ad networks in both iOS and Android platforms to show banner, interstitial and video ads.
  • In App Purchases (IAP). There are services for both iOS and Android IAP support.
  • Analytics. Cocoon supports app tracking via third party SDKs or even server to server management.
  • Multiplayer infrastructure. We already have both GameCenter support for iOS devices and our own backend infrastructure.
  • Online resource update. Our applications can update their resources (images, sounds, texts, configuration files) online without having to create a new app version.
  • Access to device hardware specific features like the camera and the GPS.

This native framework is the core of our mobile development and allows really fast and reusable native cross platform project development. CocoonJS is included inside the framework as a new service. And it turned out to be a great design decision because we managed to offer all of the services listed above to CocoonJS because in our native framework, a service can use other services. This way,  JavaScript HTML5 development can get advantage of all the services listed above (and the ones that will come in the future), all of them offered as extensions.

But we had to prove we were able to develop an application once in JavaScript and HTML5 and deploy it in multiple platforms (desktop web browsers, iOS and Android). This is how our game Sumon was born, as a proof of our new technology. We used our whole development stack to develop this game: our game engine that can render using Canvas, WebGL or CSS on desktop web browsers and our native JavaScript HTML5 Canvas wrapper CocoonJS. The game worked like a charm inside CocoonJS. The overall performance of the game was multiplied by 1000 compared to the mobile web browsers we tried, and the CocoonJS extensions allowed us to include ads to the game. We were really happy with the final result, but did not stop there. Adding more features to the system became a priority. We developed more HTML5 capabilities like non-blocking web sockets and internal storage. We also developed more extensions like integration with social networks such as Facebook and Twitter, camera management and more. At the same time, we saw a great interest among the JavaScript and HTML5 game developer community to be able to try CocoonJS. Minor initial modifications were made to some known HTML5 games to make them run perfectly in iOS and Android using CocoonJS. This is the moment when we decided to offer it to the world and started to develop the CocoonJS launcher, a mobile device application for iOS and Android devices that allows any developer to easily try their JavaScript HTML5 Canvas based games inside CocoonJS.

And here we are now. We are proud to announce that CocoonJS is publicly available for anyone to try it. It is just a matter of using our launcher application available on the app store and the android market. In it, any developer can check out our demo examples with full source code and experience the performance boost that CocoonJS provides compared to a mobile web browser. A developer can read the easy steps needed to follow to be able to prepare any JavaScript and HTML5 Canvas game so it can be executed inside the launcher. It is as simple as creating a zip file with the JavaScript code and assets, upload it to a web server and execute it. We would like to gather as many developers as possible in order to check how CocoonJS will respond to their needs to execute their projects on iOS and Android devices. If you are a JavaScript HTML5 game developer, you are more than welcome to download the launcher and try your game!

We are currently working hard to provide new interesting features like:

  • A cloud based compiling system. Any developer that has tried the CocoonJS launcher will be able to get both an iOS and/or an Android final binaries that will be prepared to be uploaded to the app store and the android market.
  • More Canvas primitives. Although we think that the most commonly used Canvas primitives are supported right now by CocoonJS, we are trying to add as many new rendering primitives as possible.
  • A brand new multiplayer game that will demonstrate the true cross platform capabilities that CocoonJS offers. It will be playable from a desktop web browser, from an iOS device and an Android device, all using exactly the same code base.
  • More services integration so that any JavaScript and HTML developer can benefit from them as extensions.
  • Multiplayer online infrastructure. We already have a Game Center extension that allows multiplayer capabilities for iOS applications. We are working on providing a full online multiplayer experience.
  • Camera support. The developer will be able to get a camera stream and draw it intro a JavaScript HTML5 canvas or even take pictures.

As you can see, it has been a busy and exciting year for Ludei and it seems that Ludei is starting to become not just a successful content developer but an innovative technology provider. We are looking forward to see if the JavaScript and HTML5 game development community wants to answer our call and provide them with the best mobile application deployment experience to distribute and monetize their developments.