我为什么应该选择 quick-cocos2d-x
1个回答
展开全部
最近有不少开发者都向我提出了一个问题：我为什么应该选择 quick-cocos2d-x？
这个问题在我看来，实际上包含几重意思：
1. 为什么会出现 quick 这个项目？
2. quick 和 cocos2d-x 到底有多大的区别？
3. 选择 quick 还是 cocos2d-x？
4. 选择 quick 的风险有多大？
5. quick 未来的路线图是什么？
----
1. 为什么会出现 quick 这个项目？
关于这个问题，我在 cn quick-x com 上有一个详细的说明，简单概括那就是：开发商需要一个更完善的 cocos2d-x + Lua 的解决方案。
2. quick 和 cocos2d-x 到底有多大的区别？
区别分为几个层面：
2.1. 底层 C++ 代码：quick 是建立在 cocos2d-x 基础上的开源项目，对 cocos2d-x 的功能几乎没有做裁剪（除了用一些更好的 Lua 扩展组件代替 cocos2d-x 内置的），主要修改都是新增功能。cocos2d-x 的 C++/Lua 项目拿到 quick 里是完全可以跑的。
2.2. 扩展的功能：针对开发商的实际需求，quick 里提供了加密解密、网络请求、IAP、第三方 SDK 集成、物理引擎封装等一系列扩展。这些扩展都是独立的代码，并不侵入 cocos2d-x 的底层代码。
2.3. 对 cocos2d-x 的改进：主要包括 Lua 支持的改善，以及触摸事件机制的改进。前者是为了游戏运行更稳定，后者则简化了 UI 的开发。
2.4. 一个 Lua 框架：quick 包含的 Lua 框架，绝大部分功能都可以直接跑在 cocos2d-x 上（实际上有开发商这样做）。这个框架的价值在于将 C++ 风格的 API 转为了 Lua 风格，让开发者可以用更精简的代码实现更多的功能。并且框架定义的规范、接口，让开发者可以创建更容易维护的程序代码。
所以 quick 和 cocos2d-x 就像美女穿衣服和不穿衣服的区别。
3. 选择 quick 还是 cocos2d-x？
如果你认为 Lua 是更靠谱的选择，那么请使用 quick。
4. 选择 quick 的风险有多大？
我能想到的有几点：
4.1. quick 的作者发疯了，对 cocos2d-x 乱改一气，造成了 quick 和 cocos2d-x 的兼容性被破坏。我不敢保证不会有这一天，但是我时刻警醒自己抵制住这种诱惑。大家需要的是一个可靠的产品，而不是一个按照个人意愿随心所欲改变的玩具。
4.2. 主要维护者跑路了，不维护 quick 了。我想出现这种情况，要么是转发过了 500，要么是 cocos2d-x 这个体系已经玩不转了。
4.3. quick 不再跟随 cocos2d-x 升级。这个请放心，当 cocos2d-x 3.x 成熟的时候，quick 会第一时间发布匹配的版本。追求新技术，是有节操程序员的基本素质。
5. quick 未来的路线图是什么？
quick 的架构会继续保持：cocos2d-x 最小修改 + 扩展 + Lua 框架 的形式。这样对 cocos2d-x 的修改最小化。同时，我们会努力将 quick 中对 cocos2d-x 的改进推送到 cocos2d-x 官方仓库。希望有朝一日能够实现官方版 cocos2d-x + quick 扩展 的架构。
而具体到功能上，quick 在 2013 年将实现下列目标：
5.1. 一个功能全面的 UI 库：亮点是自动布局管理和可扩展的 UI 控件。因为整个体系都是 Lua 实现，所以可以充分利用动态语言的优势。
5.3. 一个 MVC 库：包含基本功能的 MVC 架构，提供清晰的 API 和代码组织结构，并且可以很容易的扩展。
5.4. 全面的网络解决方案：异步 HTTP、HTTP 队列、Socket 接口和 WebSocket 接口。
5.5. 在线更新：在线更新游戏的脚本和资源，绕开蛋疼的 App Store 审核。
5.6. 第三方 SDK 接口标准化：目前已经支持 App Store IAP, Umeng, Flurry, 91, DianJin, Domob, YouMi 等 SDK 的接口。而今年我们将把这些 SDK 的接口标准化，实现类似 cocos2d-x plugin-x 的架构。但因为是动态语言，所以在灵活性上会有显著优势。同时我们也会陆续添加其他 SDK 的接口。
5.7. 专职团队：随着使用者的增加，我们也会尝试提供一些商业服务，这样 quick 将会拥有一个专职团队。未来的发展更快更好。
未来，quick 将按照平均每月一个版本的速度发布。而即将到来的国庆版，将实现 UI 库的基本架构和布局管理，以及在线更新功能。
这个问题在我看来，实际上包含几重意思：
1. 为什么会出现 quick 这个项目？
2. quick 和 cocos2d-x 到底有多大的区别？
3. 选择 quick 还是 cocos2d-x？
4. 选择 quick 的风险有多大？
5. quick 未来的路线图是什么？
----
1. 为什么会出现 quick 这个项目？
关于这个问题，我在 cn quick-x com 上有一个详细的说明，简单概括那就是：开发商需要一个更完善的 cocos2d-x + Lua 的解决方案。
2. quick 和 cocos2d-x 到底有多大的区别？
区别分为几个层面：
2.1. 底层 C++ 代码：quick 是建立在 cocos2d-x 基础上的开源项目，对 cocos2d-x 的功能几乎没有做裁剪（除了用一些更好的 Lua 扩展组件代替 cocos2d-x 内置的），主要修改都是新增功能。cocos2d-x 的 C++/Lua 项目拿到 quick 里是完全可以跑的。
2.2. 扩展的功能：针对开发商的实际需求，quick 里提供了加密解密、网络请求、IAP、第三方 SDK 集成、物理引擎封装等一系列扩展。这些扩展都是独立的代码，并不侵入 cocos2d-x 的底层代码。
2.3. 对 cocos2d-x 的改进：主要包括 Lua 支持的改善，以及触摸事件机制的改进。前者是为了游戏运行更稳定，后者则简化了 UI 的开发。
2.4. 一个 Lua 框架：quick 包含的 Lua 框架，绝大部分功能都可以直接跑在 cocos2d-x 上（实际上有开发商这样做）。这个框架的价值在于将 C++ 风格的 API 转为了 Lua 风格，让开发者可以用更精简的代码实现更多的功能。并且框架定义的规范、接口，让开发者可以创建更容易维护的程序代码。
所以 quick 和 cocos2d-x 就像美女穿衣服和不穿衣服的区别。
3. 选择 quick 还是 cocos2d-x？
如果你认为 Lua 是更靠谱的选择，那么请使用 quick。
4. 选择 quick 的风险有多大？
我能想到的有几点：
4.1. quick 的作者发疯了，对 cocos2d-x 乱改一气，造成了 quick 和 cocos2d-x 的兼容性被破坏。我不敢保证不会有这一天，但是我时刻警醒自己抵制住这种诱惑。大家需要的是一个可靠的产品，而不是一个按照个人意愿随心所欲改变的玩具。
4.2. 主要维护者跑路了，不维护 quick 了。我想出现这种情况，要么是转发过了 500，要么是 cocos2d-x 这个体系已经玩不转了。
4.3. quick 不再跟随 cocos2d-x 升级。这个请放心，当 cocos2d-x 3.x 成熟的时候，quick 会第一时间发布匹配的版本。追求新技术，是有节操程序员的基本素质。
5. quick 未来的路线图是什么？
quick 的架构会继续保持：cocos2d-x 最小修改 + 扩展 + Lua 框架 的形式。这样对 cocos2d-x 的修改最小化。同时，我们会努力将 quick 中对 cocos2d-x 的改进推送到 cocos2d-x 官方仓库。希望有朝一日能够实现官方版 cocos2d-x + quick 扩展 的架构。
而具体到功能上，quick 在 2013 年将实现下列目标：
5.1. 一个功能全面的 UI 库：亮点是自动布局管理和可扩展的 UI 控件。因为整个体系都是 Lua 实现，所以可以充分利用动态语言的优势。
5.3. 一个 MVC 库：包含基本功能的 MVC 架构，提供清晰的 API 和代码组织结构，并且可以很容易的扩展。
5.4. 全面的网络解决方案：异步 HTTP、HTTP 队列、Socket 接口和 WebSocket 接口。
5.5. 在线更新：在线更新游戏的脚本和资源，绕开蛋疼的 App Store 审核。
5.6. 第三方 SDK 接口标准化：目前已经支持 App Store IAP, Umeng, Flurry, 91, DianJin, Domob, YouMi 等 SDK 的接口。而今年我们将把这些 SDK 的接口标准化，实现类似 cocos2d-x plugin-x 的架构。但因为是动态语言，所以在灵活性上会有显著优势。同时我们也会陆续添加其他 SDK 的接口。
5.7. 专职团队：随着使用者的增加，我们也会尝试提供一些商业服务，这样 quick 将会拥有一个专职团队。未来的发展更快更好。
未来，quick 将按照平均每月一个版本的速度发布。而即将到来的国庆版，将实现 UI 库的基本架构和布局管理，以及在线更新功能。
本回答由提问者推荐
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
