Best Games of Telegram

Since Telegram announced its Game Platform we have been very enthusiastic to work in it as you might already know. After all, along this article, we have already published a tutorial about how to develop a game bot and another tutorial about porting your HTML5 games to Telegram.

But we also like to play and we realized it is not very easy to find games in Telegram (only for the moment… we hope); that’s why we want to list here our favorites games.


Don’t Die in @DontDieBot

Listen to me, this is a good one. Really challenging but extremely easy to learn. The responsiveness of the controls is perfect.Do Not Die

In each level you drag your character to pick up a key that will open the door of the next level. But don’t let the zombies see you… or smell you.


iBasket in @ludeiBot

What? Yes, it is one of our games, but we really worked hard on it to create a good game. And more than once we have had bad looks at the office when someone gets the first place in the rankings.iBasket HTML5

Simple. Colorful. Fun. Throw the balls and get the maximum amount of points in 90 seconds. Don’t think too much, if you don’t score for a certain amount of time you lose the score multiplier. And listen here, the key to be the best: clean shots give you 5 extra seconds of play, maybe using 2 seconds to aim instead of 1 is worth it.


Kung Fu Inc in @gamee

Tap left or right to throw a punch in either direction to destroy… vacuum cleaners?

Kung Fu Inc

Yep, that’s right. I guess somebody doesn’t really like Roombas. Try to not throw punches in the air, the combo multiplier is the key to reach the top of the ranking.


Jumper Frog in @microgamesbot

An old classic not so common nowadays. If you are young maybe you don’t even know it.

Jumper Frog

Jump across the road avoiding the cars and use the turtles and the logs to not fall in the water (just ignore the fact that every frog can swim, we all do). Your objective is to reach the top of the screen and eat every fly in the way.


Flappy Bird

There is more than one Flappy Bird and there aren’t many differences but visual aspect. Play the one you like the most, all of them are equally addictive.

Flappy BirdJumping SubmarineSkipper

Meteoric and Meteoric Plus in @gamee

Combine similar asteroids to form a planet. Combine the planets to create stars. Combine the stars and watch it EXPLODE!

In Meteoric, the asteroids fall from the top and you have to pile them next to their alike to combine them; whereas in Meteoric Plus, the asteroids appear randomly and you drag everything to the top, right, bottom or left (like in the game 2048), if two similar objects collide they will fuse.


2048 in @awesomebot

Speaking about 2048, that is a great game too. Of course we can find it in Telegram.

2048

One of the best games to compete with your friends. But for the love of Cthulhu, keep your highest tile in a corner of the board.


Sumon in @ludeiBot

A target number appears, you have to combine numbers in the board to sum the exact amount. Then, the target changes and you have to do it again until there are no more numbers in the board to complete the level. Easy, right?

Well, you have to do it fast; and it is better if the numbers you combine are far apart from each other. If you are one of those who asks why bother learning to do mental calculus if every mobile has a calculator nowadays, maybe it’s not that easy.

Sumon

Every level concedes notably more points than the previous one. So you might think that playing in a easy level for several minutes will assure you a place in the winners podium, when actually, anybody capable of playing in a harder level will surpass your score in a matter of a minute.


Hextris in @awesomebot

I’m sure you know Hextris. Another of those extremely simple games but incredibly competitive. Share it in your chats, you will see how everybody tries to get the record but “casually, they were just playing in the public transport”. Yeah… suuure… me too…

Hextris

I haven’t even put any effort to get that screenshot, I could do it better…


Do you agree with our list? Did we miss any game? Leave a comment if you found a really good game we didn’t list here. We want to try it, it’s not easy to find them.

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):

How to create a game bot and publish your HTML5 games on Telegram

At Ludei we love HTML5 games, that’s what our motto is. That’s us. We have developed a lot of HTML5 games, from showcases to test our Cocoon.io platform to fully featured games, with 20M+ downloads. On October 3rd the Telegram team announced its gaming platform, a ready to play, easy to build, social and lightweight solution to provide digital entertainment to Telegram users (like us, the Ludei team). As Telegram’sg announcement tells us: “the underlying technology is HTML5…” , we may have an idea here; grass is green.

html5_logo_512

After we checked the examples provided and the documentation, we decided that our bot (@ludeiBot) should be capable of serving our games, setting the user’s score and answering inline queries. All this while being a social bot, that is, our bot and our games can and are going to be easily shareable on Telegram itself. Let’s start!

For the bot creation you must contact @BotFather, answer all the questions wisely and you will have your bot available to the world. 

Botfather logo

Botfather logo

 

When your bot is correctly created you have to register your games on Telegram. A name, a short name, a description and a correctly sized photo is enough for Telegram’s “/newgame” command.

First of all, how are we going to access the Telegram API? A fast Google search returns lots of good and reliable (frequently updated) libraries written in the most modern programming languages. We can choose what to use, there is no problem here. We chose TelegramsBots Java library and the Java programming language.

There are two kinds of Telegram bots depending on how they receive Telegram’s updates. The long polling and webhook bots, for the first prototype, lets keep it simple (KIS(S)). The webhook server requires a server accessible by Telegram while the long-polling bot doesn’t, so we chose the long-polling method for the prototype.

telegram_logo

The first command a bot receives from any user is the “/start” command. Is there a better way to start learning the API? From there we move to our own defined commands, “/list”, “/play” and “/random”.

The list command shows our list of games, so we need to store them before answering the command request but, what is the information needed to send a game to a user on Telegram? The only properties needed to send a game are where to send it and what game we are sending, the “chatId” and the game “short name” (the same we registered when creating our game).

With that information stored on the server, we send a list of games using a custom Telegram keyboard to let the user graphically select the desired game.

Telegram's inline keyboard.

Telegram’s inline keyboard.

When a user taps on one of the buttons we defined, the text written on that button is sent back to the server. We process that message and if it follows a concrete arbitrary pattern (“▶️ gameShortName” in our case) we answer the request which executes the”/play” command of our bot.

The “/play” command does the proper game sending process. To do so, we just call Telegram’s API indicating the chatId and the game’s shortname. We also send a custom inline keyboard in this response with two buttons. The first button must, as the documentation indicates, always be the play button.

We had some problems sending this button because we were a little confused by the documentation stating that the “CallbackGame” value is just “a placeholder, currently holds no information”. When trying to set the callback game with this empty placeholder the button (as our logic expected) doesn’t do anything at all.

After reading our Telegram API library source code, we discovered that a proper game callback does contain some values and after setting up a JSON with a unique field “game_short_name” the button works. Please, check the following code snippet:

The “play with friends” button just shares a URL the way the API shares any other URL:

The last command is “/random”, that just selects a random game and sends it back to the channel it was requested from. Internally, it calls the “/play” command again with the game shortname parameter filled (yay, code reuse!).

There is also another topic: the inline queries. Just name our bot @ludeiBot and after writing this, hit space and start writing anything. If one of our games contains the string you have introduced then that game will appear immediately so you can tap and start playing it.

This can be done thanks to Telegram’s inline mode. Each time a user enters a new character, Telegram sends us a new inline query. We get the query text and look for a game containing that text, we collect all the matching games and we send them back before the user can even notice what is happening.

Wait; a request each time a user changes a character, how many requests are we going to process? Can we answer all those requests fast enough for a nice user experience? We use Amazon’s Lambda for other internal services and we have some experience with it, could our bot be hosted in this extremely useful service?

Again, after a fast search we found lots of tutorials helping us with this concrete need , we just need to set Telegram’s webhook location to an Amazon API Gateway endpoint that launches a Lambda function calling our bot with the received update from Telegram.

Just one Amazon Lambda function is enough to receive all the messages from Telegram, process them and answer all the requests. And all this is done in less than 70 ms without spending too much time on code optimization (this could surely be faster) and without losing time and resources dealing with lateral escalation.

amazon-api-gateway-and-aws-lambda

Another message that must be processed is the callbackQuery that is being produced when the user taps the “play solo” button of our game message. When the user taps the button, we receive a callbackQuery from the Telegram API containing the tapped game shortName parameter indicating which game the user has selected as well as other parameters.

In order to let the user play, we must then answer this callback with the game’s URL and then Telegram will redirect the user to the game’s site and display it in a webview-like environment.

The last requirement is the score sharing functionality. In order to send a score to Telegram’s API, we have to receive the userId of the player who is scoring, and either both the chatId and the messageId from the chat the game is being played on or only the inlineMessageId from which the game has been launched from.

All this parameters are received in the callbackQuery call after the user taps the “play solo” button. Coincidence?, Sherlock doesn’t think that. When answering the callbackQuery you can specify a custom game URL, so you can include the needed parameters in the URL as query parameters.

From the server perspective, we should receive a POST request to the Amazon API Gateway endpoint containing the needed parameters (the userId, both the chatId and the messageId or the inlineId only).

With this information all we need to do is call the setGameScore method on Telegram’s API setting the needed parameters and voilá. The score is shared in the user’s chat room and when the game is shared again in the same chat you can see a beautiful leaderboard instead of the game description.

Ok. Wait, what!? Let’s review how we managed Telegram’s game lifecycle:

  • First of all, a user requests a game through the “/play” command, pressing a button after a “/list” command is issued or through an inline query.
  • When we receive the request, we answer the request with the sendGame function of the API setting our own buttons.
  • When the user taps the “Play solo” button a callbackQuery is received, we must answer this query by sending the URL of our game. It is useful to also send the needed parameters to use the setScore endpoint.
  • When you score in the game a request is received in the server with the needed information to use the setScore function.

Checkout our published games here:

Jumping submarine

Angry piano

iBasket

Sumon

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.

 

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.

myImage.dispose && myImage.dispose(); // The same for canvas and audio objects.

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.

Cocoon.on(“memorywarning”, function() {
  // dispose of cached images and canvases that can be recreated
});

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 Updates For Construct 2 Developers

Ludei has been for several years now serving as a game native hybrid HTML5 app building system for many Construct 2 (and other frameworks) users. A big number from our more than 42,000 developer community have used CocoonJS successfully to release final products to the stores, hundreds of them made with Construct 2. We have provided a good platform for many, but we also understand CocoonJS might not have worked as expected in some situations. We would like to clarify this and help the Construct 2 and other game and app development platform communities to grow and be successful.

First of all, CocoonJS has evolved in the last months. We started focusing just on HTML5 games, where we saw the biggest needs, about 3 years ago. The HTML5 Canvas component was available in mobile browsers and native hybrid technologies (WebViews), but it was slow, fragmented and lacking many advanced features (and still does). We developed Canvas+, a cross-platform technology for iOS and Android that solved many of these problems. But this technology has been built from the ground up by Ludei (yeah, we built a subset of a browser from scratch!) and it wanted to fulfill only one purpose: render HTML5 Canvas 2D and WebGL applications on mobile. It did and does not render any DOM elements apart from Canvas. It lacks many features. We have added some over time (basic HTML parsing, XHR, WebSockets, gamepad, …) but still, it is not a complete HTML5 execution environment. We understand that it can be a hard environment to work with (specially at the beginning) as it limits the HTML5 APIs that can be used. But despite these limitations, it has been used by all our games and by thousands of projects from our developer community that have been successfully published to the Apple AppStore, GooglePlay, Amazon, Tizen, OUYA, etc. Big companies like Disney, Nickelodeon and others have used it too to accelerate and publish their games.

About a year ago we realized that a new trend of HTML5 execution environments were about to be launched. The iOS WebView was getting better in every aspect, even on the Canvas execution (still lacking WebGL until iOS 8, released last week). Google released the source code for the Chromium Project for Android and was announcing a possible inclusion of the runtime inside every new Android. The Cordova community also grew and it has become the de facto standard for native hybrid app compilation. We went back to the roots and tried to include these technologies and as a result, WebView+, the System WebView execution environments and the CocoonJS Cordova Command Line Interface were added to CocoonJS.

Now CocoonJS is not just Canvas+, a HTML5 Canvas 2D and WebGL execution environment, it is a complete set of technologies that developers can test and use in order to select the one that best fits their needs. We have also contributed the WebView+ (Chrome based) to the Cordova community with the CocoonJS Cordova Command Line Interface so anyone can build their Android and iOS (WebView based) projects on their own. Our Cloud Compilation System also provides the option to compile the Cordova project for you, so you do not need to install nor update any SDKs locally.

Additionally, we made all of our CocoonJS Extensions available in any of these new environments (WebView+, WebView) too and of course, if you choose to use Cordova compilations, you can use any Cordova plugins.

Regarding the Construct 2 community specifically, as Scirra has hidden the CocoonJS export option from the latest release, and as we know there is a big part of the Construct 2 community that might still want to use our service, we are providing different solutions:

  1. The latest versions of Construct 2 hides anything related to CocoonJS by default. If you want to still get access to these features, you can do so by specifying to “show deprecated exports/plugins” by right clicking in both the Construct 2 export options and the Construct 2 plugins respectively.

image_02

image_00

  1. A couple of months ago we announced that CocoonJS Canvas+ was compatible with the regular Construct 2 HTML5 Web export option. This means that if you export to the HTML5 Web and still be able to test and deploy Canvas+ based projects. There might no be fullscreen mode when WebGL is enabled in this type of export but if you disable WebGL in Canvas+ and use it’s fast Canvas 2D acceleration, your game should be correctly adapt to the whole screen. Although we recommend option 1, we are also mentioning this possibility for all those developers that do not have the export to CocoonJS option.

image_03

image_01

  1. Remember that CocoonJS is a platform that provides different runtime environments. If you want a phonegap like experience, but still use an improved WebView on Android, you can use our WebView and WebView+ options and compile your Construct 2 HTML5 Web export using both the CocoonJS Cordova Command Line or the CocoonJS Cordova Cloud compiler.

All these runtime environments are available to be tested using the CocoonJS Launcher application for iOS, GooglePlay and Amazon, a great testing tool for your projects.

And we are still working on improving our platform and these are some of the features that will soon be available.

  • We are working hard to be even more Cordova compliant and provide a seamless integration of all our runtime environments in a simple to use cloud compilation service.
  • The cloud compiler will be exposed through a REST API so third party development frameworks can easily access it and provide a unified experience for their developers.
  • A new version of the Construct 2 plugin will be available soon with a new plugin id.
  • A new iOS runtime environment option will be available: WebView+, based on the new WKWebView iOS 8 component. We are experimenting with it right now.

We fully respect Scirra’s decision to hide the CocoonJS related options. Still, we think we need to remember and correctly communicate that CocoonJS is no longer just a Canvas+ execution environment and that still can provide a great final product native hybrid app compilation for many developers (even using Canvas+, used by many!) from Construct 2 or any other HTML5 development framework. We hope to see more and more WebView and WebView+ projects being compiled using CocoonJS!

The future of the CocoonJS Cordova Command Line Interface (CLI)

A couple of months ago we published our CocoonJS Command Line Interface (CLI) that let’s you compile Cordova based projects, which benefit from the Webview+ runtime. Today we want to share with you an approximation of what’s coming to the CocoonJS CLI in the following months.

One of the main tasks we are currently developing is the integration of the command line with our cloud. This will allow you to download projects locally and upload them back to Ludei’s cloud compiler, so the compilations you make with the CLI use all the project data you already have stored in the cloud compiler (e.g., your Facebook tokens, MoPub ad units…).

Another exciting change coming to the command line is the possibility of using Crosswalk as an alternative runtime environment. Crosswalk will join the current Webview+ and Canvas+ as another execution environment for applications made with Cordova/CocoonJS. The main benefit of using Crosswalk is that it has Android binaries for x86, so Android devices running Android 4.x x86 enjoy all the features of a modern browser specifically suited for the underlying CPU.

We will also update the HelloWorldApp/DeviceReady demo that is created when you make a project using “$ CocoonJS create”, so that this new sample app will use different features of the Webview+/Crosswalk to demonstrate the potential of these runtimes.

But remember that you can already benefit from the following features with the current version of CocoonJS CLI.

Already available features of the CocoonJS Cordova CLI

  • The CocoonJS-CLI is agnostic to a specific cordova 3.x version.
  • The Webview+ provides a chromium-based environment for your HTML5 hybrid apps. It will deliver all the power of Chrome and the same look and feel across every Android device on the market. As we promised, Android fragmentation is over!
  • Remote debugging

At this point, these are the tasks that are already in development and you’ll be able to use in the following months.

Roadmap for the upcoming months

  1. Integration with the Ludei’s file system API. (which let’s the user upload it’s local project and compile it in the cloud). No more hassle of setting up and updating the Cordova environment locally.
  2. Different execution environments support (either Canvas+, WebView+, Crosswalk or whatever environment may come in the future) thanks to the compilation in the cloud.
  3. Cloud project management from the command line.
  4. Live reload. This is a great feature that will allow that by just saving a source code file on the server, let the CocoonJS client be aware of the change and update itself “automagically”,  saving tons of time during development.

It seems that the CocoonJS Cordova Command Line Interface will bring many brand new features to our platform, what do you think?

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.