We need a friendly ENGINE, not a dysfunction EDITOR

We need a friendly ENGINE, not a dysfunction EDITOR
0.0 0


@naive231 @KAMIKAZE agree
For me this is terrible that i saw announce of Cocos Builder, then i have heard of Cocos Studio and now i hear about Cocos Creator… Rly 3 GUI tools when 4th will show up ?

At least please make it open source :frowning:
Cocos2d-x strength is in open source!
And C++ :slight_smile:


Please continue working on Cocos Creator…Please. I see so much potential.


every time Cocos Creator require login i feel so concern
an opinion raises, if one day internet in my country can’t access to Cocos Creator server or any problems occur and can’t login then my project will become nothing.

by the way Cocos Creator is awesome!

$ ./CocosCreator --help
cocos-creator <path> [options]

  test <path>   Run specific test
  build <path>  Build specific package

  --help           Show help                                           [boolean]
  --version        Show version number                                 [boolean]
  --dev            Run in development environment.                     [boolean]
  --show-devtools  Open devtools automatically when main window loaded.[boolean]
  --debug          Open in browser context debug mode.  [number] [default: 3030]
  --debug-brk      Open in browser context debug mode, and break at first.
                                                        [number] [default: 3030]
  --lang           Choose a language                      [string] [default: ""]
  --logfile        Specific your logfile path
   [string] [default: "/Users/jryin/Library/Logs/CocosCreator/CocosCreator.log"]
  --path           Open a project by path                               [string]
  --nologin        Do not require login in dev mode                    [boolean]
  --internal       Show internal mount                                 [boolean]
  --testing        Use test update feed                                [boolean]
  --mount          Mount external resources                              [array]
  --writable       Specify the external resources are writable. Default is
                   readonly.                                           [boolean]
  --build          Build options                                        [string]
  --compile        Compile options                                      [string]
/Applications/CocosCreator.app/Contents/MacOS/CocosCreator --nologin


I think Cocos Creator also support offline login.


oh, thank
i’m clear now


Well, read the full thread. In my opinion c++ is the only language for games. Both Google and Apple made difficult to code in c++ as they wanted to push their languages, they finally accepted c++ and now is much easier to use it in both platforms. This is because games (not all kind of games of course) need and will always need every bit of performance.

In any case think you should focus, as you know, you can’t please everybody and resources are limited. I come from Marmalade SDK, it was a good c++ solution but they wanted ‘easy game development’ so they expanded with Marmalade Quick, of course main branch suffered and are now defunct.

When Marmalade closed i doubted between cocos2d-x and sdl-2, decided finally with cocos because forum had more traffic and because of sdkbox, integrating apis is always a pain.


Agree with @felox.

If developers want to make a serious, product-level game, they always need to control every parts of the game.

Every game engine has the same purpose: Lower the technical threshold of game developments. That’s no doubt. But in front of that goal always has a more important lowest standard: Debuggable.

@felox mentions 2 important things: You can’t please everybody and resources are limited.
I said that before,too. The core engine has lots of things to do, and the users use it for main game engine absolutely not because your engine is a “EASY” one. They use it just because it is open-sourced and community-driven. That means we can make it better and better.


lets just try this… there are over 1000 reported issues in github. Why don’t we all grab an issue everyday fix it and send pr. how does that sound? it would really help out @zhangxm


Model importer improvements
Digital Content Creation (DCC) workflow has been made easier with the first set of significant improvements in the process of importing assets from popular DCC tools like Maya. The results? Increased productivity for artists and designers, and less hassle for programmers.
FBX import in Unity now supports Segment Scale compensation for models exported from Maya and the FBX SDK has been upgraded to 2016.1.2.
We also added the option of computing weighted normals when importing FBX files such as by area, angle or both and fixed normal generation for hard edges. Lights and cameras are now imported from FBX files and Unity automatically adds and configures both Camera and/or Light components to objects as necessary.
Unity can now read visibility properties from FBX files with the “Import Visibility” property.

This blog was cut from the Unity latest version 2017.1.
It continues adding compabilities for FBX file, I don’t know why cocos2d-x don’t support it directly instead of c3b/c3t?


Check out this VR game using WebGL and WebVR running fully within browser across platforms: iOS, Android, Windows, Mac, Linux etc… and you can package it as an app in a webview just as easily - with or without Cordova or Electron.


JavaScript has become too good to ignore now. I don’t think it is unreasonable for Cocos2dx team to choose Javascript as the primary language for Creator, which is itself getting built using Javascript+Electron just like Visual Studio Code). They want developers to be able to target web also - along with iOS/Android/Mac/Windows apps.

I understand the bias of everyone who has, just like us, invested a lot of time and money building something on top of Cocos2dx and C++ stack, there is no reason for us to not continue using the same stack for existing projects. But since almost a year we are using JavaScript (with TypeScript) for all our new projects, and have migrated some existing projects also to JavaScript/TypeScript.


is this yours?


No. Just a reference for what can be done in JS/Webviews.


its one of the worst games i’ve played actually and it took 10 mins to load


I’m sure there are better examples and all but you are missing the point of this whole thread.


Not bad, look what you can do with c++

Any os, any database, any AAA game is done with c/c++. Microsoft made visual studio ide with whatever but i’m sure the compiler is done with something else. The engine is yours, you decide.


Not bad, look what you can do with c++ :wink:


cocos2d-x is a game engine to make games not web browsers :wink:


What mausmausgames has said… I have been using Cocos for 2 years now and I’m having very similar concerns. Plus I’d add the problem of lacking a detailed, all-encompassing API reference. API reference to a framework is what skin is to a human. Without it, it is disgusting to even look at. Take a look at Qt’s. Ain’t no programmer’s guide or auto-generated documentation is gonna replace that (however programmer’s guide is quite useful to beginners nonetheless). There have been no improvements on this front even though it had been recognized as a weak point years ago.


C’mon, guys, of course C++ is better than Js. No talkin’ about that.
The problem here is how many time it takes to learn c++ confidently enough to make good games.
Yes, it’s a lot. And a lot more, more than Js.
Js is a language created for managing popups. No more than that.
So now you have a lot of new js game programmers who thinks they can do games easily because “oh, well, I know the language. That’s easy.”:wink:
It’s easy because you have creator and sdkbox. Otherwise you’ll be in a big mess. Not even know how integrating services…
So that, just for fanning the flames…:wink: