一些底层轮子的代替方案

lvkuozi · 发表于 2023-8-15 15:53

由于一些变换，公司的轮子自然不便利再用了。但是搞了快两年的底层研发自然也不应该是毫无价值的，没了必定也很麻烦。
那么到底有多麻烦呢？有哪些工作是必需再做一次的呢？
我就稍微盘了一盘。

脚本

脚本必定还是静态语言更好（如果条件允许我其实更愿意嵌入C#），但如果考虑到成本，还是尽量随大流以降低风险。动态语言虽然不好，但从实践角度出发，可用（粗略估计开发效率降低概略30%摆布），只要不给筹谋用就行。
SLua/UnLua都有UE的实现，但我没接触过，还得调研下实际使用者的感到感染。
我们的方案基本是由Puerts改过来的。既然会改，自然是车雄生他有做的不好的部门（- -）。不外据了解，主要解决的问题也就：

TS和C++对象的彼此引用会导致内存泄露
不撑持Struct的值拷贝
API风格

……
做过Unity项目的人都知道，前两个问题……以前的Unity脚本方案其实也都不解决的(需要手动措置），没有任何问题。而且Puerts都搞了两年多了，这些问题也未必没有解决。
所以这样看，是完全可以直接使用Puerts原版的。
(UE本身的脚本以后也可以考虑)

工作量-1。

图形化编程

蓝图，是凑合可以用的。
蓝图第一个缺陷是效率，作为筹谋脚本这并不是关键问题，关键的缺陷还是在于可维护性。
然而，改换成其他图形化编程模式（Scratch）要的成本还是斗劲多（2人半年其实不太能接受，做到完备估计还要再加半年），更不要说虚幻里处处都是蓝图，你没法把他们都换了。
可维护性这种东西，还是可以通过规范进行控制的。大不了写完找人review。

如果必然要提供一个类似Scratch的图形编程界面给筹谋用（技术必定直接用TS），我们也可以选择一个非常简单的方案：在TS的编纂器左边放一个目录，里面的条目是各种语法模板(if,for)，再下面是各种业务功能分类的函数，双击就会把代码填到右边的文本编纂器里，这也能大幅缓解筹谋的代码恐惧症。

工作量-0.5。

技能编纂器

虚幻的GPA其实做的挺好的，可以省掉非常多的开发量。业务代码每个游戏都分歧，不能算在轮子的范围内，剩下的主要内容其实就是个时间线编纂器。
这个还是必需实现的，但或许也有其他的商城轮子可以做为参考。

当然还有定帧一类通用功能，该重写还是要重写。技能几乎是局内逻辑的全部好吧。

数据编纂器

表格可以直接使用tablegrid，但纯挚的二维表格表达能力还是太差。
不想做东西，最简单的方式是直接用xml作为树状数据的表达方式，并使用一个通用xml编纂器。通过编写法则模板，同样可以实现数据自动补全等功能。
然而真的只靠通用xml编纂器还是斗劲勉强(至少无法实现拖拽资源填入)。条件允许后也可以在UE做一个特供的通用xml编纂器，用slate的方式显示xml数据，按照法则文件提供完整的错误查抄和选择设值，其实也不复杂，快的话周人就能搞定。

工作量-0.5

ECS

虽然我认为ECS没有任何问题，但是要按ECS的方式做游戏必需确保性能。而确保性能，需要在框架层写很多memcpy代码，挺不不变的。
而且很多人用不惯这个。
为了这点好处不值得，扔了算了。等UE本身的做出来再说。

UI框架

UMG的PSD2UMG流程还是挺好用的，对于快速开发不成或缺。
UMG也自带数据绑定功能。这部门绑定代码由技术来写好了。为了可维护性，可以禁止绑定脚本使用任何外部数据和函数(这样即使蓝图代码不好维护，也只会污染这一个umg窗体），代替方案是在umg顶层创建一堆变量和函数，并通过绑定脚本绑在具体的组件数据上。
尔后，其他业务法式员填凑数据和监听时，就只负责给这些变量赋值，而不需要关心umg窗体内部的情况，内部组件名都可以瞎起，省去无意义的劳动。没有任何id和字符串也容易维护。
(通用功能组件化还是要做的，UMG也能做)
UMG这个绑定也算是一个mvvm框架，便当程度也还成。所以即使它有那么多灾用的处所……哎，也没法子，毕竟也没什么此外选择。
自研ui衬着和mvvm框架的代价太大了，最后工作效率也未必比使用UMG的原始绑定高。
但UMG本身还是要改改的。

工作量-0.5

MQ/处事器

找个现成的好了。没必要。

AI

HTN挺不错的，对比行为树多了图形化决策的功能，可以减少复杂AI的硬编码工作。
但对比行为树确实更复杂了，筹谋更难掌控了。
总之不管谁做吧，HTN确实能减少复杂AI的工作量，即使使用者是技术。找人掌控住还是有意义的。本来就懂行为树的人学这个也不难。

摄像机

这个有些绕不外，毕竟3C之一。
UE本身的摄像机还是没影。

布料

我也就拿kawaii改了一周，再来一次无妨。
后来发现一个类似功能的轮子，但功能没改好的全。弹簧质点模型也就这样。不外未来可能还可以进一步优化下性能。
https://github.com/SPARK-inc/SPCRJointDynamicsUE4

单行道 · 发表于 2023-8-15 15:53

这个工作量有点太多了吧

zxdxzh · 发表于 2023-8-15 15:54

虽然我认为ECS没有任何问题，但是要按ECS的方法做游戏必须确保性能。而确保性能，需要在框架层写很多memcpy代码，挺不稳定的。
请教大佬这句话何解？
我们做的仙侠古风mmo也是自己在Lua层写了ECS，现在用uwa测挂机战斗用例（场景简单，挂机打十几个怪），红米note9上跑，lua逻辑开销大约在7.4ms左右

cyh123321 · 发表于 2023-8-15 15:54

你们是硬套了esc的壳？lua这种不适合ecs的语言咋ecs的。

aspmx1195 · 发表于 2023-8-15 15:55

ecs的标准写法会存在大量的重复遍历。如果性能不出问题，一，说明根本没有按ecs的写法，二，规模太小。不过都选择lua了，说明量级本来就不高。量级不高选啥都行。那干嘛不直接用ec？

sjh163 · 发表于 2023-8-15 15:55

我承认我对性能有点洁癖。可问题是，非要用ecs也是另一种洁癖。次优解很多，直接都可以不干活，干嘛非要用这个。

cnsyk · 发表于 2023-8-15 15:55

这个级别的逻辑开销看起来已经很大了

twinsbbs · 发表于 2023-8-15 15:56

Ecs要面向缓存友好编程，使得被遍历的数据在内存中连续从而提高cpu cache命中率

蓝色人类 · 发表于 2023-8-15 15:56

技能编辑器那块，要时间轴可以考虑able插件

wuchao · 发表于 2023-8-15 15:57

ECS上脚本作用真的大吗？它是面向数据，也就是Cache友好的设计。脚本那些对象都是一个个new的吧[惊喜]。。还有你们每帧7.5ms的逻辑太高了。首先，一般逻辑都不需要每帧执行，应当是事件式来处理。除了非常核心，要求时间同步很关键的逻辑外，其他逻辑都不应该放在Update里。。。。

		自动登录	找回密码
密码			立即注册