还有就是lua是不是要被弱化了，怎么感觉几个版本中 lua的配置都不同，命令行生成pkg什么的，要是能有个集成的，自动识别环境下载对应系统所需的软件啊 插件啊什么的。
如果是比较生疏的新手，配置那些环境搞上一天都可能的。
类型：建议
平台： android
版本： cocos2d-x v3.0-beta2 / cocos2d-js v3.0-alpha / …
关键字：cocos2dx android adt
描述：
建议：
引用 bingwa的原话
我感觉挺好的。不过运行android的确各种坑。虽然解决了一个android上的发布。但是现在新的游戏又不知道怎么做。运行cocos run -p android 没有问题，但是用eclipse进行签名打包，就出错。哎呀，各种的蛋疼。 iOS倒是没有什么问题。
我也觉得是，虽然cocos run -p android是生成apk包了，但是导入adt,好像又有问题。。。。直接运行会出错，
麻烦测试一下,把proj.android导入adt，怎样可以一键运行，谢谢
类型：建议
平台： android
版本： cocos2d-x v3.0-beta2 / cocos2d-js v3.0-alpha / …
关键字：cocos2dx android adt
描述：
建议：
jni/…/…/Classes/extensions/assets-manager/AssetsManager.cpp:27:23: fatal error
: curl/curl.h: No such file or directory
#include <curl/curl.h>
^
compilation terminated.
使用cocos run -p android ，经常出现curl编译过不了的，是要弄curl,应该不止curl是跨平台的库，类似还有websocket,
能不能把这种不同平台的差异库，怎样编译的教程弄一下呢? 谢谢
类型：建议
平台：all
版本：all
关键字：CCScrollView
描述：滑动操作效果不好
建议：CCScrollView, CCTableView 手势滑动效果不太好，对比下原生的就知道了，强烈建议优化一下
第三方库接下来也会着手做教程的，么么哒。。。
了解～我也有体会。。。
类型：建议
平台：all
版本： cocos2d-x v3.0
关键字：声音
描述：播放声音的时候不能获取播放的进度
建议：希望可以加上播放声音的时候可以获取播放进度
3.0RC 编译的时候，没有输出任何编译信息。
调试的时候时候提示：
Unable to read AndroidManifest.xml
速度解决啊。。。。
已无力吐槽…坐等被Unity打败
既然这里可以吐槽，那小弟我也顺便说两句，cocos2d-x被我们主程批得体无完肤，主要是对cocos2d-x最初的设计提出的批评，指责cocos2d-x完全翻版cocos2d-iphone，抛弃了C++很多很好的语言特性，甚至都顾不上分析一下C++和Objective-C之间的语言差异，比较严重的摘录如下：
1）二段构造完全是废物，Objective-C没有构造函数，只能先分配内存，再初始化，C++的构造函数才是C++里最自然的创建对象的方法；如果照搬Objective-C，应该先分配内存（不用new），再用定位new构造。至于王哲先生对二段构造的解释十分的无力，构造函数应该被设计为支持创建最基本的部分，因为对象总是应该被构造出来，而产生异常应该位于其他行为，包括对象构造之外的其他创建过程中。仅仅因为二段构造中的第二次构造不是构造函数，而且有返回值，就坚持使用二段构造未免太草率，另一个原因是也许王哲先生没想那么多，直接把cocos2d-iphone的东西搬过来了
2）成员函数指针是垃圾，这个问题是这样的，我们主程有一次对CCLayer做了一次封装，做了一个Screen类，这个类没有继承于CCScene，也没有继承于CCLayer，而是一个外部类，正如cocostudio早期版本的UIWidget封装CCNode一样，CCScene成了Screen类的一个成员，按理这没什么问题，但是涉及到触摸事件时，由于触摸事件全是由函数指针实现的，所以不得不对Screen做CCObject继承，如果不做继承，就必须额外写一个小类继承于CCObject，再由这个小类通过观察者模式或friend授权传递到Screen类中，这样就增加了代码复杂度。我们的主程是一个对设计要求非常高的人，他完全不能容忍cocos2d-x在语言层次上就毫无灵活可言，Screen作为一个外部封装类，应该成为一个单纯的无需任何继承的类，但不得不对cocos2d-x妥协
3）这一点还是针对成员函数指针的，应该是上一点的续，先说一句，我们主程在编码中已经基本放弃了函数指针，包括成员函数指针，他认为这些是面向过程的东西，放到完全面向对象的设计中是一个很不伦不类的东西。我们主程对前期设计非常重视，为此也创造了一套编程守则，其中一点是根据接口编程，不要根据实现编程，这有效的降低了模块间耦合，合理分配相对独立的工作，这样做的确非常好，但碰到成员函数指针就出问题了，首先根据需求确定接口，然后根据接口创建实现类，好了，在创建实现类的过程中出了问题，他依次继承了接口类、另一个实现类（就是Screen，这个时候Screen还没继承于CCObject，需求本身就是要创建一个窗口），最后继私有承于CCObject，因为有触摸事件。编译完全没有问题，但运行就是出错。查了半天，终于得出结论，成员函数指针所了解的类型信息有限，只能以对象首地址作为调用方，而该成员函数指针要求CCObject类型作为调用类型（现在cocos2d-x所有的常用事件全是以CCObject为调用类型的成员函数指针），则必须要求首地址必须向后偏移8个字节才能到达CCObject类型，才能正确调用。将私有继承的CCObject类型挪到第一继承位置就解决了这个问题。我们主程的牢骚是，如果我也用成员函数指针，需要以我自己的类作为调用类型，该怎么打这个架
4）这个最有意思了，大家可以先去找到CCObject这个类，然后观察一下autorelease这个方法，这是个非虚的普通方法，然后再去看CCHttpRequest这个类，上面有个方法，也定义了autorelease()方法，然后注释上还清楚的写着override，然后我们主程就开始发作了；随后，我们主程发现，必须在new CCHttpRequest后，不得不调用release将其释放，new和release成对使用！我猜我们用C++编码十年的主程已经被毁三观了
我们主程最近编程的时候得出一个结论：王哲先生做的最伟大的事情是把一个垃圾推向了全世界。当然这个话我个人觉得有点过，我们的主程确实非常擅长设计，他提出的这些问题很明显在一个高端编程人员来说都是不可饶恕的，但对于入门的人来说，这样的免费引擎已经做的很好了，当然，也期望cocos2d-x能够越做越好。
我想说，楼主，我今天准备带着9秒2000来来吐槽了…:904:如果Android-10还是有错…你懂的:877:
:879:会发生什么事情，我也不知道:867:
你们主程好腻害…为啥不去设计引擎，而跑来开发游戏呢…难易程度适中，比较适合，中低端开发者…至于高大上完全可以用UE3 U3D
能提供相应的签名打包错误信息么。。。
这是个好建议，没准以后可以直接用cocos2d-x做个mp3播放器。。。 :882:
从Cocos2d-x2.1.4版开始学习，那个版本的CCFade三个动作类适用于CC、UI（cocoStudio导出的）控件，如今用到了2.2.3的版本，结果发现这三个动作类变成了后娘养的，不论是Cocos2d::ui::UIImageView，还是Cocos2d::ui::ImageView都不能使这个动作有效，难道需要多办什么手续？？？
我想知道为什么getCamera()用不了？
3.0rc0物理引擎碰撞检测回调设置有问题，不能继续这样监听碰撞了：auto contactListener = EventListenerPhysicsContact::create();
contactListener->onContactBegin = CC_CALLBACK_1(GameLayer::onContactBegin, this);
_eventDispatcher->addEventListenerWithSceneGraphPriority(contactListener, this);
官方的demo 可不可以更新一下
2段构造的问题，其实在c＋＋11以前，构造函数有很多的缺点，比如说一个构造函数不能调用另一个构造函数，非常的蛋疼，2段构造的保留也是对于api的11.一种相对稳定，如果现在要更改2段构造的话，api会大改，得到的是没有太大意义的提升，我个人认为对构造函数的一种封装是非常有必要的，加入封装以后可以加入自动化的内存管理，以及一些对底层的隐藏，虽然现在autorelease我个人认为确实不怎么样，可能以后会有较好的其他方法，比如智能指针。
2.在c＋＋11以前回调使用函数指针是非常常见的，虽然使用接口方式也可以实现回调，但我个人认为也变相增加了复杂度，很好的例子就是2.x的触控事件需要继承，也就是说，在c＋＋11之前如果要使用多个模块的回调函数的话，需要很多重的继承，明显增加了代码设计的复杂度。
3.成员函数指针必须继承在首位的问题这个确实是没有办法的事情，由c＋＋的特性决定，好在这些问题在c＋＋11中都得到解决，在cocos2dx3.0中我们使用lamba，非常优美的低偶和的做法，我个人非常喜欢lamba。
4.autorelease的吐槽我也非常认可，也许是因为智能指针的效能较低原因，还有就是可能会对api大改，这是非常不好的。
其实我觉得这个吐槽还算常见的，有吐槽才会有进步！