I can’t see a difference btw awkward cocos studio and cocos creator. I will never use it, and I don’t think so it has any other future that same as for cocos studio was.
I just wanted to add that I came to this engine only because Creator exists! Some people - like me - prefer to work with visual tools for visual stuff (placing graphics for example or setting up UI). Plus we want those tools in one place with a unified workflow. That’s why I stopped using libGDX and started using the Godot engine. It was magical. I could write code where there should be code and place anything visual in an intuitive way. Now I’m also experimenting in Defold aswell as Cocos Creator.
I think this generation of coders aswell as just consumers have alot of experience with good usability since that has become a major focus for app and web devs nowadays and we want this to transfer to game engines aswell.
I think i will stick to SpriteBuilderX with cocos2d-x 3.13 till i don’t find a future save solution.
3.13 because i use XCode 7, and don’t want to update, because it works.
Would be yet alternative Godot or Polycode. Godot is slow on Iphone 4, Polycode at the moment not for mobile. 
1 Like
Looks like Polycode is using own IDE, it’s not option at all, Xcode forever. And Godot editor looks very bad… well really no alternatives for this time…
P.s. cocos used for SpriteBuilderX updated to the latest cocos2d-x v3.15.1 with a lot of fixes
Polycode doesn’t support mobile and the development of the current project has stopped. The main developer is basically rewriting everything in his private repository so we’ll have to wait some years to get something usable again.
Yes, i know.
Oh, seems some developer copied contents from Chinese forum. It is because some internal testing version is not released on English forum.
I’m keeping observing 2 engines : Godot & Atomic.
Both of them seem open sourced, from editor to engine.
But they all lack some AAA games to demonstrate what level their engine can do.
Basically, native language or script to authoring game logics will be ok if we had an open-sourced engine. When any bugs occurred, we can set breakpoints or print something to see what happens.
1 Like
Ditto on wait you said. My experience about it.
Godot has lot of examples, afaik. It’s a 2d turned 3d engine with good community support. Anyway it’s artist-inclined, less programmers, more artists.
Atomic comes from Urho3d that’s what I’m using now. I turned to it mainly because of curiosity and the need for a full 3d engine, where cocos2dx is lacking, being more on the 2.5d kind-of 3d level, which is good, but not for fps kind-of games, that’s what I’m at now.
Anyway, both these latter engines went from 3d to 2d, and they’re not absolutely on par with coco2d-x 2d features… for instance, no director… no action-spawn-jumpby…
Moreover, these two require considerable technical understanding and definitely an advanced gaming creation level… by no way turn to these if you don’t have such an experience. Atomic is a bit more forgiving, being more tutored… but urho3d is definitely for programmer-inclined guys. No being artist there. So it’s a bit the opposite of Godot.
By the way, Godot is actually rated as the best open source engine for gaming by a sheer count of git commits and likes, followed at some distance by atomic.
Ending of TL;DR:
Switching to any of these if you don’t have a daring need for 3d features it’s absolutely not worth the while, unless you have a lot of time to spare/want to know new things. For 2d, cocos2d-x it’s still way faster, despite cranky installation, lacks of ECS and whatever.
Eventually, godot could be a 2d substitute. But forget programmers flexibility of “create C++ source, dig in”. It’s all visual. At that point, you could even choose Unity. Or simply stay with creator and cocos2-x as well, given that you know the sdk already.
There’s no perfect solution. But as this ongoing rant seem related to freedom of tinkering and missing to-be feature, I won’t be that worried. Cocos2d-x is a bit old, but it’s feature-rich and stable for 2d. It’s a good shot if want to have that job fast and done.
DISCLAIMER: I’m not related to Chukong. 
since 2014 with cocos2d-x, since 2016 with urho3d. Next one: Unity/Unreal/MY OWN 
2 Likes
And how do you think, with creator in future here will be artists forum or devs?
The answer is none, I think.
Because Creator isn’t a open-sourced project, it will be the next closed project. 
Ahh, reading @ricardo post about beginning of cocos2d: The history of Cocos2d in a glimpse 
(before cocos2d-x) I remember all that days when I learned it first time and used. All was so cool and simple.
Some link from that post: About | cocos2d for iPhone
Looking at this picture makes me feel good in my soul.
Also, they tried to chose a normal way and create a normal editor using Qt(as I said before in some my posts in other threads). Not like cocos studio’s series and so on like current creator… which is mistake too.
@walzer why it was cancelled? It was a right way and Ricardo telling same as I told you already here:
Cancelling projects, specially when they are almost ready, can be frustrating. But our main challenge was finding a good business model. We tried different things, but we couldn’t find a good one.
In hindsight, this is what I think we should have done:
Work on just one editor: the Qt editor that was supposed to be the Cocos Studio replacement.
Offer services within the editor: SDKBOX, and other services.
Focus: Only work on casual/mid-core features (no VR or other distracting features). Try to be the best ones in that category.
Looking at the past, try to learn from your mistakes, but looking at creator… ehhm.
After all this, I have a feeling that a new reborn cocos should arise…
Something like: Fast. Free. Easy to use, community supported… and with current reality it should be also:
- iOS, macOS, Android, Windows
- C++ only
- 2D only
- comes vs optional open source cross-platform editor, normal editor with normal UX and ideology.
Editor to build your UI and publish resources(same idea as SpriteBuilder have). Currently it’s saves a lot of time for me. And designing levels in SB is a pleasure.
Looking at what planned for cocos2d-x like adding more 3D, more JavaScript as main language - this is really wrong…
4 Likes
So cool ! This is my ideal engine.
It will be artist.
JS is easier, creator is easier, sdkbox is easier. More users, more chances.
Look at the c++ landscape, for istance, gui.
There’s no single c++ gui api that really works over multiplatform. None of them.
C++ is tough, and you don’t have Xcode to your back to spare you from building infrastructure…
Qt. You wrong. Or about what you talking?
Qt works excellent!
1 Like
QT… I was there. Better not. So old school, as if I returned back to 2000 and write by hand GUI.
Today I prefer Electron from GItHub for multiplatform
Oh, sorry, Forgot to tell you I’ve banned anything that’s more than 1gb installation from my mac.
In these times of header-only, mobile-friendly, sleek libraries, I’m sure to install that 15 gb monster…