Need a way to easily migrate without having to do a full rewrite. Release the CocosCreator C++ Lite engine as Cocos2dx C++ v4 with some documentation for migrating from Cocos2dx 3.x to Cocos2dx 4.
Forcing people to rewrite using Creator editor gives them an option to consider rewriting using any other framework. If they have a clear migration path they will have no reason to look elsewhere. Then Cocos team also won’t need to maintain two C++ engines. And all the existing code and projects will still ‘fit’ in the new vision without anyone having to worry about the the engine dying a slow death.
Once our existing code is using the new engine, we can try developing new parts using creator and build it together with existing code, slowly migrating parts of existing projects to creator or continuing using the CocosCreatorLite/Cocos2dx 4 engine directly without the editor, etc…
EDIT: I want to add that this has already been suggested by cocos team as an option, but they should do it quickly to remove any fears about the core engine getting ignored or slowly dying out.
I think they mean that c++ support isn’t production ready in Creator, and by the fact that it’s in alpha stage means they are 100% correct, by the very definition of alpha.
Creator itself may or may not be ready for producing stable games but you have to do so in javascript, and like piotrros I have no interest in that. I chose cocos2d-x because it was a c++ engine for native apps. I wouldn’t have even wasted my time with it if it was going to become a closed source Unity copy cat (a poor copy cat at that) and pushed for web development.
You’ve made some good / valid points…. The region of South America, Caribbean most likely don’t know about Cocos Creator, maybe, I’m mistaken…Myself, i know both English / Spanish, born in Cuba, I know that in Cuba, there are game developers, who probably don’t even know about Cocos framework…Es una lastima que la plataforma de Cocos no se enfoque en el mercado latino americano.Estoy pensando en hacer un libro para la audiencia hispana, de Cocos Creator…Pero tengo que ver si en verdad esta plataforma va durar en el mercado….**.Que Dios te Bendiga…
I only use C++ with Xcode and Visual Studio. Although the Cocos Creator looks like an interesting editor, I prefer a code approach when working with Cocos2d-x.
exactly my philosophy of what features a decent 21th century game engine should have
Wysiwyg editor
built-in animation editor
supports animation tools like Spine
performs well on HTML web mobile
I’m a fan of typescript + accurate autocompletion in VScode
Reasons I would not use it:
I’ve tested the product occasionnaly since version 1.2 (but not the latest built) and in about every version I’m stuck by some bug or crash as soon as I try “fancy stuff”.
For example, I like the concept of “nested prefab/symbol” (at least as in Flash or Affinity designer), and it’s surprising to me that Unity or Creator didn’t carefully and robusty implemement it. Testing nested prefabs usually leads to unexpected behaviors, corrupted data if a nested prefab is modified. So I don’t feel confident to use this extensively.
the documentation is terrible (despite the excellent efforts of @slackmoehrle), but it has be said (and debated)elsewhere… What happens when @slackmoehrle is sick, or takes vacations?^^ Perhaps 3 or 4 @slackmoehrle are needed? …
the community seems supportive but not huge, last time I asked something on the forum it took 9 days to get an answer. I guess the “critical mass” of users is not yet here.
Conclusion: my main blocking factor is a lack of trust.
Regarding the robustness of the tool (some “dark areas” don’t encourage me to explore or dig them, because I know I will struggle to get the proper and up-to-date information). Look at what happened with Flash (early versions , before it became bought by Adobe) the tool promised little (vector animation with basic interactivity) but did it well, and robustly. You could understand the basics and combines them in various ways. It allowed unexpected use by various kinds of users (devs, artists, teachers, etc.) and it was widely adopted. So if Chukong wants to be the Flash of Game engines, it has to be robust. I’m not sure at all it is (see my xp with nested prefabs).
and regarding the documention of course. It’s difficult for me to guess to what extends it’s from the chinese/english differences. Another troublesome point is that documentation is split amongst different web pages, github example projects, etc… no consistency. Perhaps differents github accounts, as far as I remember. Having a bunch of different tools all named “cocos-something” (2d, X, JS?, creator, studio,) etc… doesn’t help easy access and documentation for newcomers. It certainly shows that Chukong tries different branches, which is not bad, cutting dead branches is ok, but remaining branches must be cleaned regularly. Easy access for newcomers is key if Chukong wants a critical mass of users. Chukong has already done very big efforts regarding accessibility: Wysiwyg editor, free software, easy setup. It’s a pity that it’s spoiled by a poor documentation.
But overall I keep an eye on Creator because it tends to evolve in a positive way.
We (my team and I) will use CC just for UI with c++ plugin but still not completed (for example page view not working )
We choose cocos2d-x for c++ performance and directly use Open Gl stuff and if cocos go for JS We migrate to Unreal Engine. (sorry but we hate Unity)
I miss cocostudio.
We are using Cocos2dx for almost 4 years since 3.0.0pre-alpha, we have many customised class implementation based on the original cocos element. Also we have built our own ads system using C++ which CC cannot use.
what??? (sorry)
I don’t know Chukong or Cocos well enough to grasp the “subtleties” of this move… Could illustrate how Chukong blatantly ignore the importance of documentation and community.
I hope I’m wrong and that you will be able to join the team again.
There’s been some amazing points brought up thus far, I’d like to add a few more.
We’re currently in midst of two projects, one smaller one larger, both with Creator. I really like Creator, there’s a lot of amazing features, the speed that we’re able to prototype features is fantastic. However there’s a lot of things with Creator that still concern me.
With the larger project, having resource bundles would be extremely helpful, there’s many modules of that project where a resource bundle would be perfect to keep the initial download smaller. I know they’re on the roadmap, and they’ve been delayed. However, this is a feature I think that’s truly necessary before real large apps can be viable on Creator.
We have a need to integrate 3rd party SDKs that are not already handled by either SDKBOX or ANYSDK. I’ve asked for some sort of guide or tutorial for how to accomplish these tasks and I was met with silence. SDKBOX and ANYSDK is fantastic if your SDK is handled by them, I have no problem with those products. However, it’s unreasonable that they should implement every SDK. Thus, making it easier or at least making it more visible how to accomplish that would be appreciated.
Working in teams is difficult with Creator, not impossible, but difficult. .fire and .prefab files do not merge well. Even using the FireMerge tool provided by Big Fish Games, there can be dozens and dozens of conflicts, and they’re not necessarily easily resolved, it’s difficult to determine what node you’re looking at, what property you’re adjusting etc. So, making these files easier to work with, so I don’t need to be leery every time I change a .fire or .prefab would be appreciated.
Even though Cocos itself is becoming quite mature, Creator and it’s spin-off engines are still very young. There’s a lot of growing pains to go through. Creator is competing with products that have been around much longer, have gone through these pains, and come through the other side. I’m very much looking forward to the point where Creator gets there too.
Acutal H5 or js or html or webgl, have been advised by many large companies for more than 10 years, but tody, it’s still not hot for HD game development. There is a stone reason: the truth, the browsers never focus on game runing. And play game on mobile browser experience is very bad. And user offten use browser to searching, reading news and etc. I believe many many companies only deploy their’s games at Android or iOS or both of them. four years ago, I have this mind, now I still have this oponion.
Well very simple and straight answer …I think it doesn’t have direct support to cocos2Dx with including all feature that cocos2Dx it self offering. If I wanted to have engine where i have to use in between language to implement game codes than i would pick GoDot game engine. just look at that it has everything inside handling by editor and soon those guys are about to bring c# too.
Precisamente, imajinate Sud America, el Caribe usando Cocos Creator.…God Bless…
, before it became bought by Adobe) the tool promised little (vector animation with basic interactivity) but did it well, and robustly. You could understand the basics and combines them in various ways. It allowed unexpected use by various kinds of users (devs, artists, teachers, etc.) and it was widely adopted. So if Chukong wants to be the Flash of Game engines, it has to be robust. I’m not sure at all it is (see my xp with nested prefabs).
…
