Yes, infrastructure will get better. But if I have the ability to export an .apk at 25 MB, instead of 50 MB, then common sense tells me to go with 25 MB. Also, the infrastructure, if you are referring to a users hardware specs ( Iphones, Ipad ) are somewhat old, not everyone has $600-$1,000.00 to buy new hardware? Therefore, when making a game is essential that the developers thinks about the user on the other end, and tries to create a game that’s not just user friendly, but lean, especially regarding export size…
I also agree with almost everything @naive231 said. I also think that the main benefit of cocos over the other engines is it’s flexibility and speed. The fact that it is C++ and doesn’t implement a complicated high level architecture like Unreal and Unity does(and also Cocos Creator) makes it, for most projects much faster than any component-based engine. I do see the advantages that the current architecture of Creator brings, but as @naive231 said, those advantages can also be found in Unity and Unreal, and also other games engines like Game Maker etc. so probably many developers chose Cocos just because of the freedom it offers.
Now, I also think that an editor is important, but right now Creator can’t be used just as an editor for classic cocos2d-x projects, like Cocos Studio used to.
In my opinion the best solution would be somewhere in the middle, continue the development of Cocos Creator, as an IDE, editor and full game builder, but please, please continue developing the classic version of cocos2d-x and make Creator usable just as a scene editor, or at least document it enough so that we can transform it ourselves using extensions in a complete editor for classic projects.
Just like what you said, not everyone has $600-$1000 phone, neither do I.
But if my contract is expired, I would like to change another phone, maintain the same budget also, and guess what? I can definitely get a higher performance phone. Bigger package? No problem.
My point is, if your game is really kick ass one, players absolutely works this problem out, as far as our experiences.
In fact, we do concerning and struggling this at beginning, we really do. But this situation didn’t hanging so long. On the other hand, we also trying some inventive and small sized game with Cocos2d-x, but it was copied so quickly.
Now we realized something. We should raise the technical threshold of our game, not just shrink the package size. Plagiarists in China become more professional than before. Inventive idea can be copied just 2-3 weeks, even just the style, without tuning well, players can accept that. So now why we worried so much about the roadmap of Cocos2d-x, if they just gonna satisfied with the package size or imitating the Unity, it is just killing itself slowly.
agree @luke2125 , as a newbie everytime i or maybe someone else will open what new product cocos creator have produced, and sure cocos creator is a great step made from chukong itself, so, this could inspire everyone who would use or used cocos creator as a potential. Thanks
I also fully and wholeheartedly agree with @naive231. I was on the fence of writing quite the exact same post as naive231 a couple of times in the past. I’m glad you started the discussion.
First of all, I believe that Cocos2d-x is a great engine and I actively choose to use it over Unity and Unreal for my game, since I wanted pure performance. I was completely aware that I will get no (functioning) editor. I’ve seen the Cocos2d-x developer team work on various editors in the past, though none of them even remotely worked. The one before the current one didn’t even start up on my Mac and just crashed.
Cocos2d-x has many opportunities to improve on the things on that it has an edge over other engines - pure performance and writing code in C++. The core rendering code could need many improvements and also the long awaiting auto-batching for all kinds of nodes would be awesome.
There are already great editors out there, e.g. Level Helper by Bogdan Vladu who is a really cool guy and if anybody really really needs an editor, you can also pay the 25 Dollars to get a professional product with support (http://www.gamedevhelper.com/store.php). Or alternatively, tune of the editors that was made for Cocos2d-iPhone could be used and an interpreter for it’s format could be written instead of creating an editor from scratch.
This missing focus leads to many developer (including me) spending quite some time on modding / profiling and trying to optimize the engine.
It’s really frustrating to see how the focus of the talented Cocos2d-x-Team is widespread, instead of focusing on their core and unique features.
I think that it is much easier. Everybody wants money.
Cocos Creator -> More users (including low-skilled) -> More SDK BOX users (low-skilled users will prefer to use ready-made solution than to implement it yourself) -> More money for Chukong!
At the moment I only hope that they will fix critical bugs in the core engine.
And of course I do not expect a better documentation or events.
As the discussion here touched the documentation, then you may be interested in this topic.
But if the reason for these things is really to gain more users and therefore gain more SDKBox users, then they should just license LevelHelper or some other existing tool and indeed working tool instead of spending money on making their own tool over and over. Though I do not know how exactly Chukong is involved in the making of Cocos2d-x and how / whom they pay for working on it. Hence, I don’t want to speculate on that.
The people in the community who are core users are the ones willing and able to contribute to the progress of the engine. Unfortunately, those have to see how much effort is wasted in non-functioning / unneeded Editors when existing solutions do exist.
I just want Cocos2d-x to survive, to progress, to fix old issues and become a better engine. We can’t compete with Unity’s editor, but Cocos2d-x has a better performance than Unity and it still has a lot potential to become even better. Once we have a fast, stable and polished foundation, we can build an editor on top of it - if absolutely needed.
I honestly don’t quite understand why every few weeks to few months someone writes a topic where they are concerned about the future of the engine. Once again these concerns are unfounded. Nobody ever has any reasons except their opinions.
We currently write 3 products: Cocos2d-x, Creator and AnySDK.
We have staff and funding and a plan for the future. The staff works on these goals and supporting items like these forums, the website, docs, developer relations, etc, etc.
What we need is developers using the products and creating their ideas with it. This grows the community and spreads the word. If you see a flaw in the products or related items, report it. If you can fix it, submit a PR. If just 10% of our registered forums users did this we would grow by leaps and bounds each and every month.
In this forum, you or someone else from the team saying that you receive payment from your partner when developers integrate anything from the BOX in their games.
Also, I remember the old presentation for partners and investors about the monetization of engine users. The same idea.
Why not? Not everyone is satisfied with the free plan. For some people free price is a decisive advantage. In addition the cocos is really faster.
Just saying.
Personally I do not like the visual editors.
Hi @luke2125
I’m sorry, but no. I just remember that this is from the days when there was being developed cocos2d-x version 4. Someone from the team published this link.
When we don’t see any latest roadmap about v4 or v3, but instead the Creator releases, we really concerned.
When we know it seems not ready for supporting the industrial graphics API, Vulkan, we really concerned.
(Not just chasing the fashion, it really raises the performances, I think every developer would concerned.)
When we saw Cocos Studio failed, and another similar product Creator appeared, and it closes sources just like Studio, encapsulated the building process of game just like Unity, we really concerned.
When we found Cocos2d-x can’t import FBX file directly still, get a wrong rendering result after we convert a FBX to C3T/C3B, and we need further debugging with the engine, while Unity can use it directly, we really concerned.
(We should report this bug first, sorry about that. We’ll do it right away. Though that bug shouldn’t be happened.)
We know you just need developers using it and spreading it out. We also glad to hear that you have sufficient staff and fund, we really do. We’ll stick with it of course, and hoping you can have more discussion internally to consider the future and the role of the Creator.
Hi,
this discussion is so looooooong, i have no time to read it. I think there are very many better or wronger engine with or without content editor.
I’m happy with cocos2d-x and cocos studio. Of course i wait to c++ with cocos creator, and hopefully we will get the same flexibility for extensions, or code bind from outside, like with cocos2d-x.
We live in a (mostly) free world. Every people use what he/she wants.
Cocos2d-x and Creator devs, keep up the good work, for platform independency, for free, Cocos2d-x is a really good choice. For me at the moment there is no better option.
And thanx for all dev, and the community too.
I understand. But sometimes these roadmaps are guidelines. The actual implementation differs depending upon any hurdles or time constraints that occurred during the release cycle.
Supporting Vulkan I am not sure is a priority. I could be totally off. I know it has been discussed as something for us to consider doing. I do not know the status.
Yes Studio failed, but we developed Creator and Studio in parallel for a while to ensure that Creator was indeed a better plan, then discontinued Studio. We didn’t just axe Studio and leave users with nothing. Creator now also will soon support exporting to Lua and C++. If there are features in Studio that Creator does not have, please tell us what it is and that you really need it. The Creator engineering team listens to all feedback. Closed source should not be a concern. The engine itself is open.
Please send me the GitHub issue for your FBX issue and I can ask the engineering team to look into it.
Lua exists and c++ is being worked on by Ricardo. I have been testing his implementation. I believe that it is going in the v3.14 release which is around December 12. You are welcome to view his parser too: https://github.com/ricardoquesada/CreatorTest There is obviously more to this as he must make changes in the engine as well. I know he focused a lot on UI components and Scale9Sprite as part of this.
