征集引擎的开源体验

Creator 3.x
#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

能开源编辑器不。

#39

自己看assetsmanage(热更) cpp的源码就有zip
处理 至于卡ui 完全可以在cpp层做异步回调

#40

希望可以一直开源

由于团队需求，花了2天在原生实现了一个堪用的多线程 Worker ，遇到大量密集计算卡主线程的情况再也不用眼馋 WebWorker

2赞
#41

这个很赞啊，只是这个又要魔改引擎了吗？