征集引擎的开源体验

Creator 3.x
#19
  1. 开源的好处就是可以看源码，引擎的逻辑能够一览无余，当你在遇到问题的时候不仅仅有一味地求爷爷告奶奶这种选择，可以选择自己阅读引擎源码、修改源码解决自己的问题。
  2. 以下我的实际经历：
    项目需求需要实现子游戏大厅功能，通过bundle方式确实能实现部分，并且很好实现，但是有个问题资源可以热更，但是脚本不行。于是去翻引擎源码，找到js加载注册的地方，并进行了修改，重复加载脚本的问题就解决了。但是加载bundle并不会重复加载同样的index，看了引擎源码，加载bundle的地方，发现是可以手动传入版本的方式进行重新加载，于是我通过修改热更工具在生成的逻辑，在config、index打上热更版本的标签，这样一个完整的子游戏大厅的工具就产生了，目前已用在公司多款商业项目中。
  3. 首先感谢引擎组吧，虽然引擎有bug，但是开源啊，而且引擎组也有很积极的解决
    感谢论坛大佬测试出的脚本不能热更的bug，第一次做插件确实有些草率了。
    也感谢各位对插件的支持，以及信任
3赞
#20

欢迎来到cocos大型黑粉炸:fish:帖

#21

我说说我碰到的问题吧。都是通过魔改引擎去实现的。

2.4.0没有支持astc，引擎后续版本也没支持，一直到3.x才支持的。我自己按照3.x实现了astc。质的飞跃。但是2.4.0的编辑器不支持直接打包出astc纹理，后面只能写脚本，自动化处理。

在做2.4.0支持bundle压缩包热更/普通对比文件下载热更2种方法的时候，第一个问题就碰到了用cocos的下载接口在安卓那边处理不合理，用的是 callTimeout 意味着整个函数调用超过10秒就会导致下载失败。但是大文件，10秒钟下不完的，后面改成了 connectTimeout writeTimeout readTimeout 3种方式去判断是否超时。cocos在这里就没有做好处理。

后面有碰到了2.4.0不支持紧挨在安卓可写路径下的文件，按照2.4.3的模板又魔改了一次。

分包之后，因为需要支持压缩热更，最开始解压逻辑是放在安卓处理的。后面因为游戏文件大了，差不多有100M以上了，这个时候，在一些比较垃圾的安卓手机解压很慢，差不多需要将近20s。后面把安卓解压改成了c++解压，效率飙升，只需3-5s。不过这个时候产生了几个问题，c++解压会阻塞UI线程，安卓解压放到了UI线程，虽然慢，但是能刷新UI。 还有个就是引擎的 ZipUtils 这个类，明确的引用zlib。为啥不加个压缩方法暴露出来呢。还得用户自己处理。

说回来，开源最大的好处就是方便大家自己动手，有啥问题自己能解决的就提前解决了。
cocos能发展到这么大，开源功不可没。但凡是闭源的，BUG这么多，用户早跑了。实话实说

1赞
#22

不管是开源还是闭源， 首先要把基本的功能做好，然后再加其它功能，不要一些基础问题，很多版本都不管。 做的好，哪怕收费都愿意用。

1赞
#23

感觉 Cocos 2.x 的那个 cc.d.ts 的方式挺好的, 请问 Cocos 3.x 后续会弄类似这个的功能吗 ?

Cocos 的引擎开源很赞

因为可以按照自己的想法添加一些功能, 提高效率 :grinning: :+1: :+1:

另外, 确定性物理引擎(2D就行) , 请问有计划做吗 ?

#24

如果是闭源引擎，只能依赖引擎足够完善，自身没有问题，使用者也不会遇到问题，不然遇到问题网上又没有解决方案的时候，真的就无力了。事实上没有问题的软件是不可能存在！
但是开源引擎就好多了，遇到问题可以随时去翻代码，浅层的代码写的很好，我这种小菜鸡阅读起来也没什么障碍

例子1

最近遇到的两个问题，都是网上找不到解决办法，最后去翻引擎代码搞定的


例子2

平时写代码的时候，遇到疑惑的地方，也可以去翻引擎来吃定心丸
比如自己写了个load函数，里面是getComponent(Sprite).spriteFrame = xx 。就会担心性能问题，要不要考虑判断一下是相同图片就不重新赋值，结果去翻代码发现引擎已经做好了

image
image698×182 15.4 KB

这种不放心的时候随时可以看具体实现的体验，真的是晚上睡的太踏实

例子3

引擎的代码编写还是比较规范的，对于我这种小菜鸡来说，有样学样就可以把事情做好了
比如最开始接触ccc的时候，想获取坐标的时候都是node.getPosition()，也没有注意到引擎建议复用vec3。
后来在引擎代码里看到很多image 这样子复用的

再比如之前需要在不能复用的tween里先设置节点坐标为0，那就会.set({position:new Vec3(0,0,0)}) ， 那其实写Vec3.ZERO就可以了，同样的还有类似Color.GREEN

例子4

可以编写更符合需求的自定义引擎
比如小游戏环境在裁剪包的同时，还会用到包内的一小块功能，那就自己去阉割
比如瓦片地图渲染裁剪可以优化为不同layer可以共享裁剪范围计算结果（论坛也已经有大神优雅的实现了）

2赞
#25

之前做物理帧同步的时候遇到不同步的问题

一开始打印位置是完全相同 然后 玩了一会发现不同步 (因为这件事找了好久问题 甚至怀疑能不能这样做)
然后发现是因为 同一个场景 运行次数不一样结果也是不一样 之后定位到 重置场景时候物理系统其实不是初始状态 也就是 每个设备的物理系统的状态是不一样的

后面阅读源码 添加了一个清除物理的方法 每一次重置场景初始化新的物理系统 就没问题

只要你做帧同步 遇到重连 回来追帧 或者 关卡类 都会遇到

目前上线半年 并没有遇到不同步现象

官方可以加个重置物理的方法 (说不定很多人遇到这种现象以为是 浮点数什么的 我认为只要计算结果一致都是可以帧同步的 比如 1 + 1 = 1.9 所有设备算 1 + 1 = 1.9 那就没问题 只要有一个 = 2 那这个设备就不能帧同步 反正结果要确定性 就行 目前没有发现设备计算结果是有不一致的)

这是我自己的理解.

4赞
#26

ios退出app导致的崩溃，有官方大佬带带嘛https://forum.cocos.org/t/topic/143275

#27

大佬, 请问方便讲下您这个清除物理是怎么做的吗 ? 是要改引擎还是什么 ?

#28

我之前帖有很简单 就是加一个方法把物理对象赋值 null 然后系统用到物理的时候发现null 就会自己初始化新的物理 JNGame: NGame 是一个Java网络游戏服务器框架 拥有RPC调用方式 使用 WebSocket UDP 成熟 注解API 立即启动各种服务器 NGame还有 各种游戏引擎联机同步DEMO (cocos,unity) 和 各种同步案例(帧同步,状态同步,状态帧同步) 持续更新中… 遇到问题请联系QQ:2858626794 - Gitee.com

1赞
#29

需要改引擎

1赞
#30

:+1: :+1:
ok, 感谢大佬

#31

这个问题creator3.6.3还会有 :crazy_face:

#32

也没有注意到引擎建议复用vec3…
文档在哪写这些了么，我也没看到过 :sweat_smile:

#33

卧槽
image

#34

翻源码注释

#35

编辑器插件部分建议
需求：保存场景或预制体时能否出一个用户参与的钩子，当场景或预制体保存时，等待用户的逻辑处理结果，再来决定是否执行保存逻辑
原因：有时团队合作时需要强制限制一些内容，比如命名，结构，资源引用等，为了保证这一点，需要开发一个保存时校验的插件，如果不合格就不允许保存成功，或者利用插件帮它修改之后在保存，由于目前引擎没有提供这方面的功能，想要实现这个就需要一些其他操作来解决，还是希望官方可以出一个正版的解决方案（引擎只需要开放一个接口，然后等待处理结果，根据用户的处理结果来决定是否执行引擎内部的保存逻辑）
比如，在用户保存时，将保存的场景或预制体的数据处理好之后先不要执行保存的逻辑，而是先发送一个request广播，并把这些数据也带上，如果有监听者就等待结果，然后根据返回的true或false来决定是否进行后续操作
这本身并不会影响编辑器的逻辑，并且可以让用户更多的控制编辑器行为

#36

现在是有发广播的，但是消息列表中暂时没有，后续会补上，消息为’scene:save’
扩展可以参考下列文档
https://docs.cocos.com/creator/manual/zh/editor/extension/first-communication.html

#37

兄弟厉害。说的太对了

#38

能开源编辑器不。