We need a friendly ENGINE, not a dysfunction EDITOR

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

#41

I think we need both a better editor and better engine :slight_smile:


#42

Absolutely. We can always improve every aspect of every product! This is why we all do what we do. If the tools were perfect then our community would not even be here.


#43

That sounds great, and thanks for the link to the parser, I didn’t know about that repository, only about a js parser. It’s logic that he now focuses on UI since that’s probably the main purpose of an editor(gameplay assets are mostly generated and placed at runtime dinamically, but creating a UI programatically is very redundant and time consuming). I’m looking forward to the next release and I’m sure there will be many developers very happy to be able to use Creator as a scene editor for classic c++ projects.

Well, obviously. I believe the subject of this discussion is which should come first, and mainly a hopeful request to the team not to discontinue the engine development(I mean the classic open source version, not the internal Creator engine).


#44

I feel like these have to go hand in hand in some respect. At least for those that will use an editor.

You CAN have a super awesome engine and no gui tool. This helps devs that are comfortable with coding a lot.

You CAN have a mediocre engine and great editor as long as the engine keeps up with the editors demands.

You CANNOT have a great editor, but an engine that cannot support all of the editor’s features.

We try to strike this balance. Obviously this discussion means that some folks don’t think we do a good enough job here.


#45

Not really sure about that, at least in my case particularly. I didn’t join this discussion because I think that engine development is slow, but because I was afraid that the cocos team might plan to discontinue the classic engine version in the future and only develop the enclosed, internal Creator version.


#47

This will never happen. I’ll stick my neck out for this.

Edit: as I think about this more, doing so would pigeon hole everyone into using an editor. I think there is a saying, something like cutting off your nose to spite your face This would cut our usefulness into a small niche rather than any skill level coder using it.


#48

Hello, Everyone. I was Cocos Studio user.

Well… I was shocked when I realized it’s slowly being replaced by Cocos Creator. OK let me try it… boom… It looks good, even I have a little issue here, as it’s closed source and more of HTML-ish engine (instead of C+±ish engine). But, I can understand the decision to make it closed one.

I don’t know a more elaborate goal for the future of development of Cocos2d-x, especially when it comes to competition with other engines such as Unity, UE, CryEngine, GameMaker, Construct, etc. Those proprietary engines are now facing a serious headache, given a fact that Godot Engine (open source, MIT-licensed engine) growing at a very very fast speed and most likely be ready to shake Unity5, UE4, CryEngine on February 2017 when it comes to blockbuster graphic, while it’s already a viable engine to shake GMS, Construct, Fusion, and Unity when it comes to 2D engine.

I’m following cocos2d-x development, but still can’t catch its specialized goal or a solid plan for the future of Cocos2d-x. (maybe I missing something though).


#50

Engine itself is opened means? What part of engine is open?
Can we contribute to it. I mean, like improving asthetics and all. I think, why not have a great theme for a would be great tool? :stuck_out_tongue: :slight_smile:


#51

Hello everybody,

I was also a Cocos Studio user, i was using it with C++ and JavaScript together and i liked very, very much that they are separeted from each other. You just give Cocos Studio to grahics designers, they do they job, put there animations, layout, etc… and send you export from that awesome editor.
You may use it or not but in bigger companies or on bigger projects that part was necesary and it just worked.
When i saw cocos creator and it’s likeness to Unity i was so god damned pissed that i almost stop using cocos2d-x. I have Unity and especially that fact it is a closed source and they not repairing bugs and just doing new a new features.
Cocos Creator is still not having only graphic layout / animations export feature and they even don’t planing it. WHY ??? Stop beeing like unity and do what you’re was doing. Be different. Unity is for people who don’t even need to know how to programming. It have great editor but that about it.
Now i just stuck on cocos2d-x 3.11 and old CocosStudio … please … at least make that explicit export of graphics layouts and animations just like in CocosStudio. That would be sooooo great.
And stop being like Unity and continue bee what you always was. AWESOME, OPEN SOURCE GAME ENGINE FOR PROGRAMMERS … and not engine just for everyone, that is bullshit !
Thanks and sorry … but i love cocos2d-x and what i see now … it really makes me so sad :frowning:


#52

You are right. This is a workflow that many use.

Actually Creator already has this feature for LUA projects and it will probably have it for C++ from the next release.


#53

As I mentioned before, I try a fbx downloaded from Unity Asset Store:
https://www.assetstore.unity3d.com/en/#!/content/33478

After imported it into Unity, I copy FightingUnityChan_FreeAsset/FightingUnityChan_FreeAsset/Models/* out to Cocos2d-x’s project. There’s every thing we need to render a correct Sprite3D object.

But when I use fbx-conv to convert it to c3t/c3b, I encountered following error:

INFO: FBX to c3x converter, version 0.7 x32 (debug version, cocos2d-x-3.4-beta0 or later version can use)
STATUS: Loading source file
ERROR: FBX SDK encountered an error: Unknown
ERROR: Error loading source file: /home/naivechou/cocos_igs/cocos2d-x/tests/cpp-tests/Resources/unitychan/unitychan.fbx
STATUS: Closing source file
Press ENTER to continue…

That error message is so meaningless that user don’t know what is hell happened. Unknown? What should I do now? If this fbx is exported from my artists, how should I tell them that your fbx can’t be used.

(After some try-error tests, It turns out that fbx file must exist in the same path of fbx-conv… I just really NO-COMMENTS about it…)

Ok, now fbx can be converted to c3b:

INFO: FBX to c3x converter, version 0.7 x32 (debug version, cocos2d-x-3.4-beta0 or later version can use)
STATUS: Loading source file
PROGRESS: Import FBX 1.05%
PROGRESS: Import FBX 2.11%
PROGRESS: Import FBX 3.16%
PROGRESS: Import FBX 4.21%
PROGRESS: Import FBX 5.26%
PROGRESS: Import FBX 6.32%
PROGRESS: Import FBX 7.37%
PROGRESS: Import FBX 8.42%
PROGRESS: Import FBX 9.47% Character1_Hips
PROGRESS: Import FBX 10.53% Character1_LeftHandThumb1
PROGRESS: Import FBX 11.58% Character1_LeftHandPinky1
PROGRESS: Import FBX 12.63% Character1_RightHandThumb1
PROGRESS: Import FBX 13.68% Character1_RightHandPinky1
PROGRESS: Import FBX 14.74% eye_L_old
PROGRESS: Import FBX 15.79% J_L_HeadRibbon_00
PROGRESS: Import FBX 16.84% J_R_HairTail_03
PROGRESS: Import FBX 17.89% J_L_Skirt_00
PROGRESS: Import FBX 18.95% J_R_SkirtBack_01
PROGRESS: Import FBX 20.00% button
PROGRESS: Import FBX 21.05% eye_L_tex
PROGRESS: Import FBX 22.11% eye_R_tex
PROGRESS: Import FBX 23.16%
PROGRESS: Import FBX 24.21%
PROGRESS: Import FBX 25.26% BLW_CONF
PROGRESS: Import FBX 26.32% EYE_DEF_C
PROGRESS: Import FBX 27.37% root 1
PROGRESS: Import FBX 28.42% SCA_Miyako__MiyakoNode__NodeAttribute__IgnoreAxisX
PROGRESS: Import FBX 29.47% lockInfluenceWeights
PROGRESS: Import FBX 30.53% SCA_Miyako__MiyakoNode__NodeAttribute__IsLodRoot
PROGRESS: Import FBX 31.58% SCA_Miyako__MiyakoNode__NodeAttribute__IgnoreAxisY
PROGRESS: Import FBX 32.63% lockInfluenceWeights
PROGRESS: Import FBX 33.68% SCA_Miyako__MiyakoNode__NodeAttribute__IsLodRoot
PROGRESS: Import FBX 34.74% SCA_Miyako__MiyakoNode__NodeAttribute__IgnoreAxisY
PROGRESS: Import FBX 35.79% lockInfluenceWeights
PROGRESS: Import FBX 36.84% blendHIKState2SK1
PROGRESS: Import FBX 37.89% SCA_Miyako__MiyakoNode__NodeAttribute__LodLv
PROGRESS: Import FBX 38.95% blendHIKState2SK1
PROGRESS: Import FBX 40.00% blendHIKState2SK1
PROGRESS: Import FBX 41.05% blendHIKState2SK1
PROGRESS: Import FBX 42.11% SCA_Miyako__MiyakoNode__NodeAttribute__LodLv
PROGRESS: Import FBX 43.16% blendHIKState2SK1
PROGRESS: Import FBX 44.21% blendHIKState2SK1
PROGRESS: Import FBX 45.26% blendHIKState2SK1
PROGRESS: Import FBX 46.32% SCA_Miyako__MiyakoNode__NodeAttribute__OnlyRotateMotion
PROGRESS: Import FBX 47.37% SCA_Miyako__MiyakoNode__NodeAttribute__IgnoreAxisZ
PROGRESS: Import FBX 48.42% SCA_Miyako__MiyakoNode__NodeAttribute__ModelLinkId
PROGRESS: Import FBX 49.47% SCA_Miyako__MiyakoNode__NodeAttribute__IgnoreAxisX
PROGRESS: Import FBX 50.53% lockInfluenceWeights
PROGRESS: Import FBX 51.58% lockInfluenceWeights
PROGRESS: Import FBX 52.63% SCA_Miyako__MiyakoNode__NodeAttribute__LodLv
PROGRESS: Import FBX 53.68% SCA_Miyako__MiyakoNode__NodeAttribute__OnlyRotateMotion
PROGRESS: Import FBX 54.74% lockInfluenceWeights
PROGRESS: Import FBX 55.79% SCA_Miyako__MiyakoNode__NodeAttribute__LodLv
PROGRESS: Import FBX 56.84% lockInfluenceWeights
PROGRESS: Import FBX 57.89% SCA_Miyako__MiyakoNode__NodeAttribute__Skip
PROGRESS: Import FBX 58.95% SCA_Miyako__MiyakoNode__NodeAttribute__IsLodRoot
PROGRESS: Import FBX 60.00% SCA_Miyako__MiyakoNode__NodeAttribute__IsBillboard
PROGRESS: Import FBX 61.05% SCA_Miyako__MiyakoNode__NodeAttribute__IsBillboard
PROGRESS: Import FBX 62.11% SCA_Miyako__MiyakoNode__NodeAttribute__OnlyRotateMotion
PROGRESS: Import FBX 63.16% skinCluster7
PROGRESS: Import FBX 64.21%
PROGRESS: Import FBX 65.26%
PROGRESS: Import FBX 66.32%
PROGRESS: Import FBX 67.37%
PROGRESS: Import FBX 68.42%
PROGRESS: Import FBX 69.47%
PROGRESS: Import FBX 70.53%
PROGRESS: Import FBX 71.58%
PROGRESS: Import FBX 72.63%
PROGRESS: Import FBX 73.68%
PROGRESS: Import FBX 74.74%
PROGRESS: Import FBX 75.79%
PROGRESS: Import FBX 76.84%
PROGRESS: Import FBX 77.89%
PROGRESS: Import FBX 78.95%
PROGRESS: Import FBX 80.00%
PROGRESS: Import FBX 81.05%
PROGRESS: Import FBX 82.11%
PROGRESS: Import FBX 83.16%
PROGRESS: Import FBX 84.21%
PROGRESS: Import FBX 85.26%
PROGRESS: Import FBX 86.32%
PROGRESS: Import FBX 87.37%
PROGRESS: Import FBX 88.42%
PROGRESS: Import FBX 89.47%
PROGRESS: Import FBX 90.53%
PROGRESS: Import FBX 91.58%
PROGRESS: Import FBX 92.63%
PROGRESS: Import FBX 93.68%
PROGRESS: Import FBX 94.74%
PROGRESS: Import FBX 95.79%
PROGRESS: Import FBX 96.84%
PROGRESS: Import FBX 97.89%
PROGRESS: Import FBX 98.95% blendShape2.EYE_ANG1
PROGRESS: Import FBX 100.00%
STATUS: [shape(MTH_DEF)] Triangulating FbxMesh geometry
STATUS: [shape(EL_DEF)] Triangulating FbxMesh geometry
STATUS: [shape(BLW_DEF)] Triangulating FbxMesh geometry
STATUS: [shape(tail)] Triangulating FbxMesh geometry
STATUS: [shape(hair_frontside)] Triangulating FbxMesh geometry
STATUS: [shape(hair_front)] Triangulating FbxMesh geometry
STATUS: [shape(tail_bottom)] Triangulating FbxMesh geometry
STATUS: [shape(hair_accce)] Triangulating FbxMesh geometry
STATUS: [shape(skin)] Triangulating FbxMesh geometry
STATUS: [shape(uwagi)] Triangulating FbxMesh geometry
STATUS: [shape(uwagi_BK)] Triangulating FbxMesh geometry
STATUS: [shape(shirts_sode)] Triangulating FbxMesh geometry
STATUS: [shape(shirts_sode_BK)] Triangulating FbxMesh geometry
STATUS: [shape(button)] Triangulating FbxMesh geometry
STATUS: [shape(hairband)] Triangulating FbxMesh geometry
STATUS: [shape(cheek)] Triangulating FbxMesh geometry
STATUS: [shape(Leg)] Triangulating FbxMesh geometry
VERBOSE: [shape(head_back)] polygons: 142 (426 indices), control points: 87
VERBOSE: [shape(eye_base_old)] polygons: 96 (288 indices), control points: 74
VERBOSE: [shape(eye_L_old)] polygons: 22 (66 indices), control points: 24
VERBOSE: [shape(eye_R_old)] polygons: 22 (66 indices), control points: 24
VERBOSE: [shape(EYE_DEF)] polygons: 626 (1878 indices), control points: 363
VERBOSE: [shape(Shirts)] polygons: 653 (1959 indices), control points: 384
VERBOSE: [shape(MTH_DEF)] polygons: 886 (2658 indices), control points: 515
VERBOSE: [shape(EL_DEF)] polygons: 372 (1116 indices), control points: 316
VERBOSE: [shape(BLW_DEF)] polygons: 36 (108 indices), control points: 40
VERBOSE: [shape(tail)] polygons: 1168 (3504 indices), control points: 727
VERBOSE: [shape(hair_frontside)] polygons: 530 (1590 indices), control points: 406
VERBOSE: [shape(hair_front)] polygons: 227 (681 indices), control points: 199
VERBOSE: [shape(tail_bottom)] polygons: 658 (1974 indices), control points: 404
VERBOSE: [shape(hair_accce)] polygons: 240 (720 indices), control points: 124
VERBOSE: [shape(skin)] polygons: 2994 (8982 indices), control points: 1585
VERBOSE: [shape(uwagi)] polygons: 1286 (3858 indices), control points: 717
VERBOSE: [shape(uwagi_BK)] polygons: 1504 (4512 indices), control points: 822
VERBOSE: [shape(shirts_sode)] polygons: 1444 (4332 indices), control points: 792
VERBOSE: [shape(shirts_sode_BK)] polygons: 408 (1224 indices), control points: 263
VERBOSE: [shape(button)] polygons: 210 (630 indices), control points: 135
VERBOSE: [shape(hairband)] polygons: 186 (558 indices), control points: 134
VERBOSE: [shape(cheek)] polygons: 24 (72 indices), control points: 22
VERBOSE: [shape(Leg)] polygons: 2322 (6966 indices), control points: 1261
WARNING: [face] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [face] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [eyebase] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [eyebase] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [eye_L1] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [eye_L1] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [eye_R1] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [eye_R1] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [eyeline] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [eyeline] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [hair] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [hair] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [body] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [body] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [skin1] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [skin1] Material CgFX shading not supported, replaced with RED diffuse
WARNING: [mat_cheek] Material doesn’t extend FbxSurfaceLambert, replaced with RED diffuse
WARNING: [mat_cheek] Material CgFX shading not supported, replaced with RED diffuse
STATUS: Converting source file
STATUS: Closing source file
VERBOSE: Listing model information:
VERBOSE: ID :
VERBOSE: Version : Hi=0, Lo=7
VERBOSE: Meshes : 4 (214688 vertices, 24 parts, 48168 indices)
VERBOSE: Nodes : 2 root, 165 total, 24 parts
VERBOSE: Materials : 9 (0 textures)
STATUS: Exporting to c3b file: unitychan.c3b
STATUS: Closing exported file
Press ENTER to continue…

There’s some warning messages, seems not really matter.
Then I change codes in cpp-tests:

void Sprite3DWithSkinTest::addNewSpriteWithCoords(Vec2 p)
{
	//std::string fileName = "Sprite3DTest/orc.c3b";
	std::string fileName = "unitychan/unitychan.c3b";
    auto sprite = EffectSprite3D::create(fileName);
    sprite->setScale(3);
...(others omitted)...

I just replaced the orc.c3b to unitychan.c3b then I hoping to see it appear, but it doesn’t.
After we digging into the c3t and finally realized that texture of unitychan.c3b have to placed in the same path.

More over, I re-browsed the programmer guide:
http://cocos2d-x.org/docs/programmers-guide/3d/#sprite3d

It doesn’t tell us what should we do about the texture, it just say the only thing we need to do is place the c3b in Resources/ and feed it to constructor of Sprite3D, everything will be done of rendering the orc.

There’s another limitation of fbx-conv:

There are a few things to note about fbx-conv: The model needs to have a material that contains at least one texture it only supports skeletal animation. it only supports one skeleton object no multiple skeleton support yet. You can create a 3d scene by exporting multiple static model * The maximum amount of vertices or indices a mesh is 32767

Why the engine has such critical limitation SO LONG? From v3.2, 3D features has been introduced til now. I don’t heard about them on Unity. One skeleton object only? 32767 indices a mesh? The mesh of model can’t be placed under the bone? So many limitations:
http://www.cocoachina.com/bbs/read.php?tid-236693.html

Our artists complain that the engine is too weaks to used on REAL product before. That time I think maybe you will fixed them later. But you just pass them out, assumed that everyone won’t need this.

That’s what I’m saying, Cocos2d-x needs more friendly implementation. Don’t just wanna make another editor, editor can’t solve the real pain points.


#54

Fully agree with 1-st post. No need more details. And yes, bluntly said - any editor’s you ever made is bad( I really want to use another even worse word for that ).

We need something like SpriteBuilder! Try to understand that…


#55

Sorry, I don’t agree with you.

There is only one problem about Cocos2d-x.

Cocos2d-x and Cocos Creator needs more source,tutorial, sample project…etc It’s the impornant problem to earn new developers.

Cocos creator is a necessary project. Let’s see what alternatives exist;

  • Game Maker 2.0


Great editor and user interface. But it’s very expensive and it’s not a open source project.

  • Unity

It’s not good idea if you’re only a 2d game developer.

So Cocos Creator is an alternative with more performance, js scripting language(and c++ support coming soon), less build size, flexible game development tool.

I don’t want to use more large framework. Cocos2d-x is a already very big framework. We need to more stability, more refine framework. For example; Löve2d is very simple,little, basic game framework but it’s really populer option to make games.

But new component system can fix your extreme feature or different libraries. So we also need a Cocos Store to purchase new libraries, features… etc.

Summary:

  • Cocos Store: we need to use a market for components, libraries, sources…etc

  • More documents, tutorials, sample projects, articles… to earn new game developers.


#56

We need more tutorials and demo projects anyway.

For example I just started moving from cocos2d-iphone to cocos2d-x and I have a lot of problems from the main beginning…
Wrong guide steps, not working project… all this is hard for new devs. I’m looking for solutions because from my experience I realize what exactly wrong. But I don’t think that someone new will struggle with this…


#57

You can’t guarantee it right now with cocos-creator.[quote=“pococogames, post:55, topic:33651”]
I don’t want to use more large framework.
[/quote]

Cocos creator is indeed a large UI engine wrt feature available.

Yeah, but only high-end users would need it. Example what is provided in Unity Store. For basic games, I think general engine is fine. Note: I am not talking about game-template but libraries and extra features.

Haha… writing summary is nice idea for big posts :stuck_out_tongue: I’ll also add it next time.

I agree with your other points.


#58

I think that’s the issue with open source project. Example- I’ve started learning DragonBones. And believe me there isn’t any single guide and video tutorials are only 2 or 3 which shows basic part.
DragonBones also have demos just like cocos2d-x. Install it, see the code/animation and learn by yourself if you wanna use it.

I noticed that open source communities majorly relies on community support. They mostly don’t allocate resources for these things. Cocos has started doing it only lately (since end of the last year where still the intermediate and advance topics are there) only after extremely high demand from forums members.

But interesting fact is More are the tutorials, larger the community and hence much more video tutorials and books.


#59

Actually It’s not good idea for only beginners. For example, some guys want to new light effects or advanced features in cocos2d-x framework. They would use Cocos Store to get developed libraries or addons. Modular systems would be better then current system.


#60

Yeah I understood your meaning. By lights, you mean custom shaders or even feathers which is 3D I guess? Yeah, then value of forum will decrease :stuck_out_tongue: Nonetheless, a beginner will never seek for this, I’m telling. Because he has alternatives to settle for achieving similar results…

Modular as in? Plugin based! Like cocos creator way?
Matters but not much. Suppose, I can create custom lights, then I can prepare a library based .h and .cpp file and put on the store.

Until, more and more users use cocos framework or cocos creator, usage of store won’t increase because time to start and learn uptil intermediate/advance stage will itself take more time until the need for store would arise.

@walzer once said that Cocos creator would use Cocos2d-x itself. But I don’t know if its exactly the same framework or what because what’s being used in creator is entity model based but existing framework is not so. So, will the community be divided! :stuck_out_tongue:


#61

Yep, you’re right. it needs long time but not bad idea.

Value of forum won’t decrease. Because owners will share own product(library/asset/plugin/graphic) in here. (Just like unity forums or construct2d forums)

Yep :smile: Maybe some plugins, extensions or addons would be not free, maybe free. Competition can work.

But the first problem documents, tutorials, sample projects aren’t enough for new developers. Cocos2d-x is not good platform about that, you know. Look at Haxeflixel demo page and resource codes, Unity tutorials page.

Cocos2d-x is easy and great framework but too many developers are giving up in the beginner period because of that.


#62

Hi @pococogames

That’s a good point there, not many developers have patience, and they just move on to another game engine. Hopefully, in the near future, documentation, tutorials will improve…. God Bless…

Sincerely,

Sunday