C++ support for Cocos Creator

I’ll work on adding C++ support for Cocos Creator.

This thread will be my “personal blog” about it.

1st impressions:

  • Cocos Creator is NOT 100% compatible with cocos2d-x.
  • It uses a component based model to build scenes
  • it supports JavaScript scripts
  • it has its own “nodes” (prefabs)
  • project files are saved in a “.fire” (json format)
  • We recently added Lua support, which means that from cocos2d-x + lua you can run “.fire” files with certain limitations.

So, my plan is:

  • Generate an intermediate file out from the .fire files. Most probably an python script. This script will do all the hard work. Basically converting the component-based scene (cocos creator) into a node-based scene (cocos2d-x)
  • Not all prefabs / components will be converted. Raise a warning when that happens
  • Learn from the Lua support files, since they already triggered those limitations. Unfortunately they are not generating an intermediate file. Instead they are parsing the .fire files in runtime.

Basically I start prefab by prefab and see what can be converted and what not.

##Labels

It is composed of a Node + Label Component.
It is not easy for me to differentiate a Node from a Component.
As far as I know, the Nodes have an _id, but Components, don’t.
Also, Nodes can have Components, but Components can’t have Components.

Node have a container with all its Components:

  {
    "__type__": "cc.Node",
    "_name": "Label",

    "_components": [
      {
        "__id__": 7
      },
      {
        "__id__": 8
      }
    ],
}

But Components don’t have id. Instead, what they have is node which is a reference to the Node that contains them.
eg:

  {
    "__type__": "cc.Label",
    "_name": "",
    "_objFlags": 0,
    "node": {
      "__id__": 6
    },

Some properties start with N$ which I have no idea what’s the meaning of that. eg:

    "_N$file": null,
    "_N$string": "This is another label",
    "_N$horizontalAlign": 1,
    "_N$verticalAlign": 1,
    "_N$overflow": 0

Besides that, Label seems pretty straightforward to support.

##Sprites

Similar to Labels: Node + Component.
The Component has the type cc.Sprite:

  {
    "__type__": "cc.Sprite",
...
    "_spriteFrame": {
      "__uuid__": "4f39fc84-eaed-4f05-95ff-f636066e8de8"
    },
...
  }

And the frame is defined in a “meta” file which is also another JSON file.
It has the following format:

    "grossini_dance_08": {
      "ver": "1.0.3",
      "uuid": "4f39fc84-eaed-4f05-95ff-f636066e8de8",
      "rawTextureUuid": "4e2edada-a2d6-4635-afdf-c426810de768",
      "trimType": "auto",
      "trimThreshold": 1,
      "rotated": false,
      "offsetX": 0,
      "offsetY": -1,
      "trimX": 17,
      "trimY": 7,
      "width": 51,
      "height": 109,
      "rawWidth": 85,
      "rawHeight": 121,
      "borderTop": 0,
      "borderBottom": 0,
      "borderLeft": 0,
      "borderRight": 0,
      "subMetas": {}
    }

And the filenames are the ones that associate them. eg:

$ ls -l
-rw-r--r--  1 riq  staff  6745 Sep 15 18:35 MainScene.fire
-rw-r--r--  1 riq  staff   146 Sep 15 18:35 MainScene.fire.meta
-rwxr-xr-x  1 riq  staff   758 Sep 15 18:34 grossini_dance_08.png
-rw-r--r--  1 riq  staff   690 Sep 15 18:34 grossini_dance_08.png.meta

So the file “grossini_dance_08.png” has its frame definition in “grossini_dance_08.png.meta”.

So, supporting sprites seems straightforward, like a Label.

UPDATE: The file “library/uuid-to-mtime.json” has the mapping between UUID and file.

##Splash Sprite

Not sure what’s the purpose of this Node, but it seems almost identical to Sprite. I’ll as the CocosCreator team.

##Particle System

Similar structure: Node + Component.
The ParticleSystem has a “file” that describes the particle.

    "__type__": "cc.ParticleSystem",
    "_file": {
      "__uuid__": "b2687ac4-099e-403c-a192-ff477686f4f5"
    },

and in “library/uuid-to-mtime.json” it is described as:

  "b2687ac4-099e-403c-a192-ff477686f4f5": {
    "asset": 1471599381000,
    "meta": 1471599381000,
    "relativePath": "particle/atom.plist"
  },

but I couldn’t find atom.plist anywhere.

So, once this missing-atom.plist-file is solved, it should be straight forward to support it.

##Tiled Maps

Node + Component. Seems pretty straightforward to support it.

17 Likes

I’m down for testing and writing docs!

4 posts were split to a new topic: Getting Started with Cocos2d-x

SpriteBuilder is a very good editor, but as far as I know it is only for cocos2d-iphone and also it is no longer maintained.
CocosCreator is JS oriented, I guess, mostly to satisfy the Chinese market.

What are you planning to support?
Just importing the Node structure in the same way CocosBuilder and CocoStudio are currently supported?
Or are you looking for somewhat more integration or additional features beyond what C.Studio allowed?

Lua extension also generate a intermediate file via a python script. They convert .fire into a .lua file, and this .lua file include infos in lua data structure.

Perhaps this is a temporary file that is created during the initialization phase.

@walzer yes? great. Where can I get the python script? I don’t want to re-invent the wheel if possible.
I talked to Jare yesterday and he told me that they are parsing the .fire files directly from Lua, but perhaps it was a misunderstanding.

@stevetranby
Yes, more or less that. Unless somewhat has a better idea.
My idea is to parse the .fire files, and if possible generate a cocosstudio file so that I don’t have to create yet another reader for cocos2d-x.

@ricardo Might be interesting to have someone create a live node hierarchy export writer into .fire as well then? The more data can be transformed the better?

Another ideas probably futile idea: transliterate javascript snippets into c++, write all out to a component_behavior_generated.cpp (single file) or similar (folder of files named with the javascript filename, etc). Then massage this along with the event names (function, actions, selector, whatever its called in CocosCreator).

Anyway, I’ll take a look at your first draft solution and consider these to try and determine feasibility.

This is amazing! :slight_smile:
So… If I have cocos studio project… I have to import it to cocos creator and then using your script generate it back to .csb files :smiley: ? This is a bit ridiculous cocos team can’t just generate .csb files from cocos creator and it’d be done.

@ployee indeed :smiley:

CocosCreator WILL have an export to .csb “directly” with this though, under the hood it’ll write out to .fire and translate to .csb. It’s to eliminate the requirement of writing a .fire parser/loader at least for now.

It’s effectively do you want c++ support now or next year :smiley:

The previous solution of Lua extension will process json files which generated by the Build button of Cocos Creator.
The convert script is creator-lua/tree/master/lua-project/src/convert-creator-build.lua, and you could find it on the repository I sent you. It is a Lua script, but not python, :slight_smile:

Fire file could be an option, but it includes too much data of editor. The benefit is that you don’t need to generate data with build processing all the time, and could get data when you save the scene.

YuLei is working on automating the workflow. I will ask him to sync up information here.

Sorry, I didn’t get that. What do you mean by “live node hierarchy” ? You mean exporting directly from Cocos Creator (without parsing the .fire files)?
If so, yes, that’s was my original proposal: Cocos Creator should have plugins and 3rd party extension could browse the scene graph (and other objects) and do whatever they want with that data… like creating a exporter to whatever they want, or even transforming the scene graph.

But right now it is more important to have the C++ exporter than to have a polished API for 3rd party developers.
So, the easiest way for me is to parse the .fire files.

Rearding parsing JavaScript snippets… well, that seems hard.[quote=“piotrros, post:21, topic:32143”]
So… If I have cocos studio project…
[/quote]
Probably you should keep using it.[quote=“ShunLin, post:23, topic:32143”]
YuLei is working on automating the workflow. I will ask him to sync up information here.
[/quote]

great!

@ricardo I didn’t work on Js side until today. But I have an idea. Why you don’t export all of scene as a c++ class format.(with parsing on Cocos Creator)

1-We open Cocos Creator and designing scene.
2-File->Export->Cocos2d-x Scene Path

So after we have two files;
sampleScene.h
sampleScene.cpp

And you may use js binding feature of Cocos2d-x for physics or another companents on Cocos Creator.

So I think c++ developers just want to level design, physics editing, managing project and assets…etc

C++ workflow isn’t just like Js workflow. We working more slow then high level sides because of compile times.

2 Likes

that’s an interesting option. thanks.

1 Like

@ricardo yeah I was a bit cryptic since that was a very stream of consciousness. Hope this reply clarifies it a bit.

Live Node Hierarchy - Create a Scene, add some Nodes with children in code using Scene::create, Node::create, and node->addChild. Take the scene or any node in the hierarchy and be able to export a .fire (or equiv) file based on the properties of the runtime node itself along with its children. Node::ExportAsFireball(node, "filename.fire"); or whatever. Similar to TMX writer, etc.

Similar to @pcocogames my thoughts on having CocosCreator export more c++ friendly files is not difficult and should be fairly straightforward. Either directly to a known loadable format (.csb) or by writing out c++ directly.

I was thinking less about Javascript->C++ per se and more that you could write “scripts” in the editor as small snippet in the chosen language and for c++ it would just combine all the snippets into the “event” functions (onLoad, etc) into a single generated .cpp/.hpp file set.

1 Like

Aha, brilliant. You absolutely can ask Shun to get the script!

Interesting plan, but does it mean a Cocos2d-x C++ project keeps its current directory structure and will not be unified with what Cocos Creator uses? I had a hard time due to the situation of Cocos Studio and Cocos Creator, if switching to the project structure of Cocos Creator is not necessary it’s cool, but if the current Cocos2d-x structure is deprecated in favor of Cocos Creator in future, sooner is better as we don’t want to go back and forth.

Since it looks like a one-way C++ exporter for Cocos Creator, if you add your own event handler code in C++ to exported C++ scenes, you have to port such modification each time you modify your Cocos Creator project and export it to C++, is it correct?

quick update:
In this repo I’m putting my tests: https://github.com/ricardoquesada/CreatorTest
this is the script: https://github.com/ricardoquesada/CreatorTest/blob/master/parser.py

for the moment it does almost nothing, but it has the structure which is important. Now it is time to do some boring stuff and import the properties and print them correctly.

Yes. This is just an exporter. It will generate the needed files to load a CocosCreator scene in cocos2d-x.

2 Likes