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.


Read about iBasket on TechCrunch.

CocoonJS Release (2012/11/20)

The most awaited CocoonJS update has finally arrived! We have been working really hard the last couple of months to improve our platform. This new release comes with many new features, bug corrections and improvements. We know it has taken really long to get the new version out, but we really hope it will be worth it. Let’s give a quick review to all the new cool stuff inside the new version of CocoonJS by Ludei!

  • CocoonJS extensions
    • In-app purchase test bed
    • Easier to use and improved WebView integration
    • Application “quit” control
    • “screencanvas”, a new way to improve performance (even more!)
    • Opening URLs using the system web browser
    • Text and message dialogs
  • DeviceMotion and DeviceOrientation APIs
  • Vibration and GPS APIs
  • The HTML5 path API (an industry 1st)
  • Box2D native binding (beta)
  • Improved rendering system
  • Support for more ad networks
  • iOS6 and iPhone5 support

CocoonJS extensions

CocoonJS includes an extension mechanism to provide native features missing in the HTML5 standard. Although the extension mechanism has been present from the first release of CocoonJS, in this new version, along with new features, new more developer-friendly APIs have been introduced. Most extensions (except from the social network extension) are backward compatible, meaning that if you were using the window.ext.IDTK_XXX mechanism your code should still work. Anyway, we HIGHLY recommend you to use the new extension mechanism, that is easier to use and has full documentation and support from our side. All it takes is for you to include the necessary JS files at the beginning of your HTML file depending on what features you want to use and what environment you are using: CocoonJS and/or the WebView. One of the coolest features of these new extension APIs is that they handle all the cross-platform management. Forget about having to see if the extension is present or not. The JS code will do that for you and it will make your code compatible in a desktop web browser, in CocoonJS or in the WebView feature. All the demos have been rewritten to use the new extension APIs so you will still be able to learn much from both the demos and the documentation we provide. Although we will update our wiki with full documentation and tutorials, let’s review some new features in the CocoonJS extensions:

In-app purchase test bed

The latest version of the CocoonJS launcher app offers the possibility of testing our extension APIs for IAPs. Although this feature has been available in previous versions of CocoonJS, it has not been published because there is not an easy way of allowing developers to test IAPs in the launcher app. This new version of the CocoonJS Launcher App enables a mock-like environment so any developer can test the IAPs extension APIs and then, whoever has premium access capabilities, can configure them for real in our cloud compilation system, that also provides a complete set of tools to track and check the purchases made inside the apps, and start making money ;).

Easier to use and improved WebView integration

The new CocoonJS extension APIs provide a much easier and better way of handling the web view feature inside CocoonJS. Now you are able to load as many URLs or local files to the WebView and all the way around, from the web view to CocoonJS. Sending messages from one environment to the other has never been easier and now these can also be asynchronous. Any window.console object output in the web view will be shown in the CocoonJS debugging console automatically making the debugging of web view content much much easier. Long story short, the WebView support has been dramatically improved.

Application “quit” control

In Android (not in iOS) the back button can be used to destroy the activity. Now, there is a way to control this behavior from JavaScript. The default behavior has changed and now, if the developer does not specify anything, CocoonJS will prompt a dialog and pause the application to let the user decide if the app should be destroyed or not. Moreover, the developer now has the possibility of specifying that he/she wants to take control of the app finalization. The process is as easy as specifying a function that will return a boolean by calling CocoonJS.App.setAppShouldFinishCallback(FUNCTION_THAT_RETURNS_A_BOOLEAN). If the function returns true, it means the app should finish and if it returns false, it means it should not finish and that the developer takes control of the finalization. Whenever a developer wants to finish the application, there is a function called CocoonJS.App.forceToFinish. This feature is specially useful in Android (in iOS for example none of the functions will work).

“screencanvas”, a new way to improve performance (even more!)

Ludei has been providing the best performance for HTML5 gaming that is in the market and in the pursue of this goal we have been improving the rendering mechanism day after day. In this new release, we have found a major improvement that requires not much effort from the developer perspective. Most canvas based games create and use what could be called a “main” canvas where everything else (images, primitives, other canvases, etc) are drawn. If your app uses this “main canvas” idea, you can benefit from this feature. The only thing that you need to do is to call the new function CocoonJS.App.createScreenCanvas to create this “main canvas” and you are good to go. Specially in android and in some specific devices, you will see a minimum of a 2x performance boost by doing so. Check-out all the CocoonJS demos in the new CoconJS Launhcer App and see it for yourself!

Opening URLs using the system web browser

This has been a very frequent request among the developers using CocoonJS. By calling the function CocoonJS.App.openURL(URL) you can call the system browser to open a URL. It can be very useful to provide access to your app users to the rating of your app, to open your website URL, etc. Anyway, as many of you know, CocoonJS provides a WebView control that can be displayed over (or even alone) our OpenGL rendering surface. We also recommend to use this feature so you don’t have to switch between apps (your game and the web browser). Check the CocoonJS.App.loadInTheWebView and the CocoonJS.App.loadInCocoonJS functions to take control over this features.

Text and message dialogs

Text dialogs already existed in the previous versions but the mechanism has been extended and made easier. In this version message dialogs have been also added and regular web browser support has been included.


DeviceMotion and DeviceOrientation APIs

This feature has been long awaited by the CocoonJS developer community. Finally, CocoonJS supports both accelerometer and gyroscope events providing the W3C specification APIs. Not a lot of both desktop and mobile browsers support these APIs.

Vibration and GPS APIs

They have been added in the previous version of CocoonJS but now they have been improved and new demos are provided so developer can learn from them.

The HTML5 path API (an industry 1st)

This is a really interesting new feature CocoonJS supports now. The W3C canvas API offers the option of creating complex paths, thus, rendering vector graphics, with all the advantages that this means (less memory footprint, transformation capabilities, faster rendering, etc). CocoonJS is one of the first HTML5 rendering virtual machine that supports the path API. Check out our new demo to see some pretty amazing results!

Box2D native binding (beta)

Box2D is a widely used 2D physics engine. There are multiple ports to multiple platforms and languages. There is a port to javascript but due to it’s demanding mathematical calculations and poor memory management, the performance it provides for environments other than desktop web browsers is not acceptable. CocoonJS has included a native binding to solve these problems. This feature is still in beta and not all the Box2D APIs have been implemented, so it is to fully compatible with the Box2DWeb version, but we are getting there. Check out the performance you get both in iOS and Android by executing out new cool demo!

Improved rendering system

Our openGL ES expert developer has rewritten our native binding completely and now we have a more stable and reliable and full HTML5 compatible rendering system. We are still trying to push the envelope and will try to solve any graphical glitches that can appear from now on but this version is definitively the most advanced HTML5 rendering system in CocoonJS ever!

Support for more ad networks

New ad networks have been integrated to the ad extension.

iOS6 and iPhone5 support

The new iPhone5 and the new iOS operating system have led to some internal modifications and the need of some changes in the cloud compilation system configuration.

Well, that is a full list of features! As you can see, there are a lot of new things CocoonJS can do now and many highly requested features and bugs have been included and solved. We are still working hard to try to provide you with the best HTML5 gaming experience on mobile devices, so stay tuned for the next releases!

Keep creating amazing games and let CocoonJS to power them! 😉

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.

Ludei at the HTML5 DevUp by Ideateca

Last month, we participated as both sponsors and speakers at the HTML5 DevUp by Ideateca in Barcelona.

The event hosted more than 300 attendees that were interested in JavaScript development in general and specifically in game development. During the event we had the opportunity to chat with many people interested in our technology.

Here’s the video of our morning presentation. In this video, Ibon Tolosana and Iker Jamardo talk about CocoonJS and the possibilities it offers to JavaScript games developers.

Rob Boerman from Appoint Solutions took part of the presentation.

In the second video our colleagues Ibon and Iker go into more detail during the workshop held that afternoon.

Hope you enjoy it!

CocoonJS, the advanced survival guide.

CocoonJS now offers out-of-the-box integration with many major HTML5 gaming platforms and frameworks like Scirra Play Construct 2, Impact or CAAT among others.
Integration is direct, and no code changes must be made to your source code beyond the tips we already talked about in the post CocoonJS a survival guide.

But we can’t forget that CocoonJS is a hardware accelerated environment, with deep OpenGL bridge integration, and sometimes, that is not at zero cost. This post unveils some advanced concepts you probably won’t have to be dealing with, but just in case, we must warn you about them.

These topics are not CocoonJS specific, but generally applicable to any OpenGL backed development.

Be aware of your images’ size.

Regular HTML Image objects are backed by OpenGL Textures. These textures must be 2^n sized, that means that valid texture sizes will be 64×64, 64×128, 256×512, etc., which in the end, could lead to wasting texture space. For example, if you have an Image that is 33×65 pixels, it will take 64x128x4 bytes in memory instead of the expected 33x65x4 (multiply by 4 because each pixel is RGBA packed).
Whenever possible, an atlas image is better than many arbitrary images.

Images’ size can’t be huge.

In addition to the two square size restrictions, textures can’t exceed a given size. While we’ve found that normally a GL Texture object could be 4096 pixels width and/or height, certain medium-high end Android devices will limit that size to 2048.
While it seems to be enough size for an Image, to make sure, limit your Image’s width to 2048 pixels.

Be aware of your Canvas objects.

Regular Canvas objects are backed by OpenGL FrameBuffers. This means amongst other things, that the same size restrictions apply as to Image objects. Despite the fact that a regular game is not supposed to keep many canvas objects at the same time, you should keep their number tight.
Additionally, if clipping operations are performed on a Canva’s Rendering context object, the canvas needs to allocate extra resources, like an stencil buffer.
Keep in mind that Canvas objects can take twice as much as a regular Image.


In addition to the size constraint when clipping is enabled, clipping should be used sparingly. CocoonJS implementation allows you to nest as much clipping areas as needed, but at the cost of some performance loss.
This is due to the fact that clipping areas must first of all be tesselated, but reconstructed when the context is saved/restored.
If your game does not perform as expected and you’re doing heavy clipping operations, try disabling them and compare.


Despite what it may seem, filling text is not that straightforward operation. Filling text means: allocating a new GL Texture to hold drawn text, uploading pixels to that texture, and then destroy the texture to probably repeat that procedure in the next frame.
CocoonJS caches text, but is not heuristically intelligent. So if your game makes extensive use of drawn text, our advice is to cache the text to an offscreen canvas and manage it yourself, or even better, draw text with an sprited font.

To assist you with all this memory management nightmare, CocoonJS will issue some warnings with debug information regarding the allocated amount of memory in addition to the allocated number of images and canvas’s.

CocoonJS a survival Guide


CocoonJS is an accelerated javascript and HTML5 execution environment with a strong focus on monetization. Its main features are amongst others, support for asynchronous websockets, access to monetization extensions, out of the box native multichannel sound, etc. But amongst them, there’re not the features of being a complete browser, nor a WebView.

That said, think about CocoonJS as a kind of “browser”, which gives support for the HTML5 Canvas elements, websockets, XHR, audio tag… all of them customized for maximum performance and response time, but doesn’t give access to CSS, most of the document element out of the box objects and HTML markup in general.

The big question is: Why ?!?!?!?!?

Because after all, CocoonJS aims to execute Canvas games on mobile devices in full screen. That means, there’s no room for other elements but stacked canvas. And in a full screen environment, most of the functionality a browser offers is not needed. We don’t need scroll events, mouse events, etc. But admittedly, we need some layering of arbitrary markup language, and we are as of right now, actively working on it.

So, how do I get my games running accelerated to the bone in CocoonJS ?

The first thing to note, is that CocoonJS does not rely on an HTML file to run. This simple fact leads to some needs:

  1. Even though it is not absolutely needed, have all your JS source code in a single file.
  2. Instead of relying on an HTML defined canvas element, you must create it manually, either by calling new Canvas(); or document.createElement(“canvas”);
  3. Add manually created Canvas objects to the document as in a regular browser: document.body.appendChild(canvas);

Once this step is done, any Canvas based game should run at full accelerated speed.

How we ported adjusted Onslaught Defense (OD) to run inside CocoonJS

Module Managers.

First of all, for those who use a module manager like require.js or any others. At the moment, CocoonJS doesn’t offer any support to the script tag. As I said previously, CocoonJS expects all your code in one single file. Some module managers like Impact engine’s, make a dependency resolution that doesn’t start injecting script files immediately. Somehow, it defers script injection until it has evaluated the whole file.
But with Onslaught Defense, which uses require.js, things didn’t work that straightforward. We had to patch require.js code to avoid script injection. After all, the whole Onslaught’s source code was already together in one file.
Patched code on require.js was:

  1. Dealing with document’s head and the calls for getElementsByTagName. Reason: no DOM support.
  2. getInteractiveScript: remove getElementByTagName(‘script’) block.
  3. req.checkReadyState function. Just return req.resourcesReady(true)


The way in which OD detected touch enabled was querying for typeof window.ontouchstart !== "undefined". CocoonJS is touch enabled, so we substituted that check for: isTouch=true;.

Screen resolution

OD was dealing with making a canvas object full screen if on mobile. In CocoonJS this feature is out of the box. So we patched the code to set document.body.style.width and document.body.style.height. These are DOM related and not supported (nor needed on full screen mode). Also code related to canvas style and position was patched, since it isn’t needed.

For now on, the correct way of getting screen size is window.innerWidth and window.innerHeight. To make your Canvas objects full screen, set canvas.width= window.innerWidth; canvas.height= window.innerHeight.

One thing you must know about CocoonJS is that you don’t have to change your canvas size to make it run fullscreen. CocoonJS will up/down scale your canvas and have correct touch coordinates sent. You could choose how you’d like your canvas to be scaled, either keeping aspect ratio or not, and also if you want to have no blurring filter applied to the scaling operation, which comes handy for games relying on pixel art. Refer to the official CocoonJS Wiki pages to know how to control scale operations.

Since OD scales itself in the browser to conform the whole window size, we patched it from scaled canvas to game coordinates coordinate-transformation routines. Just comment two lines. Just commented two lines of code.

Localizing on-screen coordinates

Since in CocoonJS the canvas object takes full screen, there’s no need to deploy complex procedures traversing upwards the DOM hierarchy, adjusting with styles, etc. just to get the correct coordinate offset inside the canvas element. The canvas is always at 0,0 and touch events reported coordinates are already in Canvas space.
Modern browsers offer out of the box canvas-space coordinate values via layerX, layerY or offsetX, offsetY. CocoonJS is not a browser/WebView, and as multiplatform developers must derive procedures to get the correct canvas coordinate out of input events. Luckily for us, CocoonJS behaves like modern browsers as gives correct on-canvas coordinates out-of-the-box.


The only issue with the sound is that CocoonJS requires the method load be called.
OD uses sound-sheets, which we don’t recommend at the moment. TBH we must improve the sound objects to be able to play sound-sheets.

The result

The result, is a game running @250fps on iPhone 4S iOS 5.1 and @150fps on a Samsung Galaxy S2. The amount of tweaked lines was less than 30 and most of them were DOM related. The overall procedure took 2 hours until having a fully functional OD game deployed in CocoonJS launcher.

Yes, you’re right, sound-sheets are not running properly. Until the next CocoonJS launcher version, where they will.

Go, give it a try on the browser, and soon on natively on your mobile phones.

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.


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


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.


    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.

Ludei GDC wrap-up

Last week the Ludei team was at the very exciting Game Developers Conference and we had a blast talking to developers about HTML5 and our awesome technology.

Although HTML5 hasn’t fully blown out yet, we saw a lot of excitement and hope for HTML5 amongst all game developers (flash, iOS, and Android).

We talked to various kinds of developers that wanted to make the transition to HTML5 that were looking for a good solution in the present.


ludei stand gdc


We all sensed the rising opportunity for HTML5 and all the developers we’ve talked to were very interested in learning about CocoonJS.

Because our technology does not constrain developers to a SDK or library (thus no code changes), we believe that our technology is positioned to provide the right support in the present while being able to adapt to the inevitable changes of HTML5 in the future.

Thus far, we have gotten great feedback and even though GDC is over, we look forward to hearing from everybody!

HTML5 Developers Conference Barcelona

We present you

HTML5 DevUp Barcelona

HTML5 Developers Conference

HTML5 Developers Conference

Now, hardly anyone doubts whether or not HTML5 is the future of web and mobile development. As you all know, at Ludei we are betting on HTML5 for games as well as for applications and websites. This is a space that moves very quickly, which makes it essential to stay up to date on the newest trends and changes in order to capitalize on opportunities as early as possible and to produce cutting edge products.

Last year more than 300 professionals came together at iPhone DevUp, and this year we have changed the main topic of our annual developers event completely to adapt to the shifts in this sector. This time we will focus on the present and future, opportunities and risks, as well as the truths and myths surrounding HTML5.

Top notch international keynote speakers will reveal their experiences and points of view. Furthermore, attendees will have the chance to go deeper in the areas they are most interested in thanks to the practical workshops and seminars that will be held in the afternoon. At night, a pleasant networking cocktail party will give us the opportunity to continue the conversation with other attendees as well as the actual keynote speakers.

Don’t miss the European HTML5 Developers Event, April 27 2012 in Barcelona. Get your tickets NOW at a special early bird discount!

Let’s meet at GDC!

From  March 5th to March 9th, we are sponsoring the Game Developers Conference(GDC)! GDC is the premier conference for game developers. This event brings together emerging start-ups of the gaming industry to explore business development strategies and best practices.

On monday our CTO, Ibon Tolosana is giving a talk about HTML5 development at the HTML5 Tutorial Day, and we’ll be exhibiting at the Smartphone and Tablet Games Summit on Monday and Tuesday.

Are you a developer and planning on attending GDC?  Visit our booth! We would love to talk with you about our HTML5 game technology(CocoonJs) and show you how it works!

For those of you who can’t come, you can follow us on twitter  for live updates. We are eager to meet you in San Francisco!