Yes, the engine part will keep open source in the future.
Cocos Creator lacks stability. Beta releases felt like alpha builds and stable release felt like beta builds. The QA process really needs improvements. I understand the editor and engine is evolving at a very fast pace and it is difficult to keep track of bugs. But I believe with proper and transparent automated test written and executed, most of the minor bugs and be identified and squashed. Moreover, we community can take part in it.
Why I use it?
Already shipped a small casual/non original game just to test it and test SDK integration. The experience was awesome: I added Game Center support (iOS), Analytics (iOS/Android) and Chartboost videos(iOS/Android) in less than 2 days. It was awesome. I also completed and published the small game in 2 weeks.
- High productivity
- Rapid prototyping
- Great Performance for 2D games
- Entity Component System!!!
What I dont like it:
- Lack of support on english forums: we need the dev team supporting early adopters.
- Best practices documents: what is the best way of doing something?
- More examples projects
- Best practices
- More bug support: we do not know if we are facing a limitation or a bug (see this: [BUG] TiledMap Parser error while set a tmx file)
And the most important: REAL SUPPORT to early Creator adopters
- Chukong is a big company and I believe they can do muc better supporting/incentivize creating games in Creator. King made a contest and sent a few grups of developers to the GDC.
If you really care about us the developers, Invest MONEY in supporting us. Support the developers: sponsor games, small grants, add ads support/campaigns
Build regional support in more languages. Create forums in more languages. Find advocates and hire them (pay them!!) to spread the word in other languages, create events, build communities, and so on.
That is the kind of things that I dont understand coming from a big company… it gives a bad message about the product and the company.
I tried using Cocos Creator, but… it wasn’t c++ support back then at all. Now it’s still alpha, so not ready for production yet. I don’t want to use js, sorry.
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.
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.
y español! Hay muchos hispano hablantes en el mundo!
Precisamente, imajinate Sud America, el Caribe usando Cocos Creator.…God Bless…
Reasons I would use Creator:
- 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.
Agreed. Lack of documentation and stable releases looking like beta. QA needs to improve.
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.
Thank you for the kind words. I hope to work on the documentation again someday!
what??? does it mean this job/task is “paused” now? …
Back in March, Ricardo and I were laid off from the company. Now this task is being done by others in the group.
If Cocos Creator’s documentation is like Phaser’s I will stick to Cocos Creator for all my 2D web games.