Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
10. August 2012


I received a comment from a Cocos2D-HTML developer saying that the API is complete for the upcoming beta release, so that I could update the tutorials on this site.  So today I jumped in to see exactly what changed and the answer is quite a bit!  In the process of updating the code to work with the newest Cocos2D code, I went through a great deal of pain tracking down those changes.  This post is to illustrate what has changed, so you don’t have to go through the same process.


The code being ported is the example code from this tutorial.



Filename changes


I encountered a few filename changes ( which JavaScript can make exceedingly annoying to find ).  First off, a few files have had their casing changed, which you won’t notice you are working in Windows, but under Linux you will.  Mostly it’s a matter of files being renamed from cc to CC.  Additionally the folder keypad_dispatcher is now keyboard_dispacter, and CCKeypadDelegate.js and CCKeypadDispatcher.cs have been renamed to CCKeyboardDelegate.js and CCKeyboardDispatcher.cs respectively.


Function changes


ccp is now Point

ccc2/3/4/ is now Color2B,Color3B,Color4B

Layer.setIsRelativeAnchorPoint has been removed.

Director.sharedDirector() is now Director.getInstance();

setIsTouchEnabled() is simply isTouchEnabled()

setIsKeypadEnabled() is now isKeyboardEnabled()


Events have been renamed, for example:

ccTouchesEnded is now onTouchesEnded


The Keyboard delegate have renamed events from:

keyDown and keyUp to onKeyDown and onKeyUp

cc.key.[name] is now cc.KEY.[name]

cc.Touch ( the value passed to touch handlers ) has changed from .locationInView() to .getLocation()

cc.AudioManager.sharedEngine() is now cc.AudioEngine.getInstance();

cc.Log is now cc.log


Bootstrap change


This is where the biggest changes occurred.  The startup process is completely different.  First of all, library loading is no longer the responsibility of the  application, it is instead handled by jsloader.js.


This changes cocos2d.js massively:


(function () {
    var d = document;
    var c = {
        COCOS2D_DEBUG:2, //0 to turn debug off, 1 for basic debug, and 2 for full debug
        tag:'gameCanvas', //the dom element to run cocos2d on
    window.addEventListener('DOMContentLoaded', function () {
        //first load engine file if specified
        var s = d.createElement('script');
        s.src = c.engineDir + 'platform/jsloader.js';
        s.c = c; = 'cocos2d-html5';
        //else if single file specified, load singlefile

If you haven’t seen this syntax before, it is basically an anonymous function that will execute at the end of declaration ( because of the () it ends in ).  The majority of what is going on here is the creation of a configuration file ‘c’, where a number of settings are, um, set.  tag is the name of the canvas element in your html file, engineDir is where you installed cocos2D to, appFiles are additional files you write ( in addition to your main.js ).  Basically every file you create needs to be added to this array.  It then adds an event that will be fired once the DOM has been populated, which will then create a new <SCRIPT> tag in your HTML document, then pass in the path to the jsloader, which will then load all of the cocos2D libraries, as well as anything your specified in the appFiles array.  Finally it stores the configuration settings in ‘c’ in the newly created script tag.


In a change I disagree with, the framework now forces you to add a file named main.js, which will be called by jsloader at the end of the loading process.  IMHO, this should be added as part of the configuration you set above.  This file replaced AppDelegate.js from the tutorials.  Let’s take a look at the new main.js:

var cocos2dApp = cc.Application.extend({
    ctor:function (scene) {
        this.startScene = scene;
        cc.COCOS2D_DEBUG = this.config['COCOS2D_DEBUG'];
        cc.Loader.shareLoader().onloading = function () {
        cc.Loader.shareLoader().onload = function () {
    applicationDidFinishLaunching:function () {
        // initialize director
        var director = cc.Director.getInstance();
        director.setAnimationInterval(1.0 / this.config['frameRate']);
        director.runWithScene(new this.startScene());

        return true;
var myApp = new cocos2dApp(MyFirstAppScene);

Things have changed a fair bit here, but the process is pretty much the same.  First thing to notice is it pulls the configuration data ‘c’ and stores it in the variable config, which is then used to setup cocos2D.  The next major thing to notice is we now create an instance of our app, and pass in the scene to start with. 


Now let’s take a look at the changes to MyFirstApp.cs:

var MyFirstApp = cc.Layer.extend({

        var s = cc.Director.getInstance().getWinSize();

        var layer1 = cc.LayerColor.create(new cc.Color4B(255, 255, 0, 255), 600, 600);
        //layer1.setPosition(new cc.Point(s.width/2,s.height/2));
        layer1.setAnchorPoint(new cc.Point(0.5,0.5));

        var helloLabel = cc.LabelTTF.create("Hello world", "Arial", 30);
        helloLabel.setPosition(new cc.Point(s.width/2,s.height/2));
        helloLabel.setColor(new cc.Color3B(255,0,0));
        var rotationAmount = 0;
        var scale = 1;
                if(rotationAmount > 360)
                    rotationAmount = 0;
                scale+= 0.05;
                if(scale > 10)
                    scale =1;


        return true;


var MyFirstAppScene = cc.Scene.extend({
        var layer = new MyFirstApp();


Things have changed a bit here.  First we now extend a scene to create a new object MyFirstAppScene.  This in turn creates a layer and adds it to itself.  The onEnter event is called when the scene is activated ( via RunWithScene ).  Otherwise all of our changes are those described above ( function renames, removal, etc… ).



I hope that helps you port your existing code to the newest codebase.  All of the changes are improvements ( except perhaps the whole forced main.js thing, I still don’t like that ), so it is worth the pain.  I hope to get the tutorials all updated shortly, but unfortunately, these changes more or less will result in complete re-writes of 3 tutorials, so it might take a bit! Sad smile


8. August 2012

I just finished publishing the GameFromScratch 3D Engine round-up.  This is a guide to the top game engines in use by game developers today, that are available to be licensed. There are a total of 20 engines on the list, and for each one it includes the platforms it runs on, the platforms it can target, the price, sample games, the books available if any, key websites ( generally the forum and wiki or documentation pages if available ), programming language supported and example games published with the engine.


I have a similar round-up in the works for 2D game engines, which I hope to publish shortly.  Additionally, I have already published a similar document for HTML5 game engines.  I made the horrific mistake of authoring the guide in Word ( what was I thinking!??! ), and as a result the fonts are a little wonky in Chrome.  Hopefully I can find and kill this annoying trait.


If I made any mistakes, or I missed a key engine, please let me know.  Hopefully you find the 3D engine round-up useful!

News Programming Design

7. August 2012


I wrote sometime back about RIM’s open-source Gameplay SDK.  GamePlay is a complete 3D engine that targets Blackberry OS 10/PlayBook OS, Android, iOS, Windows and MacOS X.  They just announced the release of 1.4 and it’s full of some pretty nice additions:


New features

  • Lua script bindings on all public interfaces of the framework.
  • Script binding generator tool for creating user-defined Lua script bindings from Doxygen XML.
  • AI state machine for AI programming/scripting on game objects.
  • Virtual gamepad input support with custom theming using UI system.
  • Optimizations using NEON math for mobile platforms.
  • Compressed texture support for DXT, PVRTC, ATC and ETC1.
  • Improved modular shaders with support for #include in shaders and new light map support.
  • Optimizations and Improvements to the UI system such as inertial scrolling and scrollbars.
  • Pre-built versions of the gameplay-encoder and gameplay-luagen tools.
  • Optimizations in animation and physics.
  • Fixes to support Maya 2012/2013 COLLADA DAE_FBX export.
  • FBX 2013 format support.


The also announced their roadmap for future versions:

The ‘next’ branch features for v1.5, v1.6, v1.7

  • Linux support.
  • Vehicle physics.
  • AI path finding with navigation meshes.
  • Physical Gamepad input for Xbox 360, Wii, and Bluetooth® HID controllers.
  • Terrain.
  • Scene editor tool.



You can read the full announcement here or head over here to get started.  Lua scripting is a very nice addition, especially for those that prefer not to work at the C++ level ( include me in that camp! ).  Terrain and scene editing tools will go a long way towards helping adoption.


Nice work GamePlay team! 


If I could make a suggestion if anyone on the team is listening, I would recommend a rebrand at this point.  Gameplay is an apt name, but it is incredibly generic, meaning that your discoverability is going to be abysmal.  You’ve created a great product here, it would be a shame that people didn’t use it simply because they couldn’t find it!  Just adding a second word the next name (Gameplay NEXT GameplayGO Gameplay-A-GoGo) would help a ton and allow you to keep your existing documentation, website, etc… unchanged.


2. August 2012


I don’t often get excited about unreleased products, and up until this point I have never gotten all too excited about a Kickstarter project ( although I really look forward to a possible Planescape sequel! ), especially a hardware package that sounds too good to be true.  “The first truly immersive virtual reality headset for video games” is pretty ambitious.


Then I read the quotes:


  • "What I've got now, is, I honestly think the best VR demo probably the world has ever seen"
    John Carmack, id Software

  • "Needless to say, I'm a believer... We're extremely excited here at Epic Games to get the Unreal Engine integrated with Oculus"
    Bleszinski, Design Director Epic Games

  • "I think this will be the coolest way to experience games in the future. Simply that... that big"
    David Helgason, CEO Unity

  • "I’m really looking forward to getting a chance to program with it and see what we can do.”
    Michael Abrash, Valve

  • "It looks incredibly exciting, if anybody’s going to tackle this set of hard problems, we think that Palmer’s going to do it. So we’d strongly encourage you to support this Kickstarter.”
    Gabe Newell, President and Owner Valve

When it come to video game name dropping… that’s a pretty impressive list!


Now about the device itself:


It’s called The Oculus Rift  ( ugh ) and its tentative specs are:

Head tracking: 6 degrees of freedom (DOF) ultra low latency
Field of view: 110 degrees diagonal / 90 degrees horizontal
Resolution: 1280x800 (640x800 per eye)
Inputs: DVI/HDMI and USB
Platforms: PC and mobile
Weight: ~0.22 kilograms


Perhaps most important, and the thing that got my interest, it’s coming out of the box with Unity and Unreal engine support.  That could move it from being a fringe curiosity, to being a device with an actual future.


Ultimately this all came about from their kickstarter campaign, attempting to raise 250,000$ to make developer kit’s available.  Well, that goal is WAYYYYYYY passed, and as of writing they are pushing the million dollar mark. A pledge of 275$ or more got you early access to the device and the SDK, although they are sold out, so I don’t know why I bothered mentioning that! Smile 


That said, pledging 300$ or more gets you:

EARLY RIFT DEVELOPER KIT + DOOM 3 BFG: Try the Rift for yourself now! You'll receive a developer kit, perfect for the established or indie game developer interested in working with the Rift immediately. This also includes a copy of Doom 3 BFG and full access to our Developer Center for our SDK, docs, samples, and engine integrations! (Please add $30 for international shipping)


300$ really isn’t that much, well within reach of many indie developers.  Of course, it’s a pretty big long shot, although if you are working with Unreal or Unity in the first place, the Oculus Rift really isn’t that much of a risk.


What do you think?  Is this the future of gaming?  There were some rumours that next Xbox was going the VR route.  I also seem to recall reading Steam had something in the works too ( ironically, Michael Abrash, who was quoted, was the person I believed was leading the effort).  Personally though, it makes me sick… literally.  I have tried a couple of VR rigs in the past, and beyond a few minutes play I start getting dizzy.  Let’s hope that doesn’t hold true with the Oculus Rift. Oh, and that’s a terrible name.


AppGameKit Studio

See More Tutorials on!

Month List