This page contains documentation around CocoonJS and mini tutorials around its use, more specifically with Kiwi.JS. This tutorial assumes you already have some basic knowledge of Kiwi.JS already, so if you need more tutorials on Kiwi.JS then you can go to our getting started section.
Developing Kiwi.JS with CocoonJS
Kiwi.JS is a HTML 5 game engine which has been designed to work in browsers (Chrome, Firefox, e.t.c) but also has been designed to work natively on Android and iOS devices by utilizing a technology called CocoonJS. You can read more about CocoonJS here.
Whilst developing Kiwi we have tried to make the difference between the use of Kiwi in CocoonJS and normal browsers as seamless as possible, there are a few things you have to be aware of and to make sure you do when developing for CocoonJS, which we have listed below.
Target CocoonJS
When you are creating a Kiwi.JS game for CocoonJS you firstly need to tell Kiwi.JS that it is going to be used in a CocoonJS environment.
|
1 2 3 4 |
var gameOptions = {}; gameOptions.deviceTarget = Kiwi.TARGET_COCOON; var game = new Kiwi.Game( null, 'GameName', null, gameOptions ); |
The code above sets the device that the game will target to be Cocoon.
The reason you need that is because Kiwi is designed to primarily work in Browsers, and as such Kiwi.JS use’s the DOM to create elements and apply CSS to those elements for sizing/positions. Now when we were developing it for CocoonJS, we have wanted to get the best performance as possible, so we have/are making Kiwi.JS compatible with Cocoons Canvas+ mode. Which is an accelerated environment. Meaning it is faster that the Webview+ mode (which functions like a normal browser) but doesn’t support much of the DOM or CSS properties that browsers do.
No HUD Support
In Kiwi.JS there is a HUD section which is currently not supported when targeting CocoonJS. This is because the HUD is based around the DOM and uses it to create and style various HUDElements and the type of DOM Manipulation we use for that is currently not supported in Canvas+.
Why is the whole HUD stuff based on extra DOM elements anyway? Is there a specific reason for that? From what I see all of this might have been done with the canvas as well.
Good questions Alex. The main reasons we have used DOM elements for the HUD section is because browsers already provide a lot of default functionality through the DOM, which can be very useful in your game. For example, if you wanted to have a form in your game where the user has to input data then you could make use of the ‘input’ element. You can then style that element using CSS (and sexy CSS 3) very quickly. That way we don’t have to recreate, what browsers already do well.
Also on that note, rendering text in canvas is a slow process.
Now you are completely correct also, some of this could have been done with the canvas element and it still can be. A CanvasHUD plugin could always be created, or for now you could use GameObjects and update their position to match the inverted position of the camera.