征集引擎的开源体验

Creator 3.x
#1

大家好！

我们正在申请 GDC2023 的演讲机会，申请的是 Open Source Game Development Summit，目前进入到 Phase2，希望大家能和我们分享一些自己使用开源引擎开发游戏的体验，举例来说包括但不限于：

  • 引擎的开源如何帮助到你的游戏开发过程
  • 参与和贡献到引擎的开源开发（提交 issue，PR，参与讨论等）的经历
  • 选择引擎的时候是否把开源作为考量条件，以及对你来说重要的原因
  • 。。。

希望大家能分享一些具体的案例和故事，欢迎小作文 :scroll:

拜托了！ :pray:

2赞
#2

关于第一点我还是挺认可的，最近做的输入同步demo就很依赖能看到引擎源码去判断哪里需要改，哪里需要绕过，以及综合判断到底某个卡点是引擎问题还是我自己问题，目前也达到了理想的效果，这点估计用unity单人奋战会多花很多时间

1赞
#3

最近在优化粒子性能，把粒子系统大概看了下，感触还是很多的，一方便觉得开源很方便，有问题可以随时修改，一方便觉得目前社区pr参与度还可以更高～只能从我做起吧。。好的pr也不藏着了，大佬们都别卷了，多提多修pr，不仅可以获得社区开源者的tittle！提的多还可能有神秘奖励喔 :smiley:

3赞
#4

引擎代码怎么帮你判断需要改的位置的？还有你说的卡点是阻碍点还是卡顿？

#5

说说最近我遇到tiledmap出现缝隙的问题吧

最开始我以为是纹理采样的问题，经过一百圈的折腾，发现如果2个瓦片使用同一个纹理，就又没缝隙了

然后使用gDebugger工具开始各种分析，什么shader、texture、buffer各种查，查的头秃，还是没有找到问题所在。

问身边一圈大神，都是爱莫能助，没遇到这种问题，但是项目就是遇到了这个问题，真是让人头大的很

最后没办法了，只能从源码下手，然后开始追查顶点数据，发现提交的顶点数据也是没有缝隙的，

因为提交的顶点没有经过MVP矩阵转换，所以也想着不会是shader里面gl_Position的问题，直到后来一步步修改引擎源码，各种分析，确认了顶点式数据z和mvp矩阵相乘后，x,y发生了偏移，从而导致tiledmap出现缝隙。

一步一步下来，折磨我的同时，让我也成长了，从怀疑问题来自自己，到确认是引擎bug，下次再遇到硬骨头的bug，我丝毫不会畏惧，即使我对引擎不了解。

如果是闭源引擎，那这只能求爷爷告奶奶了。

3赞
#6

这。。。求个 PR 哈哈
感觉路线渐渐转向吐槽

1赞
#7

cocos 2dx 3.16的bug，就没pr的必要了吧

#8

也可以把修改片段发到这里，主要我感觉可能 creator 搞不好也有

#9

这样问就很尴尬了… 至少CCC 2.2.1吧，我需要碰撞时遍历玩家的顺序要严格按照“加入顺序”来保证确定性，那自带的碰撞系统如果本来就是这么做的或者有钩子改成这样就最好，但实际上是没有，起码我就可以下这个判断：这事要自己来并且不算浪费时间 – 虽然这好像不怎么值得说… 其他的也包括看了你们update怎么写的，决定在过快过慢的判断上自己能最少只新增多少代码这样的小点，确保每一个要确定性的地方我都知道来龙去脉。

“卡点”既有阻碍点也有真的卡顿，单说结果就是我曾经怀疑是因为CCC渲染性能问题的地方最后都证实是我自己的问题，导致多看了不少动画渲染那部分的代码 （实际上并不开心也并不高效，氧化钙） – 这种就属于我不看你源码能不能做出来吧，不好说，但看了能确信问题不在那里是很重要的，假如是Unity可能这种情况下就会陷入赖引擎的惰性思维了，或者找不到怀疑自己的有力依据

1赞
#10

明白了，网络同步的确定性问题，确实在引擎中考虑的不多

#11

这个没所谓的，我考虑过其他引擎，并不会更好做，我更看重的是“能快速准确地判断怎么做是最低成本的”这个好处，复杂的核心算法写多反而容易错

#12
#13

引擎开源能提供更多的可能性，遇到问题的时候可以追本溯源，找到问题的出错点，闭源的话就只能瞎猜了，运气好能猜到，运气不好就变成无头公案了，然后开源后扩展也比较方便，你可以很方便的扩展你想要的功能，比方你可以修改节点渲染顺序，扩展动态合图，修改文字渲染，增加视频音频播放器，增加wasm等等功能来解决特点游戏特点方向的性能优化问题，能检测的手段也更多，优化的方向提供了更多的可能性
扩展引擎现有功能，不用等引擎下个版本发布就自己合pr或者自己改修复线上bug，或者想要新的功能又不想升级版本的时候可以在现有版本基础上合入新的pr，出了问题也可以自己查，不需要等官方遥遥无期的排期而一筹莫展，实在不行crash了搞点骚操作直接绕过，对代码和研发周期的掌控性更强，引擎开源情况下也不用担心给你植入有些意想不到的代码，植入了也可以删。
然后针对某些特点平台的优化就更明显了，引擎为了跨平台的兼容性，有些方案的选择会倾向于兼容性，性能比较中庸，但是对于特定开发者来说，可能需要某个平台的性能最大化，如果闭源的情况下就很抓瞎了

1赞
#14

ScrollView、InputEditor
在友商（U）上基本难以在原基础上定制非常“高级”的功能
不仅仅是成员、函数私有，甚至还有Cpp / jni之类的更底层代码完全无法查看
只能直接重新写一个类似的出来

开源的话，就不用说了，js hack code结合继承能解决不少问题，
如果还不行直接看代码->修改
对于其他协作开发来说，只要不是破坏接口的修改，基本完全无感，不需要额外的学习成本

PR最近两天提交了两个
主要是对tiled map的问题进行修复
主要考虑到能将这些问题的修复推给你们，减少项目组其他成员定制引擎的步骤也是好的

开源肯定是引擎选择考量之一
不说别的，
升级引擎对于我们来说特别是国内需要“热更”快速解决问题的环境来说，成本巨大，也等不起

1赞
#16

以前在微信使用websocket 掉帧很厉害，不知有没有修复

#17

1.引擎本身的问题我们能直接修改，提高了工作时候的效率
2.很多时候，是通过学习引擎代码来提高自己的。
3.以前做RMXP这些小玩意的时候，很多效果不好实现，无从下手，到cocos这里后，没有不行的，不行就是你不行。反正就改，各种魔改
4.知道你们是不是在偷懒，后面的版本会改写啥

1赞
#18

太真实了！

#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赞