How to adapt HTML5 games to be published on Telegram

The Announcement

On October 3rd, Telegram published its gaming platform. Now, the bots are able to launch HTML5 games inside Telegram and share your score with your friends. @gamebot and @gamee were the two first bots announced and Ludei is not going to be the last when it comes to HTML5.

The Rules

When creating a game with @BotFather, he will make you accept a series of rules:

  1. You will not implement any ads or any external links on your custom URL pages.
  2. You will not invite users to pay for any services provided on custom URL pages.
  3. You will not use any data collected over the course of user interaction with your custom URLs for spamming Telegram users.
  4. You will not transfer any Telegram data collected over the course of user interaction with your custom URLs to any third parties.
  5. In order to protect the privacy of Telegram users, your custom URL pages must not set any cookies.

Now, those are some serious rules that made us change some things in our games.

Due to these rules we had to remove every way of promoting the rest of our games and every social media integration like Twitter or Facebook. Thankfully, we didn’t collect any information for third parties neither used cookies in our games -removing all that sounds like a headache.

Game Rules by @BotFather

Game rules by @BotFather

Sharing the games

The first thing you notice when reading the technical post is the script you have to include inside your games. It is a rather short script. This is because launching a game inside Telegram means opening a URL, provided by our bot, in the webview of Telegram. Our game should need hardly any changes.

<script src="https://telegram.org/js/games.js"></script>

This script provides us with the TelegramGameProxy.shareScore() method, which is used to share the game (but not a score, weird) with Telegram chats. It works like the usual share button in Telegram, there is no complexity with this part. We added a button with the shareScore() function at the result screen of each game in case you don’t know what to do with it.

Sending scores

The name “shareScore“ is quite confusing since you can’t even pass it a parameter to share. To actually send a score you should also read our post about a game bot creation. The game must send the score to the bot (with a HTTP POST, in our case) and the bot is responsible of notifying Telegram of our score. But how does the bot know who we are when it receives it? We solved this problem sending along the score a number of identifiers the bot previously added to the URL of the page. These identifiers are always userId (identifies the user) and either inlineId (if the bot was summoned with an inline call), or the pair chatId and messageId. The necessary ones are in the request Telegram sends to our bot when a user taps the play button.

Update scores in Telegram

@ludeiBot updates scores in Telegram

To sum it up: the user activates the play button, Telegram asks our bot for a URL to open and sends the identifications of the user, the bot returns a URL containing those identifiers in a query, and finally, our game can send the score and the identifiers of the user so the bot can update the rankings.

Detecting Telegram

At this point we have a game that can be published to Telegram, but why would we use two versions of the source code of our game? We still want to be able to promote our games if the user plays at ludei.net. If we can know when the game is executing as a Telegram game we can serve it from its original server to Telegram. Any special change we made for Telegram just has to follow a condition.

At first we tried checking window.TelegramWebviewProxy !== undefined  (like Telegram does in its script), but somehow TelegramWebviewProxy is undefined even inside the Telegram webview, so in the end, we just check if the URL contains the identifiers of Telegram our bot adds. In our case the identifiers were query parameters because our games already had a method to parse them. Although they could have been hash parameter too; Telegram exposes an object containing them.

Testing your game

The last thing to do is testing. Most of the testing can be done easily like with any web page development: set up a local server and open the URL in your devices. But we found some resolution problems when Telegram launched the games. Some elements appeared several times larger than when using a typical browser app. Therefore, one last advice from us is to create a minimal test bot, capable of just launching the games, enough to be able to fix any bug that might appear only in Telegram.

Our games

Check out our games (please open the following links on your mobile device):

The new Cocoon is out!

The New Cocoon Is Out!

Cocoon.io is finally out for everyone! We have been working hard and thoroughly testing the new Cocoon in stealth mode for the last months in order to verify that the whole system worked as expected, to get the initial feedback from all the users that wanted to get a first hand experience on it and to improve as many features as possible. We are deeply thankful to all the beta testers that have been patient and really helpful to create the best Cocoon to date. Thank you!

Main advantages of the new Cocoon

Cocoon.io has been designed from the ground up to try to include many of the cool features users have been demanding for quite some time. Let’s review the main advantages and differences of Cocoon.io:

  • The main structural change is that Cocoon.io is completely based on Cordova. When Ludei started working on HTML5, Cordova wasn’t as widespread as it is today. It also was completely tied only to the system webview. Cocoon has always defined itself to try to overcome some of the original Cordova limitations but it was not built on top of it. Cordova is the de facto standard in the industry to setup HTML5 to native project compilations and we have decided to embrace it and contribute to the community with our approach in Cocoon.io. This new Cocoon mixes all the benefits that have made Cocoon great plus all the advantages of Cordova.
  • Select the best webview runtime for your needs: There are different needs when it comes to HTML5 games and apps, and the new Cocoon is designed to allow you to easily select between the best webview runtimes depending on your needs. We still provide our state of the art runtime called Canvas+ specifically built and well suited for games based on 2D and WebGL canvas. We also have our full DOM support using WebView+, an advanced webview based on Chrome for Android and Safari for iOS. Cocoon.io even allows to select the regular system WebView for those developers who still want to use it.
  • Redesigned UI/UX to simplify and improve the user experience. We really hope you like it. The user feedback has been very positive so far and we will continue to improve it in the future.
  • Easy Cordova plugin setup as Cordova has tons of plugins to select from. Cocoon’s new search engine plus easy to use UI will certainly help you navigate through this sometime tedious process. Of course, you can add your own plugins to your projects!
  • Github integration to tell Cocoon.io to compile your projects directly from the content of a git repository. A very convenient way to ease the process of developing, committing/pushing and compiling your apps.
  • Let Cocoon.io help you with the signing of your final native apps. Signing your final projects both on iOS and Android can be a bit tedious. If your provide your signing keys, Cocoon.io will be able to compile a final signed app ready to be uploaded to the stores.
  • Login with different types of accounts like Google or Facebook accounts for your convenience. Of course, you can still use your current Cocoon user and password or even create a new account.
  • Web2App: We are trying to redefine the ease of use to create native hybrid apps based on responsive websites. We will provide great plugins to create native apps based on a website in order to create a compelling native app with all the advantages of mobile applications regarding performance and user experience. Directly from your responsive website URL!

The New Cocoon Developer App

As a great tool to test and debug your apps before compiling the final products. A new cloud needs a new Developer App that we have published to the stores. The cloud compiler also allows you to easily build a developer app customised to the settings and plugins you have configured in your project.

appstore_button_google
apple-appstore

Migration From The Old Cloud Service

All the user accounts have been migrated to the new Cocoon so if you login to the cloud compiler using ludei.com, now you will be redirected to the new service login at cocoon.io. We are working to migrate your projects too but as the new Cocoon is a complete overhaul, this process will take some time. We will contact each and everyone of you when the projects are migrated. In the meantime, as we know many of you still have projects on the old service, we will provide a message with a link to the old cloud every time you login to Cocoon.io.

Screen Shot 2015-12-13 at 08.47.29

Message for users with projects in the old cloud service once logged into the new Cocoon

The old cloud won’t allow the creation of new projects but as your account has already been migrated, you will be able to create them in the new cloud.

It is also important to notice that as the new Cocoon is based on Cordova, all the extensions/plugins will also be bases on Cordova plugins. This change has plenty of advantages: from a much larger selection of services to open source options and the possibility to develop and add your own native access APIs whenever needed as opposed to the old cloud that was a closed environment. We are working to provide various plugins (like Atomic Plugins) maintained by us to ensure they work in perfect conjunction with our compilation service (we even use them in our apps/games!). Most of our old extensions from the old cloud won’t be available, and thus, for those services, some modifications might be needed in your application code. We will provide as much information as possible to try to ease this process as much as possible depending on the game engine or app framework you use.

The old cloud service will be discontinued by January 31st 2016. We would like to invite you to enter and start using the new cloud and please, do not  hesitate to check out and write on our Cocoon.io forum or contact us at support@cocoon.io if you are experiencing any kind of problem.

Construct 2

If you are a Construct 2 user and you are still using the old CocoonJS cloud, please bear in mind that when exporting for the new Cocoon cloud you have to take into account two main things:

  • Export for Cordova: As the new cloud is completely based on Cordova, you have to use the Cordova exporter in Construct 2. The old CocoonJS exported has been deprecated so you only need to use it if you are exporting for the old CocoonJS cloud.
  • Use the new Cocoon Construct 2 plugins: We have a new set of Construct 2 plugins for the new Cocoon cloud. You can grab it from here: https://github.com/CocoonIO/cocoon-plugins-c2

We are working in a Knowledge Center where you will find tutorials and video tutorials about how to export and configure the Construct 2 Cocoon plugins in the new cloud.

On behalf of the whole Ludei team behind this new Cocoon, we really hope you like it!

HTML5 games are hot in China

For the past several months we have been traveling to China to attend HTML5 game development related conferences where we have been invited to participate as speakers (GMGC, H5GDC, ChinaJoy, …). It has been an amazing experience to see how both the Chinese markets and developers are embracing HTML5 as a possible great way to drive gaming content in a different direction from the polluted and very complex to stand out of what are the so called “traditional” native content stores (iTunes, GooglePlay, Amazon, …). We have and still are learning a lot about this interesting new ecosystem that is being developed in China.

GMGCH5 H5GDC
HTML5 games section at GMGC and the HTML5 Game Developer Conference (yes, H5GDC!).

GDCTalkChinaJoy

It is strange to have lived how the western countries have led the HTML5 game development for some years now, but there has not been a great reception from the markets. We are still using the same native markets as any other technology to build native games using HTML5. And do not get us wrong, it is one of the many beauties of HTML5: content can be delivered in many different forms, including native apps.

The great advantage from HTML5, apart from being cross-platform, is that it can provide new ways to access content on demand. This kind of possibilities work the best in the area of social networks, where engagement can be achieved in a much easier and organic way: just provide a link to some content and download/consume it right away. It is what we are doing in our Facebook or Twitter timeline’s in a daily basis with web content. Imagine being able to integrate the missing pieces of realtime communication with the other players that a social network provides, with monetization using some kind of virtual currency, native feature access, great performance, etc. from within the social network app itself.

All this is what is happening in China right now. Of course, there are plenty of differences between the Chinese market and its user base compared with western countries, but the idea is exactly the same. Chinese social networks (so called Super Apps in China) are very diverse and users are used to being active in more than one at the same time. These networks are great platforms for native game distribution nowadays. But the experience is disconnected as the user selects the game and has to go to a store to download the content and execute it as a separate app. With HTML5, Chinese super apps are able to engage the user inside the app and still provide all the mechanisms the social network is able to provide. This is the type of HTML5 content use case we at Ludei have been waiting for years but in the Western countries haven’t been successful yet for different reasons (the messaging app Kik has been the only significant example). So imagine our excitement when we started to travel to China to learn from what’s happening there.

It is very early still but China has established the steps in the right direction to make this whole HTML5 gaming ecosystem a reality. New technology companies have started to create great technology and tools, markets/super apps are embracing HTML5 and creating new sections for this type of content and users are starting to show that acquiring them can be much easier if the whole experience is integrated inside the social network and the content is virally distributed among players. The perfect storm.

This is a great opportunity for Ludei. China is a great believer in the benefits of HTML5 runtimes and Ludei has both the technology and the community to provide great content to the Chinese market. Runtimes are being integrated inside the Super Apps so the fragmentation, performance and feature problems of traditional webviews are eliminated to the benefit of the developers.

We have been in touch with all the players in the sector: developers, publishers, technology providers, markets, carriers, … and we are working hard to establish a great way to help all the great developers that have used Cocoon so far to publish their games (or any HTML5 game developer out there regardless if they haven’t used Ludei’s tools 😉 reach this very interesting but complex market in China. We have created a close relationship with the most important HTML5 game publishers in China and many developers are aware of Ludei and using Cocoon to publish their games already in the country. As a matter of fact, the game that has been awarded as the best HTML5 game in China has been developed by Wozlla, a company that has been using Cocoon for over 3 years now and with which we have a very close relationship.

WozllaAwardOur friends from Wozlla receiving their “best HTML5 game” award at H5GDC

We will make all the efforts possible to make the transition to this market as easy as possible for anyone that wants to leverage their content in the country of the Great Wall.

Exciting times for HTML5 games.

iBasketGunner: Ludei’s First 3D WebGL Mobile Game

Ludei started as a game development company around 4 years ago. Then we focused most of our efforts in platform and technology development. Still, we publish a game or two from time to time that help us fulfill two main purposes:

  • Taste our own dog food ;). Test the CocoonJS platform.
  • Have fun! We love making games!

iBasketGunner is one of our latest productions. It continues the saga started by our fairly successful game iBasket. We started iBasketGunner as we wanted to test 3D capabilities of our WebGL implementation for both iOS and Android and also include all of the extension services into one product. This game has them all: In-App Payments, Social Network Integration, Multiplayer, Advertising, … and of course, 3D and even an ad-hoc implementation of a 3D physics native binding, one of those cool things only CocoonJS can offer. Let’s check out the result in the following video:

And now, let’s talk about some of the technical features of the game:

  • It is definitively one of the best looking 3D WebGL games for mobile in the market. Our team has worked on some cool shaders for the ball, the net, etc.
  • It uses a modified version of ThreeJS, one of the most well known 3D WebGL open source engines out there.
  • We have used all of our CocoonJS extensions in this game. It has been great to have a single API for all of them, even the complicated ones like multiplayer through Game Center (for iOS) and GooglePlay Game Services (for Android in GooglePlay). Ads, IAPs, Social Network Integration, etc.
  • There is our first approach to a 3D physics engine native integration using Bullet and it’s JavaScript counterpart AmmoJS. This makes the game run smoothly as JavaScript is not a very powerful language to make math computation. We have even tested the game on low-end devices such as the iPhone4 or even on a Nexus One (Android 2.3). Of course the performance is lower, but you still can get 20-30 FPS on them!

We really hope you enjoy iBasketGunner that is available in iTunes, GooglePlay and Amazon!

 

Powered By CocoonJS: Elliot Quest

Here at Ludei we try to review and stay in touch with many (if not all) of the developers in our community. We are always amazed by the quality of products that you guys publish and try to provide the best feedback and listen to all your needs in order to improve the platform.

Today, we want to focus on a very interesting project we knew about some time ago as it was a successfully backed KickStarter project that looked amazing and was highly anticipated: Elliot Quest. We have been in touch with the mind behind the project (Luis Zuno) and we are happy to announce that the OUYA version of the game has been published powered by CocoonJS’ Canvas+ technology. In this case the game was developed using ImpactJS, one of the many game development engines Canvas+ supports. The game is also available on Steam now and there is a WiiU version coming out soon. 

Luis has been really kind to write some words about his project and the process of using CocoonJS.

“Since I started working on Elliot Quest, I always wanted to have the possibility to publish my game on a platform such as OUYA, but due to the limitations of the default HTML5 runtimes it was nearly impossible. I was getting 16FPS and the game was unplayable.

Fortunately I found CocoonJS and it’s Canvas+ technology and my wishes became a reality! The performance is simply awesome, the framerate is stable and it supports the gamepad API with the same HTML5 standard API. It is fully compatible with ImpactJS and as a developer it was a relief to find the CocoonJS cloud compiler service. Compiling the game and testing it on the console was a delight and the support team helped me during the whole process.

I recommend CocoonJS to any developer that wants to get their HTML5 products to mobile native platforms.”

We want to applaud the great work behind Elliot Quest and all of the projects that are being published using CocoonJS. Thank you very much everyone, you are the reason why CocoonJS exists and hope to see more great products published in the future!

If you have an interesting project, do not hesitate to let us know about it. We will try to periodically write posts about interesting apps published using CocoonJS.

 

CocoonJS CLI now with live reload

At Ludei coding never stops, and today, we’d like to introduce to you the new feature we’ve added to our CocoonJS Command Line Interface: live reload.

We are javascript developers too and we’re aware of the need of being productive. We realized we needed a faster way to iterate over our JS code, so why not include the live reload capability to our CLI?

For those who don’t know what live reload is, this feature reloads automatically the code of your app inside the connected browsers each time you save your changes. This way you forget about saving, going to the launcher, and refreshing the content to see the changes every time.

How do I benefit from this new feature?

First of all you must update your cocoonjs-cli version. You can find more information about our CLI here.
sudo npm install -g cocoonjs
Then, you can create a new project, as always:
$ cocoonjs create MyProject com.ludei.test LudeiTest
$ cd MyProject
$ cocoonjs platform add android
$ cocoonjs serve

You’ll read a message like this one:

[CocoonJS] Executing command 'serve'
[CocoonJS] A 'cordova prepare' is needed before executing 'cordova serve'.
[CocoonJS] Command 'cordova prepare' executed correctly.


[CocoonJS] Static file server running on port 8070 (i.e. http://192.168.0.43:8070)
[CocoonJS] Path: /Volumes/data/hello-world
[CocoonJS] CTRL + C to shut down

Now, open a launcher an point to that web address. In our case http://172.16.100.43:8070. You’ll find the default main page. Also, if you are working in the same machine where the command was executed, you can point to the loopback/localhost interface (127.0.0.1).

Open the contents of the www folder with your code editor, and edit them. Each time you save the code, the launcher will refresh with the new content!

The video below is a good demo.

We hope you’ll love it!

CocoonJS Announces the WebView+ for iOS 8: Publish WKWebView Powered Standalone Apps

Apple’s new iOS version 8 announcement brought many good news for the HTML5 developer community. Safari has improved much (it now supports WebGL for example, yay!) and the system webview now comes in two different flavors: UIWebView and WKWebView. The main difference is related to the JIT optimization for JavaScript. To put it in plain words: the execution speed for JavaScript code is orders of magnitude faster using a JIT compiler and thus, your web app may run much faster inside the new WKWebView than in our older friend the UIWebView. To know more about the WKWebView and to have a glimps of the performance improvements, please, check the following great article by Sencha or check our own tests below.

At Ludei, we immediately started playing around with the WKWebView as we were eager to provide it along with all the great runtime environments we have (Canvas+, WebView and WebView+ for Android). But there was a catch. At least in the current version of iOS, there is no way of deploying a native hybrid HTML5 app using the WKWebView that has access to local files, something that is quite common on Hybrid apps to be able to execute them off-line. But Ludei has always loved a good challenge and we decided to solve the problem and make the WKWebView available to every developer that would like to use it.

Today, we are happy to announce that we have added a way to create WKWebView based completely standalone hybrid applications for iOS 8 in our CocoonJS Cloud Compiler System version 2.1. As far as we know, no other technology allows to publicly create completely offline WKWebView based apps at the moment. We have decided to call the WKWebView based runtime environment: WebView+ on iOS 8. We will still provide Canvas+ and the regular UIWebView, but every CocoonJS developer that wants to take advantage of the WKWebView, is able to do it right now. Whenever the application is running on an iOS version lower than 8.0 where the WKWebView is not available, there will be a fallback to the UIWebView.

We have also added this shiny new WebView+ for iOS inside our CocoonJS Launcher that is still in review by Apple. Meanwhile, if you want to check the awesome performance that it provides, you can build a Custom CocoonJS Launcher using our cloud.

ADDITIONAL NOTE: We are working hard to add the WebView+ to the CocoonJS CLI too! Stay tuned!

WebView+ Vs WebView on iOS 8

We have performed some tests ourselves to check how much of a better option the WKWebView (CocoonJS WebView+ for iOS 8) is compared to the UIWebView (CocoonJS WebView). These are the results:

Canvas intensive operations

All the test were executed on a iPad Air iOS 8.0.2

First test

2000 sprites rotation + translation with sprite animation rotation and random colored vertices

  • Webview+ : 30 FPS stable
  • System Webview: 6 FPS stable

Second test

3000 sprites Rotation + translation. Using 3 framebuffers. Transparency and tint with custom shader and custom clip area

  • Webview+: 20 FPS stable
  • System Webview: 4 FPS with unstable frame timing

Third test

5000 sprites 32×32 using rotation + translation, tinted vertices and MipMap

  • Webview+ 17 FPS stable
  • System Webview: 3FPS with a frame timing between 379 and 400ms

Tests with well known benchmarks

All the test were executed on a iPhone 5 running iOS 8.0.2

Octane 2.0

Octane 2.0: is the javascript benchmark from the v8 team. Lets see the differences between webview+ and webview. The higher the mark, the better.

Octane test Webview+ Webview
Richards 2712 117
Deltablue 2834 125
Crypto 3491 203
Raytrace 3474 365
EarleyBoyer 5118 636
Regexp 382 42,5
Splay 2384 605
SplayLatency 1641 2101
NavierStrokes 3455 323
pdf.js 3025 1006
Mandreel 2407 118
MandreelLatency 1784 702
GB emulator 4593 943
CodeLoad 5315 3912
Box2DWeb 2806 689
zlib 4675 N/A
Typescript 4363 N/A
Octane Score 2819 N/A

N/A means that the benchmark stops or freezes the the device.

Wirple BMark

This is test for webGL performance. The higher the score, the better.

Test Name Webview+ Webview
Canvas test1 61 26
Canvas test 2 38 10
WebGL test 1 17 7
WebGL test 2 14 7
Total score 130 50

Of course, some screenshots of the results 😉

The webview+’s results on Wirple BMark

Screen Shot 2014-10-22 at 18.34.00

The system webview after running Wirple BMark

Screen Shot 2014-10-22 at 18.34.14

Techniques to Optimize Memory Use in CocoonJS Canvas+ Environment

Memory is a critical resource in HTML5/JavaScript game development, especially on mobile devices. In a desktop environment you can load tons of textures but on some low-end mobile devices you can reach the maximum RAM limit quickly. Although JavaScript encourages automatic memory management by using a garbage collection mechanism, you shouldn’t ignore effective memory management techniques. HTML5/JavaScript applications can suffer the same memory related problems as native applications, such as memory leaks, out of memory issues and they must also deal with garbage collection pauses. 

This post will give you some general advice on memory optimization for HTML5 games and some CocoonJS Canvas+ specific tips.

Effective asset loading

Preloading all the assets at the start is the easiest and quickest way to manage the memory but it only works for small games where all the assets fit into the available memory. You shouldn’t preload everything on a heavy game, only the assets that you need each time, and dispose of the unneeded assets as soon as possible. Your game memory usage depends highly on your game engine (some of them do a better job than others). Don’t expect that the browser or the garbage collector will fix all your problems and that you can stop worrying about effective memory management.

Texture packer

Javascript images and canvas objects are backed into OpenGL textures and FBOs, usually using RGBA format, 32 bits per pixel. Think about it, for example a 2048×2048 image eats 16MB of memory!  Some GPUs require POT (Power Of Two) textures for the best performance, so keep in mind that some images could use more memory than their real size and use 2^n size textures whenever you can.

We recommend that you pack all your textures using one of the Sprite Packer tools out there. That way you’ll waste less memory and improve performance (by avoiding the number of context switchings) and loading times. Some HTML5 engines are able to pack all your textures at runtime, others don’t, so please check your engine features first.

Garbage Collection

JavaScript automatically frees objects when it detects that they are not used anymore, this process is called garbage collection. During a collection the execution on your page can be suspended for a moment. If your game creates too many JavaScript objects in each frame it can lead to noticeable pause issues. This is another example that proves that it is a mistake to forget about memory management on JavaScript. You should reuse javascript objects whenever possible.

The dispose method

Image and Canvas objects are disposed when the garbage collector detects that they are not reachable in the JS code. The disposal is not immediate, it may take some seconds depending on the heuristic rules of the JavaScript virtual machine. Using a WebGL context the developer has more precise control over the WebGL texture and buffers disposal but that’s not the case when using a 2d context or when dealing with Image and Canvas objects.

CocoonJS’ Canvas+ environment exposes a method called “dispose” on canvas, image and audio objects. This method immediately frees the associated texture or internal buffer, which is very useful for games with heavy textures or for games that need a greater control over the memory.

Using this CocoonJS Canvas+ exclusive feature is very easy. Imagine we have an image object represented by the “myImage” variable.
[code lang=”javascript”]
myImage.dispose && myImage.dispose(); // The same for canvas and audio objects.
[/code]

The memory warning event

iOS and Android native applications are able to receive a memory warning notification from the system. The default implementation in Canvas+ and WebView+ environments is to perform a garbage collection and free as many internal cached data objects as possible.

From CocoonJS Canvas +2.1, the environment exposes the “memorywarning“ notification as a window listener. It is strongly recommended that you implement this method and free up as much memory as possible by disposing of cached data objects, images on canvases that can be recreated.
[code lang=”javascript”]
Cocoon.on(“memorywarning”, function() {
// dispose of cached images and canvases that can be recreated
});
[/code]

Texture reducer

Texture reducer is a CocoonJS Canvas+ exclusive feature. When your game targets all resolutions you need huge textures for iPad retina like devices and small textures for small mobile devices. A game developer has many ways to handle this:

  1. Create different asset packages, HD and normal. Good solution but bigger app size.
  2. Scale down HD resources. Excessive memory usage and performance impact on small devices.
  3. Create smaller asset packages on runtime rendering to a canvas/texture. Good solution but some JavaScript engines don’t support this.

The CocoonJS Canvas+ texture reducer feature can transparently do the job for you. It uses the third approach and it is highly customizable (for example, you can only apply it to certain resources). Check out the complete API documentation to see how to set it up.

As the texture reduction lowers the quality of the final images to be displayed, an interesting approach that we have recommended to some customers is to apply it only for certain device models, leaving higher resolution for some others (you can use the “navigator.userAgent” property to identify the device model). This, of course, it is not an easy task on Android due to the big number of device types, but on iOS is definitively an interesting option, specially for older devices such as the iPhone4 or the iPad Mini 1st generation.

Max Memory Threshold

This new CocoonJS Canvas+ exclusive feature available from version 2.1 and higher, exposes the “setMaxMemory” utility method. When the max memory threshold is set, CocoonJS checks the total amount of texture sizes (images and canvases). When the runtime memory size reaches the max memory threshold, CocoonJS disposes of the least recently used textures until the memory fits the threshold. It disposes of textures used for JS Image objects (which can be reloaded later if needed or are drawn again). It doesn’t dispose of canvas objects because they cannot be reconstructed if they are used again in a render operation. This extension is designed to be used in 2D contexts, because in WebGL contexts the developer is the one responsible for memory disposal.

Check out the API documentation.

Lazy Loading

Another CocoonJS Canvas+ exclusive feature available on version 2.1 and higher we have added the “cocoonLazyLoad” boolean property to Image objects (we have also added a duplicate called “idtkLoadDisposed” for retro compatibility with Construct2). When the property is set to true, the image is not loaded until it’s used in a render operation. Engines that load all the assets at startup can benefit from this property. But do not forget to purge the textures when they are not needed again, for example, using the dispose mechanism described earlier!

NPOT Textures

Canvas+ uses POT (Power Of Two) textures by default in 2d contexts. This is very useful for performance improvements, especially on mobiles with old GPUs. But it can waste memory on games that don’t use packed or 2^n textures. In CocoonJS Canvas+ version 2.1 you can allow NPOT textures in Canvas2D contexts (they were already supported in WebGL).

Check out the API documentation.

Conclusion

We have covered some basics of memory management in HTML5 games and exposed Canvas+ specific tips and tools.  We are always open to your suggestions. Remember that if you have some problem with memory usage in Canvas+ and you think that the problem is on our side you can send us a testcase and we’ll be glad to help you.

Additional Notes about Ludei’s Canvas+ Environment

CocoonJS’ Canvas+ is not a full browser, but a highly optimized JavaScript Virtual Machine for Canvas 2D and WebGL environments. Comparing it to a full fetched browser is not recommended as browsers include “a lot of magic tricks” (and that is why sometimes they are big and slow). For example, a browser might be able to handle a 5000 by 5000 pixels image but that does not mean that the underlying device is able to do it, just that the browser is handling some things internally for you either lowering the quality of the image (downscaling it) or subdividing it. Very few native technologies (C++ game engines) allow this kind of features as the developers should know how to handle this situations correctly (do not use 5000×5000 textures in the first place). Here at Ludei we never intended to create a new browser, but provide a highly specialized runtime environment so HTML5 developers can be closer to the native side without ever leaving JavaScript and the great HTML5 APIs.

CocoonJS In App Purchases are easier than ever in Kiwi JS

WE  apple-touch-icon-144-precomposed  KiwiJS

KiwiJS is a game development framework that uses JavaScript and HTML5. Ludei and the team behind it have been working to make it compatible with Canvas+ in CocoonJS. Their feedback has been invaluable and CocoonJS has improved much thanks to this collaboration, as we do with any other game engine out there.

 

Both platforms have been compatible for a while now but today we are pleased to announce that our friends over at Gamelab have just launched version 1.0 of their HTML5 game framework Kiwi.js and a much needed In-App purchasing Plugin for CocoonJS! What we found is that this new version of Kiwi is easy for developers to use, comes with a ton of documentation, runs fast and offers a lot of useful features. The In-App Purchasing Plugin (which comes with an example store fashioned off the Kingdom Rush store) allows users to sell their consumable game items to players and to create virtual currencies within their game. Also available for purchase is a Cartoon Particle Effects Pack that promises to make your HTML5 games pop! 

 

Kiwi.js founder, Dan Milward, says that while the ‘indies’ are a well catered for community, his company has identified a need for professional services that provide a higher level of customer support to the industry as a whole. “What we want to see is the HTML5 space taken more seriously and used to create serious games. Our pro add-ons, customer support model and IP partners will all go towards helping make this happen.”

 

For more information head over to the kiwi website.

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! 😉