Hi everyone!
I’d like to know more about the inner workings of Cocos Creator.
First let’s talk about what I believe to know already. So feel free to correct me if I’m wrong.
cocos2d-x is a game library written in C++.
cocos2d-js is a JavaScript binding of cocos2d-x.
Cocos Creator is a desktop software that provides a visual editor alongside an engine using cocos2d-js.
So here are my questions:
Does Cocos Creator is a web application embedded inside some kind of wrapper (like electron as the youtuber GamesFromScratch assumed) or is it a native desktop application?
Does Cocos Creator exports projects natively to HTML5 or does it use some conversion tools like webassembly or something like that to convert a native C++ app (from cocos2d-x) to HTML5?
In fact, I want to know if HTML5 export is a pure JavaScript application or if it relies of a native transcompilation.
Finally, does Cocos Creator exporte projects natively to Desktop or does it export to HTML5 then converts it to a desktop appliction with eletron or something like that?
How does JavaScript executes in desktop application exports? Since browsers come by default with a JavaScript interpreter I assume it is no problem for them but what about desktop projects? Do thos projects embed with them a JavaScript compiler?
All those questions come from the same issue: performance and size. What is the most performant platform for project exports? What is the most lightweight? Which platform is the native target? Which ones come with intermediary tools?
Please try to be very exhaustive in your answers (even giving me reasons for those design choices) for me to better understand what compromise I have to make for each target.
Thanks in advance.
This is not true. Cocos Creator and Cocos2d-js are not closely related or similar. Different API’s all together.
Creator is an Election app.
Creator exports to native, not c++.
Speed and size are items we work on all the time. The v2.2 release just improved these even more. See the post here on these forums for details and numbers.
This is not true. Cocos Creator and Cocos2d-js are not closely related or similar. Different API’s all together.
OK. I got that. Cocos Creator and cocos2d-js aren’t related. So my initial assumption was wrong.
Creator is an Election app.
Do you mean it’s an Electron app?
Creator exports to native, not c++.
To “native” what? You have to be more specific. Native HTML5 app? Native Desktop app? If it’s an eletron app, I assume Cocos Creator is developed in JavaScript. So maybe it’s easier to export a project to the web than it is to export to native desktop?
Speed and size are items we work on all the time. The v2.2 release just improved these even more. See the post here on these forums for details and numbers.
You could have put a link to the post you’re refering to. Obviously, the development team is always working to optimise things further. I guess it’s their main target. I only wanted to know what parts of the engine may bottleneck a project.
You didn’t answered my questions about exports architecture.
What comes with each platform export in addition to the game? Any libraries?
What Cocos Creator uses for web export? cocos2s-js? Some custom JavaScript library?
What Cocos Creator uses for desktop export? cocos2d-x? Does it uses dll files or is it a standalone file?
@jare, could you answer these questions, please.
@flashjaysan, @jare can give you better details as Cocos2d-x and Cocos2d-js are not in the mix here. Cocos Creator uses a special Cocos2d-x-lite engine.
Cocos Creator uses a special Cocos2d-x-lite engine
What does it mean? CC uses typescript as a scripting language so people would think that engine is native to HTML5/Javascript naturally. Is this correct?
E.g: In Unity the C# code => IL => C++ => Emscripten => Js, so the performance of Unity is very bad.
I wonder if CC is better for web platform.
I’m making a physics based game with Cocos Creator 1.9.3 if you want to check it forum post here:
I had a lot of chances to test Cocos Creator’s performance with this game project. It works flawlessly with more than hundered physics objects dozen of joints and most of them reads joint force and torque each frame to decide to break or not in update method. I’ve successfully played the game on Galaxy Note 2 ( Android 4.4.2 - Release year 2012). I have a generic save/load system which holds all physical properties of objects and components and in compressed and encrypted format. It take 2-3 seconds to read/compress/encrypt save data on Note 2 phone. Lightning fast on todays phones.
Native:
Cocos Creator uses JSB to bind javascript functions to C++ on native, hard work done by native code on mobile and desktop, not a web embedded app like cordova. It uses native power of processors.
Web Browser:
It compiles to pure Javascript for web. There is nothing between javascript code and the browser. Works perfectly performant.
Compiling to any platform is nearly same and simple. Not easier or harder to compile for web or android. My unexperienced cousin had succeeded to compile for iOS in several hours.
Summary:
You’ll not have any performance bottlenecks with Cocos Creator. You can customize the open source engine if you need later like I did for my project in save/load system.
Hope it helps 
I have been digging around Creator’s inner workings for quite some time now and this is how I understand it. Please correct me if I am wrong at any point as I too would like to fully understand how it works.
A good starting point can be found in the Cocos Creator’s manual, engine customization page:
https://docs.cocos2d-x.org/creator/2.2/manual/en/advanced-topics/engine-customization.html
So, the Cocos Creator consists of several part:
Cocos Creator editor – Electron app used for scripting and making/editing the game while using the underlying engines to publish the game.
JavaScript engine – JavaScript engine which is a forked and evolved/enhanced version of Cocos2d-html5. Used when publishing to web platforms.
Cocos2d-x-lite engine – C++ engine which is a forked and trimmed/enhanced version of Cocos2d-x 3.9. Used when publishing to native platforms (iOS, Android, macOS, Windows).
Cocos Creator adapters – JavaScript adapter and mini-game adapter (this one I have not examined much).
Taking all that into account, the publishing process looks like this:
Web platforms – all scripts made with the editor are bundled together with the JavaScript engine which in the end produces a web HTML5 JavaScript powered app.
Native platforms – the Cocos2d-x-lite engine is compiled into binary executable and all scripts made with the editor are connected via the adapter to the compiled engine so that the game objects can be created/edited/controlled. Similar to how Cocos2d-x has JavaScript scripting functionality.
Now I apologize if I slightly derail the topic with my own question, but I think it is not worth opening a new one as it is quite related to the OP’s question. It is related to similarities and differences of the Cocos2d-x and Cocos2d-x-lite engine.
When the Cocos Creator was just made with v1, it used the Cocos2d-x 3.9 as a base for its own lite version which had many functionalities removed such as 3D, deprecated classes and functions, Lua, camera and so on and so forth. This all made perfect sense as at that point, the Cocos Creator looked like it is going to be a streamlined light version of Cocos2d-x with 2D only in mind and mostly oriented for web platforms.
Now with v2, I see a lot of these functionalities to be back mostly the 3D stuff. And checking the lite’s source code, it seems it has changed the flow and architecture of how it works probably to better fit the ECS paradigm.
So now we have:
An older Cocos2d-x engine with lots of backwards compatible functionalities from the past, is in process of being moved to Metal supported renderer, does not have an official editor and is being updated at a slower pace.
A newer Cocos2d-x-lite engine which is primarily used as the backend of Cocos Creator (I do not know if it is capable of being compiled as a standalone app like Cocos2d-x), developed with ECS in mind, does not seem to have Metal support, has an official editor (Cocos Creator) and is updated very rapidly.
So this brings me to the following question: why are these engines being developed in separate lanes when at current versions they are quite similar in functionalities, but have some extra functions, and would it not be better and wiser to merge them into one engine that has the functionalities of both and can be used as standalone engine (C++ code only) or with the Creator editor (JavaScript with compiled backend)?
I fully understand this is not achievable overnight and I am thinking about the long-term orientation. To me, it seems as a better business solution to merge them or phase one of them out. But not in a way to fully abandon C++ support, but to have a universal C++ engine that can be used alone like the Cocos2d-x and together with the Cocos Creator for WYSIWYG editor.
This will happen at some point. But not quite yet. Both engine teams collaborate to make sure we are making wise choices.
Well, this is something I have not been aware off. So there already is a plan of unifying them at some point? I suppose the lite engine has an edge here since it is being updated more frequently.
Also, do you have any info whether the lite engine can already be compiled as a standalone app? Not planning to use or try it right now, but just being curious.
Yes, both teams work towards unification as a goal. It is hard to say exactly, but the lite engine has benefits. v4 is coming out in the future as well. Mostly metal integration and other fixes.
I have never tried this, but I will try to find some time to try it as well as ask the engineering team.
Edit: I talked to the engineering team and it’s not really possible to make a stand-alone game with cocos2d-x-lite. There is actually no Scene object! Cocos2d-x-lite is used as a runtime currently.
That makes perfect sense as, indeed, even I noticed the scene is missing. Thanks for checking it out nevertheless.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.