如何评价腾讯在Unreal&Unity下基于TS的puerts（开源）热更方案？

sain102210 · 发表于 2020-11-25 16:19

mofang · 发表于 2020-11-25 16:20

个人觉得给UE4添加lua，javascript等其它脚本的做法是有重大意义的。UE4本身的blueprint压根没法用于一定规模的生产。
只能哄哄游戏开发票友的样子

呶呶 · 发表于 2020-11-25 16:20

作为一枚早些年cocos creator的狂热使用者。ts用起来还是蛮爽的。

sunjunfa001 · 发表于 2020-11-25 16:21

游戏开发的标准向客户端看齐。就手机游戏来说其本身就是一个app，自然免不了要面临和其他手机app一样的问题。 app开发中需要的热更新比游戏还多，在和平台的斗智斗勇中产生了很多动态化方案。
很多移动端已经普及了的技术，在游戏上几乎没有类似应用。阿里很久之前也做过类似的luaview的技术，然后没用多少就淘汰了，lua虚拟机不是长久之计，typescript解决了很多问题，V8引擎在各种地方有很多实践，生态链非常完善，多人合作编程规范都有很多落地，按道理来说早应该用在游戏客户端上了。
根据现行移动客户端方案，我一直在想游戏客户端之后可能会怎么发展，以下纯当我瞎想。
我设想中的游戏客户端结构是这样的。首先unity或ue作为一个容器只是这个移动客户端的一部分。用v8引擎执行js代码完成游戏主逻辑，更高效并保证动态化。现在这些手游好多都重ui轻gameplay的，然后可以将大部分ui界面用h5，或者考虑到性能用rn实现，只在gameplay和hud上使用游戏引擎。两部分底层不一，所有的业务部分均用js实现。再将手机相关的特性和接口用native写好封到这个js层里。游戏也不太需要靠优化代码数量减小包体积。
这样做我自己估计会有这么几个好处。
1.游戏只要不运行gameplay就可以极大降低性能消耗，也不会剧烈发热耗电，通常ui的解决方案是异步的，更新频率和渲染方式都更切合于ui，运行开销很低，相比游戏引擎只要打开哪怕是挂机手机压力都巨大，占用内存大，关掉之后很难保活。
2.游戏启动速度可以做到非常快，先用ui页面过渡一下给玩家点东西可以操作，登陆，领奖励，看看活动，配一配装备天赋队伍等。游戏引擎在后面慢慢加载，等到玩家要开始打关了引擎也加载好了。在初次游戏或者更新时，前端和引擎端可以独立更新，可以用很小的包快速更新前端内容让玩家有充足的内容体验，同时后台下载gameplay需要的资源。
3.全部采用js（实际使用ts）前端中非常多优秀的布局和ui解决方案可以直接利用，避免在ui适配和基础ui组件上重复造轮子。不管是h5页面还是rn页面，动态化能力都很强。框架形成之后，新人上手开发门槛会很低。

死去活来 · 发表于 2020-11-25 16:22

增加JS支持、进而能支持TS是极为重要的。无类型的脚本语言对团队开发来说几乎等于噩梦：代码重构极为困难，导致随着开发演化代码质量越来越低。
几个典型的问题：
1，需求改了，必须要修改一个函数调用的参数数量和类型；
2，配置表改了一个列的名字或类型；
3，网络协议更改了属性名字或类型；
见过有lua程序员为了方便find和replace，把同一个概念换成不同的名字用在不同类里面的情况。
见过一个变量随着函数调用每一层都在tostring或者tonumber

unity下之前的方案有这么几个：
1，ts to lua。没有sourcemap，调试有点恶心
2，emmylua插件。强类型支持有bug
3，ilruntime
4，自研typed lua做静态检查
puerts是一个很有潜力的候选，v8的调试profiler工具很成熟，ts本身也是一个发展非常活跃的语言。很值得尝试。

tutushetou · 发表于 2020-11-25 16:22

我作为一个游戏开发小透明还是要来说一说
首先如果这个框架能良性发展，我是一百二十个赞同
一方面是因为我本身写js很多，可以很快衔接。
二是，vscode对于js/ts支持很好，代码提示很舒服，要知道如果没有代码提示，写lua是十分痛苦的。
三是可以很好利用js/ts特性，例如对json的完美支持，有一说一，unity对于json的支持就是屎。而且，这样我们就可以把很多东西独立于引擎之外，比如我们可以用electron等web技术开发关卡编辑器，然后用json描述数据等，降低了耦合。
总之这个技术如果良性发展是很有意义的。唯一比较滑稽的就是。
unity原本支持js，然后官方扔掉了js。然后腾讯又加回来了。

下面来谈使用体验，目前正在使用该框架复刻unity的官方教程，做好类型绑定之后生成TS代码提示，加上vscode的提示coding体验和c#基本没什么区别，ts编译快的飞起，不用每次切回编辑器就卡一下
性能上，小规模项目上应该算不上什么瓶颈
还有什么体会，使用之后继续补充

yadnus · 发表于 2020-11-25 16:23

从解释执行的性能角度看还是得lua吧，js慢一倍以上。当然，未来的话 wasm64 成熟了有解释器的话可以一统江湖了

雨点 · 发表于 2020-11-25 16:23

个人觉得意义不大，相对lua优势不多，好的地方在于语法方面，这个可以通过插件+代码规范解决一部分。

cmwl999 · 发表于 2020-11-25 16:24

个人觉得给UE4添加lua，javascript等其它脚本的做法是没太大意义的。UE4本身已经有非常好用的blueprint。
另外，过度追求热更会走上邪路。

罗明工作 · 发表于 2020-11-25 16:24

隔壁Godot也支持脚本开发，但它的理念是追求轻快，这是弯道超车的节奏。
用UE4还搞热更的，你们就尽情整吧，别被性能坑死。

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