【调研，感谢支持】大家经常接入的第三方库都有哪些？

Creator 3.x
#5

JS库 ：JSZIP、protobuf、MD5、 QrCode
jar库: https://github.com/ChinaDragon01/CommonUtilsLibrary-master

#6

guid-typescript 生成唯一id
astar-typescript 用来做寻路

原生的话，一坨，比如用来发海外的话，google play 支付、各种登录、appsflyer统计、admob广告。像楼上说的，做这些事情都要先调整一次生成的项目，后续creator就用来构建个assets，原生构建面板的编译和运行，几乎没用过。

1赞
#7

如果官方可以做一个兼容层去兼容react native的plugin,那生态不就来了… :laughing:

#8

我自己也接过好些 SDK， 并没有发现工程有问题。 能展开说说吗？

#9

Oimo 吧，cocos自带的物理性能有点问题

#10

多人协作

多人协作是一个很正常的项目需求，目前一般都是通过git来协同合作

以 Android 平台发布为例，一个项目是需要接入很多SDK的，可能是由多名同学共同完成下面功能

  • 接入新的SDK
  • review
  • 修bug
  • 加功能
  • …

那么第一步，所有同学得要获取到 完整的原生工程代码，但是按照现在Cocos的原生工程目录结构，用起来十分别扭

以 3.x 构建的 Android 工程为例

一、默认构建目录位置问题

Cocos 构建后的 Android 工程默认是在 build 目录，这个目录是不会被纳入版本管理的。不注意的情况下，是项目新增的SDK接入代码，默认是在 build 目录上，这些代码是不会上传到仓库中，其他同学是没法看到。当然我们肯定有很多办法解决这个问题，比如

  • 可以修改 .gitignore 文件
  • 可以修改构建输出目录
  • 修改 build.gradle ，重定向 sourceSet 目录

这就需要我们改一下 Cocos 的原生项目路径或者结构了

二、项目文件太过零散

Cocos 默认构建的 Android 工程是 站在能方便引擎升级 的角度去创建的，由此，一个默认构建的Android 工程目录会十分分散

  • build/android/proj：Android Studio 工程的位置
  • native/engine/common：多个原生工程通用的配置
  • native/engine/android：Android Studio 工程的 Module 配置（包括 app ，instant app）

到这里已经很难接受了。为什么呢？

正常的Android 工程，app module和 settings.gradle 都是一个目录的

而 cocos 这边却分开了两个地方

  • app module 在 native/engine/android
  • settings.gradle 在 build/android/proj

甚至 app module 所在的 native/engine/android 是一个 ignore 掉的目录

简单来说

  1. 你修改的 app icon，是不会同步到 git 仓库中
  2. 即便我们刚刚说的第一步「构建目录」位置不放在 build 目录了，放在其他能纳入版本管理的地方，还不行，因为你还必须处理 native/engine/common ， native/engine/android 这两个 ignore 掉的目录

那么

  1. 你要是移动了 native/engine 的目录，你还必须修改里面 CMake 文件的里面目录路径
  2. 你要是将 native/engine 目录纳入版本管理，那么势必和其他机器生成的 native/engine 产生冲突

怎么处理都是个麻烦事，但是还是得处理

这就需要我们改一下 Cocos 的原生项目路径或者结构了

三、大量绝对路径

像上面刚刚提及到的目录

  • build/android/proj：Android Studio 工程的位置
  • native/engine/common：多个原生工程通用的配置
  • native/engine/android：Android Studio 工程的 Module 配置（包括 app ，instant app）

里面的文件存在大量本机绝对路径的使用，这几乎又是一个难以做多人协作的项目生成方式

比如：build/android/proj/cfg.cmake

set(COCOS_X_PATH "/Applications/CocosCreator/Creator/3.7.1/CocosCreator.app/Contents/Resources/resources/3d/engine/native")

这样子的路径，如果我将这个提交上去，那么让同项目的 Windows 的同学怎么能跑起来呢？

那么肯定是我的使用方式不对。

可能在Cocos看来，多个同学开发 Android 游戏流程如下：

10个同学协同开发一个android游戏，那么这10个同学各自在自己机器上构建各自的Android 工程，去编译构建运行

但是，我觉得应该不是这样子的，正确的开发方式应该是这样子：

10个同学协同开发一个android游戏，应该是其中一个同学提交一份Android工程，然后10个同学共同维护这一份 Android 工程，在里面去协同开发

而现在实在是心情复杂

尽管如此，这个绝对路径的问题在Android上其实还好处理，不多，但是一到构建 iOS 的XCode 工程，实在是一言难尽

四、小总结

简单来说，我们主要是探讨怎么实现多人协作，具体一点是怎么将一个「完整」的Android工程提交，就这一点，已经是十分麻烦了

8赞
原生构建
#11

谢谢分享，我先对比分析分析。

#12

官方终于觉悟了 像常见的平台（如字节 微信 小米 ov 苹果 谷歌 taptap）登陆 广告SDK 扫码(QRCODE)倒是其次

#13

cocos的原生工程 我呵呵

#14

其实个人觉得 安卓端的 不应该有引擎组去适配的 因为很多东西 都需要自己手动去调整的 就好比 每台机子的sdk都不一样 这个大可以找个专业的人去写好一个完整的安卓 同事在自己电脑换合适的路径 替换文件可以

#15

Hello，大家好。 我补充说明一下。
我做这个调研，不是说要集成SDK到引擎中。
只是想了解一下大家的需求后，以合理的方案，让大家更容易集成和使用SDK。

#16

这个有什么结论了吗

#17

WalletConnect, 接入一直失败，求walletConnect 成功案例

#19

众所周知，我们都没写过几行代码

#20

总所周知, 我们都没写过几行代码

#21

游戏开发里面需要json序列化映射类的这种基本上都是应用在配置文件的解析中吧

#23

json转成typescripts，语言层面上来说，不管你用什么类库，大概率都是先创建对象，再把数据传进去初始化，返回创建的对象。众所周知，我们都没写过几行代码。这么复杂的轮子我们通常还是自己写，这样说出去我们代码行数又多了

#24

（帖子被作者删除，如无标记将在 24 小时后自动删除）

#25

我们通信和配置文件都是二进制，写一套解析工具，还有自动化生成对应的声明文件，json从来都没有用在这里过，用json的通信我觉得是真不上来哪里好

#27

自己写，类似于protobuf，都是二进制序列化和反序列化，我们项目里面基本上不会直接用json