Train your Brain with SmartGamesLive!

Jan 10 2013 09:29

Not too often we get feedback from developers about great products and games created with LimeJS. Still sometimes they let us know about their great accomplishments. SmartGamesLive is one of them. The creators of SmartGames have informed us about launching a new online digital platform. For their 20th anniversary they have created 12 online versions of their most popular in real life boardgames.

You can play more than 1400 brain teasing challenges in 4 different levels of difficulty. Of course in true spirit of LimeJS you can play all the the games in full-screen mode on your desktop or mobile device.

You can find all the games in SmartGames homepage:

Play Voodoo Friends

May 22 2012 08:22

If you want to see what it’s possible to make with LimeJS or just want to have fun playing a good game then check out Voodoo Friends. It’s an awesome platform puzzle game built by Danish game developer Cego. And of course its built with LimeJS.

You can play it in the browser at Chrome Web Store:

Or get it for your iPhone or iPad from the App Store:

Cego developers have also been active contributors to LimeJS on Github, adding new features and fixing bugs. So big thanks to the team and congrats on the launch.

Cognuse cures brain injury with LimeJS

Jun 30 2011 08:21

Developers from the medical start-up Cognuse have been developing new generation cognitive rehabilitation platform for restoring and training executive functions after a brain injury or stroke since 2006. Their method consists of set of games specially designed by specialists of the brain injury area, that patients have to repeatedly play through. System stores their results and provides new harder levels based on their performance. Platform can be also used for general cognitive training to battle the cognitive decline in the elderly population, including people with a tendency to develop Alzheimer’s or similar diseases.

Stroke support has landed

May 12 2011 19:08
Tags: strokes

The stroke support was one of the top features developers have asked from us. Starting from today you can finally add strokes to your shapes. All shapes and renders are fully supported, you can add both fill and stroke to a shape or use them individually.

The API is very similar to adding fills. All shapes have new method setStroke(). Like the setFill() method it can accept parameters in many forms. You can pass in an instance of lime.fill.Stroke or just pass in stroke width and color. For color all the same parameters are accepted that you previously could use for color fills.

// All of the following are valid ways of adding a stroke.
sprite.setStroke(5,'#c00'); //5px red stroke
sprite.setStroke(5,0,100,0,.5); // semi-transparent green
var redline = new lime.fill.Stroke(2).setColor(100,0,0);

If you need to remove previously set stroke call setStroke(null). The same technique can be used for fills.

Below you can find a simple demo….

WebGL API description

Apr 12 2011 12:26
Tags: webgl 3d

In this post we are going to dive more deeply into the WebGL library methods that are included in the LimeJS WebGL branch. Those methods are used while making the lime.Renderer.WEBGL renderer and are available for developers to create custom WebGL games.

What it is about:

  • Cleaned up workflow. No more multiline inlining shaders.
  • Object oriented API. C style turned into JavaScript style.
  • Complete handling of format conversions. No need to convert something to another format before sending to WebGL.
  • Debugging support. Get error messages for invalid inputs, instead of black screen.
  • Make it easier to work with big models.
  • Math utility helpers
  • Getting out of your way and letting you concentrate on your shaders.

What it’s not about:

  • A simplified or alternative way of making 3D
  • A higher level abstraction layer.
  • You still have to know how OpenGL works. You just have to code less and get your work done quicker.
  • If you need a Closure port of something like three.js of GLGE this is not it.

The API:


GLController is front controller object for your 3D Canvas context. You can use controller object for storing data you need persistent for your context. It also provides method for resizing the viewport. Only real reason for this class existence is that we don’t want to modify the context object itself.

Static Methods:

  • GLController.forCanvas(element) - returns GLController instance for Canvas element. Always returns same object for same element.


  • getSize() - get current canvas and viewport size.
  • setSize(size) - resize canvas to new values and also resize WebGL viewport to same size.
  • makeProgram() - Return new Program object for the context.
var glc = lime.webgl.GLController.forCanvas('mycanvas'),
    gl =;



Program connects the shaders to your code. You use it to initialize your shaders, set shaders properties and draw. Program object accepts data in almost any reasonable form and converts between formats if necessary. When you pass in data in wrong format it will let you know about the error and …

WebGL is coming

Mar 30 2011 15:24

WebGL is a new open technology for building HTML5 games. I enables developers access to lower level graphics APIs allowing high performance and 3D transformations. All fully hardware accelerated. WebGL is based on OpenGLES 2.0 and it basically works in three steps. First you write small shader programs and send them to be run on your graphics card. Then combine your vertex/color/texture/etc data to the data buffers and send the buffers to the graphics card. And finally tell your graphics card to draw the data inside the buffers using the shader programs. Good introduction to OpenGL ES 2.0 can be found from Jeff LaMarche blog. Luckily you don’t have to know everything about WebGL to use it in LimeJS. The WebGL renderer can be used as a simple on/off switch with no further knowledge needed. As an extra we will include Closure Library style WebGL framework methods that we use for writing the renderer so you can use it for your custom WebGL related work.

You can follow along WebGL related development in the WebGL branch on Github. Its not in any way stable or feature complete at the moment but may be interesting for you to follow along when features appear. This also means that we are very open to suggestions about all aspects what it should do, what it should not and how it should be implemented. As there is no features yet marked ready there is a very good change your own idea can make into it.

The main benefit WebGL gives is …

Is HTML5 the future of (mobile) gaming?

Mar 18 2011 08:50

According to TechCrunch  HTML5 Is An Oncoming Train, But Native App Development Is An Oncoming Rocket Ship at least that’s what it advocates and believes strongly, the same time Google’s Eric Schmidt is quite convinced that HTML5 will eventually dominate almost all apps. Its very old debate and probably truth is somewhere in between. But as technology advances and developers get more and more aware of possibilities, I think we’ll start to see some serious competition coming from web-based game developers.

Main promise is to write it once, and have it run everywhere. Its still “the promise”, since game creation with HTML5 is still not painless and has so many platforms and devices to deal with, that’s what we would like to change rapidly with LimeJS. Every day brings us closer and closer to situation where programmer has to deal only with creation of game and not technical problematics around it.

We at Digital Fruit are convinced that HTML5 is a outstanding technology for mobile (and even desktop gaming). That’s why we invested considerable amount of time to create LimeJS at first place. It can be used right now with already existing skills: developers just need to make right decisions and understand limitations of technology. HTML5 can be used to make games and achieve a outstanding user experience. In the end, that’s what really matters and what will make apps success or fail.

Major benefits of HTML5 (and in our case specially benefits of LimeJS)?

  • You already know how to use it
    Generally, web development and JavaScript skills are also much easier to find compared to native development skills. Expected costs will be lower and development can probably start faster. Native app development is not only difficult but it’s also expensive.
  • Cross platform
    If you’re planning to create native mobile apps then you have to support on minimum level at least iOS and Android. That means two completely different languages: Objective C and Java. Using LimeJS (or any other advanced JavaScript game framework) the app will be usable immediately across a range of devices and operating systems (there is still no Nokia/Symbian and never will). You will reach even further: all major mobile and desktop browsers are covered. Many smart-phone browsers are getting better support for HTML5 and that’s only going to improve rapidly. Also you can instantly add Facebook to current list of supported platforms as I believe it is clearly platform its own (even if its run from browser). Facebook is also encouraging people to get into HTML5 gaming.
  • Social
    In essence there is nothing social in HTML5 but as server clearly exists, it’s not too complicated to add social interaction there.  
  • Speed of development
    Where HTML5 game development with LimeJS really excels is it takes considerably lot less of the time (compared to a native app) to get it ready for market. Add here cross-platform and you got real winner here. Native apps are like fossil fuels - they are useful and readily available today but they will finally lead to less desirable outcome.
  • Dynamic distribution
    This is part where HTML5 really shines - it’s possible to change content on the fly without requiring any additional lengthy approval process from Market/AppStore.  It allows really fast content (and even interface) update without any additional requirements but network connection.
  • Optional installation
    HTML5 apps can be distributed any way creator wants - via Market/AppStore or just via the browser. Users are not required to install anything, all they need is modern HTML5 capable browser.
  • Strong support of market leaders
    HTML5 is pushed by big companies like Google, Facebook and Apple so it will not disappear any time soon and only thing what happens it gets more and more support over time. All major browser vendors(including Microsoft) see HTML5 as their biggest goal. RIM and HP(Palm) have made Javascript as a built in way for creating native applications for their mobile devices.

Limitations of HTML5 games

  • Performance
    Regardless of advances in HTML5 developments and frameworks, HTML5 based games are still slower compared to native code based cousins. In near future it will change significantly as technology advances very fast. Only clear drawback I can see is that low-end smart-phones are on the rise and they do handle complex graphics not that well as high end ones do. Not everyone gets the same smooth experience (but this is equally true for native apps so no clear winner here). Luckily hardware acceleration and WebGL are already appearing in latest browser version pushing the speeds very close to native performance.
  • Inconsistent implementations
    HTML5 specification in still in draft state and some related technologies have very different level of support. Some browser makers try out their own ideas, some don’t like the ideas proposed by their competitors. This turns your code into device specific hacks and makes it less likely your game will still work with newer versions. Using a framework is a must to avoid such situations.
  • 3D
    It’s probably fair to say that if you want to create a full 3D experience with 3D transformations and shading today with HTML5 then it would be quite difficult. But if you want to create an optimized, bare-bones 3D then JavaScript engine that supports translations and rotations can do it quite well. There is however possibility to get next level with 3D  - namely WebGL. Luckily hardware acceleration and WebGL are already appearing in latest browser version pushing the speeds very close to native performance.
  • Integration
    peer-to-peer networking is still currently not available for HTML5 (there are some workarounds). But then again, you can develop a hybrid app which uses very little native code and relies mostly on HTML5.
  • Monetizing
    Monetizing the game of HTML5 will be exactly like it is today for anything else. If you want to make income then native app development is still the most logical way to go but its slowly changing. Also with ad-supported model there is no notable difference. You can also take a WebView and package  it to a regular native shell and you have a “native” app (which is really just a web app), that’s pretty much what Netflix did for the iPad.

How to gain maximum with LimeJS

  • Hybrid HTML
    HTML5 vs native is not an “either/or” decision its much wider view of things. Follow principles set by Netflix to use HTML as far as it is reasonable and if needed do the rest with native/hybrid app
  • Package it
    On iOS you can bookmark your app directly to desktop and from there for average user there is no difference if its native app or HTML5 creation. In Android things are a little bit different - Android does not allow to create headless browser experience “out of box”, so only way to do is to package it (with PhoneGap or something similar)
  • Offline content
    One notable property of HTML5 is great support for local storage. It makes possible to your user to go offline and use app without any data connection.
  • Look & feel you want
    you are not limited to “usual and native” interface look, in fact you can and should adjust everything according your own game centered needs - LimeJS has all needed tools for that
  • Think big
    LimeJS is created real games in mind, its not for making demos nor it is collection of “hacks” - everything is systematically thought trough to give game creators freedom and tools to create true game experience and keep everything maintainable.

Why we in Digital Fruit believe that HTML5 will be the definite future of mobile (gaming)?
We strongly believe that in 2-3 years from now, majority of games (and apps) on mobile devices will be based on HTML5. Right now HTML5 gaming may be is still playing “catch-up game” but technology is progressing extremely fast. There is a really big and growing demand for multi-platform world in which most major mobile platforms (iOS, Android, Windows Phone 7 and Blackberry) are very serious for a significant market share. It will be clear that most companies will not be able to afford that many parallel development teams and supported platforms. If you think of a cross platform software layer for Internet applications what would be supported by all vendors, anything other than HTML does not make sense. Sure Flash can do some nice tricks better in the moment (specially on desktop as iOS still lacking support for Flash and on Android its nothing more than proof of concept) but if you think about the future there is no way a proprietary plugin can be something that fulfils all vendors need for better apps.

Currently HTML5 is not yet the best thing in the world, but all this will change rapidly over short time. HTML5 is the way browsers are heading, and they’ll all just get better and better. HTML5 is most definitely future of gaming on touch devices.

Olavi Tõnisson

Making flexible views

Mar 09 2011 22:03

While creating games with LimeJS you don’t have to think about the different screen sizes your players will be using. In the beginning of your game you just have to define the stage size and we will take care of that you game appears in maximum size on both HD monitors and on an iPhone. This enables you to use fixed positions and sizes, much like in Flash. When the display size or device orientation changes you don’t have to recalculate your game elements positions as your stage is still same size, although it appears visually bigger on the screen.

This all happens automatically for screen sizes. But what should you use when your element itself transforms or elements parent element is resized?

AnchorPoint - handling element’s own tranforms.

AnchorPoint lets you define the location in your element that is most important for your game object. When you position your element this is the point that is put on the exact position you give in ‘setPosition()’. The element rotates around this point when you use ‘setRotation()’. If you scale an element this location remains in its position and everything around it is scaled. All children of the element are by default positioned by the parent element’s anchor point….

Using KeyframeAnimation for fill effects

Mar 03 2011 21:48
Tags: demos

Some posts ago we showed how to use KeyframeAnimation in the normal way. That is by making a SpriteSheet image and using separate areas from that image as separate frames in the animation. But theres a bit more in it. The ‘addFrame()’ method can actually accept any kind of fills. Depending on what you wish to achieve this may give you a way to have some animating objects without using lot of images.

Please note that following can not be counted as a major feature of LimeJS but rather a side effect that we are happy about.

Starting with the simplest fill types here is the animation using plain colors as fills. All syntax is the same. Just pass the color name to the ‘addFrame()’ method.

var sprite = new lime.RoundedRect().setRadius(10).setSize(50,50).setPosition(100,200);
var anim = new lime.animation.KeyframeAnimation().setDelay(.5).

This creates….

New formats for SpriteSheets

Feb 27 2011 20:25

There has been some new features added to SpriteSheet functionality. In addition to the Zwoptex Flash format LimeJS now also supports the newer Zwoptex (cocos2d) format and JSON format present in TexturePacker. While you could use trimming before you now can pack your files even more by using rotation switching.

We have put a parser logic for each format in the special object that needs to be included with goog.require() and passed in to the SpriteSheet constructor as a third parameter. All currently supported parser objects are:

  • lime.parser.ZWOPTEX - Original Zwoptex format, also known as Zwoptex Flash format or cocos2d-0.99.4
  • lime.parser.ZWOPTEX2 - New Zwoptex format, also known as Zwoptex Generic or cocos2d
  • lime.parser.JSON - JSON format that can be exported from TexturePacker

So your new code may look…