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里。。。。
页: [1] 2
查看完整版本: 一些底层轮子的代替方案