Cocos Creator RoadMap - UPDATED thru 11/2016

Cocos Creator RoadMap - UPDATED thru 11/2016
0.0 0


Collider components and related events and callbacks is a simple rectangle or circle based collider for detecting simple collision.

Chipmunk physics extension will also be available in July, we have a user who is developing a Box2d extension for Cocos Creator, in case it interests someone, here is the repo:


Oh! Actually by physics things, I meant something like drawing physics bodies on the sprites itself in the cocos editor and attaching it that sprite, just like we’ve in Unity or SpriteBuilder.

By this,

Is that the same you meant or is it some other thing!
Because I think since we’e full access to cocos2dJS engine inside cocos creator we can obviously use Chipmunk physics code in the editor! So, thing coming in July would be GUI for physics?
That would be fun :smiley: :smiley:

Currently, collision for simlple rectangle/circle can be done using getBoundingBox in cocos2dJS,
then what exactly will it be for cocos creator, I mean we already have that, isn’t it?

I went through the github link, but couldn’t understand how exactly it can be tested/used currently :smile:


At least, circle and box collider shapes enough to me for now. (I know, polygonal shape entegration isn’t easy)

The important thing is designing simple collider shapes in the visual editor. Usually, I’m already use box and circle collider shapes instead of polygonal collider shape. (because of performance)

We can do other physics operations in the coding process. (bitmask, collision dedection…etc)

So, all of major game genres needs to designing physic shapes in the visual editor. (Platform, topdown, strategy, beat em up, shot em up…etc)


I had made 2 basic prototypes which had unusual physics bodies and they worked perfectly fine for me.
I had to do some modifications as sizing was issue that I initially faced main problem in…

Why do you find polygon shape integration difficult, I mean how do you do it?
But yes, if some visual physics editor would be integrated then it would be really good.

haha yeah :smiley:


:blush: I’m talking about “Polygonal shape integration with visual editor isn’t easy”. Because you’re designing polygon and after you need to converting triangle algorithm. After you need parse these points in the framework. ( like physic editor solution ) So, they need more time for that then other simple shapes(box and circle).

In fact I think as general; If I use a visual editor, why I need another solutions for main operations? I don’t want to use another physics editor or tile editor solution in the future. One solution, use for all of main visual process. :smile:


Yes, physics extension will include the functionality to draw bodies and attach them.

Of course, hard coded physics works already today, but it’s not integrated with the editor, that’s what we need to do.

The Collider components will provide some basic collision support before that, of course we can already retrieve the bounding box of any node, but sometimes it’s not what we want, we may want a collider just at the bottom of a node. We may also want the possibility to give bitmasks to group nodes as @pococogames suggested


I used this way for my inhouse visual editor (Sometimes I’m working on my simple visual editor for c++ game frameworks as a hobby :smile: )

with snap;

without snap;

Maybe it’s not bad idea. I don’t know. It’s just a idea.

You may add a checkbox for bitmask. Or you may add a simple field. Or we add bitmask code in the script for now after you will think about that. I’m not waiting all of things from you in a short time. :smile:


This is cool. Great. Now explain what did you mean by

Also, I used physics editor UI for windows for doing polygonal physics bodies and it’s easy there.

That’s cool. Are there any plans to build like level editor? because then cocos editor would be new spritebuilder for WINDOWS which I alway awaited :smiley: And I personally feel, like we’ve spritebuilder for cocos2d then there should be something for cocos2d-x/JS too as nonetheless they both are awesome game engines :smiley:


Yep. Physics editor is an easy solution for that. But I don’t like too many json files in the project. (Physics, tile maps, sprite atlas…etc ) I think, Cocos Creator has a potential for doing all of these visual works.


I agree with you. I think you’re correct.


Really cool editor ! we could use this as inspiration.

What did you mean by build like level editor ?

Yes, we will provide a part of the extension workflow in v1.0, and more in the future versions. By then, you will be able to create editing tools in Cocos Creator


Level editor :stuck_out_tongue: like in sprite builder



Would it be open-sourced?


Yes it will be.

@slackmoehrle could you add this to the original post, seems to be a frequent question :stuck_out_tongue:


I might have the privileges to do so :slight_smile:


Cocos Creator is awesome, good job.
I’ve a question, if you plan import coco studio data and you’ll be able to work with c++ , then will you deprecate studio and have only one developer enviroment?



From what I can gather from the interview with Wang Nan over on, Cocos Creator is going to be the primary focus from the Cocos2d-X team from this point forward. But the most important information I have gleaned from the interview and other info at is that it looks like C++ and Lua support with Cocos2d-x will eventually be deprecated in favor of Javascript only when they drop the Cocos2d-x name in favor of simply Cocos. This domain will be deprecated as well once is fully translated to an english version as well.

I think this is the right approach, looking at the direction of technology being more web centric and cross platform. Web technologies are where everything is headed. Desktop will always be around in some form or another, but with cloud storage and even apps being able to be played streaming instead of being locally installed, more and more companies are embracing web technologies to develop all of their applications, so the need for local compiled programming languages is become less and less necessary as it becomes more and more cumbersome to maintain two code bases and higher employees for both C++ and Javascript development to achieve all of their cross platform needs. Of course compiled apps/games will still be the standard on Mobile and Desktop for the foreseeable future, but JSB seems to be the only viable route rather than straight C++ coding in the front end. Keep in mind that the current batch of new developers are not teaching themselves C++, but rather they are learning Javascript in droves.

Cocos Creator itself is written in Javascript, making it quick to modify for specific company usage as well as rapidly writing plugins/extensions and integrating more third party capabilities.

Not sure if the team is ready to post their intensions here in the forum, but it doesn’t take much to connect the dots to come to the conclusion of their ultimate goal when reading over at

Now I don’t think this is going to happen overnight, and I think Cocos2d-x domain will remain around with the ability to continue using C++ and Lua using Cocos Studio until more and more people embrace Cocos Creator, but as soon as there are more downloads and submissions of games using Cocos Creator than Cocos2d-x directly, lets see how quickly it is phased out. It will be a slow death, so current projects shouldn’t be impacted.

Now I could be completely wrong, and interpreted the tea leaves incorrectly, but you can read the interview yourself and come to your own conclusion. This is simply my impression on what I’m seeing over there.


In one of my projects we have effectively merged cocos2d-x with another c++ engine, generated Lua bindings for the second engine and various custom systems and written the majority of the app code in Lua. I would be disappointed to see cocos2d-x take the route of Unity where it tries to do everything for you and dictate a workflow making it very difficult and obtuse to integrate large third party systems.

One of the greatest appealing factors of cocos2d-x for me was its openness and flexibility. Being able to exclude modules I didn’t want such as physics, and only make use of features I really needed. Keeping the application lightweight.

I do completely agree with the changing ‘climate’; that a growing number of programmers have little or no c++ experience and so focusing on a unified JS layer makes a whole lot of sense. However there are still people like myself that value cocos2d-x for its c++ and I hope that side of the offering is not lost in the rush to future proof.


It’s too early to jump to any conclusion about the future of Cocos2d-x community, as it’s an fully open source project, actually nobody can really decide its future.

I totally agree with you, in Cocos Creator, we have no intention to be closed or to force user to follow a book of rules. Actually, we just opened source our engine framework: (You can star it now :wink: )

And if you take a look at the native build folder, you will find it’s exactly the same structure with Cocos2d-JS, you can build with Cocos2d-x in source code or in framework. Then you have full control to your project, extend C++ engine, add Javascript Bindings APIs, add sdks with SDKBOX, anything you want.

It’s not so convenient with v0.7 yet, but in v1.0 and coming versions, we spent and will spend a lot of time to bring users a good experience on extensibility and flexibility.

In v1.0, users will be able to customize templates, engine framework (both web and native). There will also be the first part of plugin system.

In the future versions, we will include a much compact version of Cocos2d-x, a complete plugin system to extend the framework, the editor, even the asset library.

Hope you guys stay with us for the coming versions.


That would be really cool that providing the minimal footprint and include only those things as what you require rather than complete engine or manually disabling at which developers are comfortable but not every game programmer.

Yeah :smile: