Ant 引擎的一些改进计划
我独自开发游戏已经有三个月了。这三个月里，我是 Ant Engine 唯一活跃用户，这是一个很好的机会来挖掘对于一个独立游戏开发者来说，引擎哪些地方有缺失。现阶段，我还是希望把精力放在游戏开发上多一些，所以引擎方面恰恰够用就好。虽然，完善引擎这件事做起来会更愉快，因为这些工作对于我比较顺畅，容易想清楚，游刃有余；而一个人开发游戏，更多的时候是手跟不上心而产生的烦闷。
我还是想挑战一下自己，把游戏设计好，实现好。引擎方面的事情，把想到的东西先记录一下。或许完成手头的游戏项目，沉淀更多，再回头做引擎，愉悦感更强一些。
首先，可视化编辑器 对我来说不重要。所以暂时就不维护了。我更需要的是一些快速验证眼下游戏设计中想法的功能，这些就在游戏 demo 中顺带实现就好，看起来没必要放在编辑器里。这和现阶段没有美术参与也有关系。因为对我自己做独立游戏来说，我不在乎开发进度，先做美术还是后做美术，区别不是很大。本来我自己就喜欢传统 roguelike ，几个 ascii 字符就能脑补所有的美术表现。我想，游戏原型阶段就不需要美术在编辑器里做创作了，用一些几何体就够用。这也是为什么我在三个月前最先完善的就是 Ant 引擎中预制几何体 这个功能的原因。
我在使用 Ant 引擎的时候，发现因为缺乏具体 API 文档而只能不断的阅读源代码（毕竟有很多模块不是我自己动手写的，无法全部了然于心）。而且并非每个模块的设计都满意，这让我经常有修改引擎的冲动。做了一段时间后，我找到一个方法来解决这个开发问题。我可以额外再做一个精简版的框架，按目前开发游戏的需求，从最基本的功能做起，逐步完善。这样就能隔绝引擎已经做好的部分：好用的模块直接做一些浅封装，有问题的部分可以多花些精力做不侵入（破坏老代码）的改进。
本来根据游戏类型的不同，使用引擎的方式就会有很大差异。我希望可以有不同的这样的框架针对具体类型游戏做二次封装。这样，在二次封装上写游戏的花，后面就可以更放心的裁剪底层实现。我更希望让 ECS 框架还原成更原始的设计：面向数据，避免添加太多的辅助模块。
最近还有许多工作是在 UI 上。我对 RmlUI 的方案还是比较满意的。毕竟类 web 的开发有极大的用户基础，各种边角被人打磨过。不过目前的一些实现细节，尤其是 UI 层和游戏层的消息通讯部分存在设计问题。
现在 UI 层和游戏渲染（以及逻辑）处于两个隔离的 Lua VM 中，跑在不同线程上，依赖消息通讯交换数据。引擎简单的封装了消息通讯过程，提供了 RPC 方法。但从游戏逻辑倒 UI 阻塞 RPC 调用，直接使用的话必定产生死锁。这是因为游戏逻辑通常放在 ECS 的一个 system stage 中执行，而处理 UI 层的 RPC 请求在另一个 stage 。为了回避这个死锁问题，需要小心的利用 ltask 的一些异步功能。我做了一些简单的封装后，情况好了一点。这个封装抽象出一个 model 对象，自动在两个层之间做数据同步（只同步差异部分）。在游戏逻辑这边设置 model 的状态，就可以直接在 UI 上展示出来。这个封装还很粗糙，需要我自己多做一些 UI 模块后再改进。
由此，我猜想 ECS 里面可能还需要提供一个 async 的 stage 可能好点。现在的 stage 里如果调用了 ltask.call ，就完全塞死当前帧了。加一个 async 的 stage ，让这里 yield 出去的流程，在下一帧回来这个stage 继续做。这样也可以取代 instance 创建的 onready callback 。只需要把一些消息处理过程放在 async stage 就可以更自然的写。前几个月就做过一点类似的尝试 ，感觉还没想好，暂时不打算把这个特性加到引擎中。
动画模块 是目前引擎比较欠缺的部分。只是我在做游戏原型时还用不上。如果未来做动作向的游戏，这方面的需求就更大了。这个的开发优先级比较低，等实际用起来再解决。
材质系统 看起来更值得改进。尤其是我在开发过程中，遇到一个简单的需求：运行时把一个对象改为半透明渲染，折腾了我好几天。最后我还是采用了去年开发游戏过程中使用的方案，为编辑器做好的预制件数据打上 patch ，为每个预制件预生成一个半透明材质的方式。然后在运行时根据需要，在不透明和半透明预制件中做选择（因为现在引擎不支持运行时给对象赋予完全不同的材质）。
说起这个半透明材质问题，我认为本质上还是性能优化问题导致的。理论上，我们可以让所有的对象都是半透明材质，把透明度调为 1.0 ，它就呈现出不透明的状态。调成 0 就消失了。但是，对于渲染来说，不透明和半透明（以及不显示）性能上有本质差别，这会导致不透明的 3d 物体和半透明 3d 物体底层渲染管线都有极大的差别，远非改个材质参数这么简单。或许在 2D 引擎中，这个差别并不大，但对开发者来说，最好不管是 2D 管线还是 3D 管线，都不必在意实现的困难，用起来设置个参数就可以了。这也是引擎要极力解决的问题。在这个（半透明）问题上，我和引擎开发团队的同学讨论了两个晚上，有了一些新的想法。以后有时间我想重构（并简化）相关底层代码。
目前，我不打算在手机平台上开发游戏。这存粹是个人对游戏体验的喜好：我对在触摸屏手机上玩游戏完全失去了兴趣。那么 Ant Engine 的最大努力：直接在开发机上对手机设备上的游戏损失调试，看起来意义就不大了。未来我想把为了实现这个特性而给引擎带来的复杂度做一些简化。尤其是远程调试、VFS 同步、触摸屏支持等。同时，可以增强许多 PC 开发上的体验：尤其是美术资源自动编译这块。我希望可以尽量减少额外的编译环节，让引擎能直接加载更多的通用格式的文件（图片、模型等）。
尤其是材质编译模块，是目前引擎中最为复杂的模块之一。我认为设计也是有问题的（不应该如此复杂）。这一块在上个月开发团队里做了一个晚上的讨论，改进方向下次专门写一篇 blog 介绍。
另外，还有一个大块的计划是重新用 Vulkan 编写 gfx 层，而不再使用 bgfx 这种跨平台方案。这也是后话了。相较用 Vulkan 实现新的 gfx 层，我更希望有机会好好做一套 2D 管线（以及独立的 2D gfx 层）。毕竟 2D 的 gfx 层要简单的多，可以把重心放在如何提供更好的（独立）游戏开发体验上。
想做的事情太多，一件件来吧。
Just for fun
Comments
更多的时候是手跟不上心而产生的烦闷，我也有这样的烦恼，想得太多做得太少
Posted by: 伟 | (26) September 15, 2024 08:48 AM
PS5、Switch、Xbox主机游戏日本就占了二个，中国一家也没有，单机游戏产业生态中国起不来，游戏主机关键是生态
Posted by: 伟 | (25) September 14, 2024 05:54 PM
至少要干过37互娱这类企业，米哈游没出来之前都是国内排名前三的游戏公司
Posted by: 伟 | (24) September 14, 2024 05:25 PM
全球游戏产业规模已经超过2000亿美元了，至少要抢到100亿美元份额
Posted by: 伟 | (23) September 14, 2024 05:14 PM
我们还要打造一个steam taptap wegame一样的游戏平台，做好游戏全产业链
Posted by: 伟 | (22) September 13, 2024 03:43 PM
我们要打造中国版的星际争霸，打造全球战网系统，
Posted by: 伟 | (21) September 13, 2024 12:17 PM
我目前在策划二款游戏，一个类似于星际争霸和红色警戒的军事rts游戏，一个类似于playrix的梦想小镇 和它们不同有庞大的世界观，真正做到米哈游口号一样达到创造10亿人虚拟世界，专注于军事游戏和模拟人生游戏题材做到极致
Posted by: 伟 | (20) September 13, 2024 10:55 AM
技术不重要，像陌陌，雪球，yy 多益网络创始人都出自网易，都不懂技术，反而把事情做成了
Posted by: 伟 | (19) September 12, 2024 10:49 PM
梦幻西游的经济系统为什么能20年经久不衰，中国还有几款能玩20年的游戏，把梦幻经济系统研究透彻
Posted by: 伟 | (18) September 12, 2024 06:05 PM
别管那个ant了，说起来是开源的，指不定哪天弄出什么幺蛾子。
要么重头另写个新引擎，要么在主流引擎基础上弄出个新游戏。
Posted by: sfour | (17) September 12, 2024 05:31 PM
我要和云风兄打造中国的暴雪，任天堂，网易出来的多益网络就玩的风生水起，草根到不能再草根了，反而几个大咖创立的简悦没有很成功
Posted by: 伟 | (16) September 12, 2024 04:34 PM
我要云风兄打造中国的暴雪，任天堂
Posted by: 伟 | (15) September 12, 2024 04:23 PM
@single @伟
我以前也总忍不住想对别人的选择指指点点,,,觉得别人与其这样那样折腾,不如怎样怎样更合适
后来慢慢意识到了一个问题,人各有志!
云风大哥应该是那种把折腾代码造轮子当乐趣的人,这一点问题都没有啊
如果真的那么在意商业结果,中国的任何一家互联网公司他可以随便挑,这个你们不会有异议吧
Posted by: hoddddky | (14) September 12, 2024 09:56 AM
为了乐趣而生的东西一定不会不好玩，提前亿点期待云风大佬的独游发布。
Posted by: jaynlo | (13) September 11, 2024 09:22 AM
@danggui1995
https://mikke89.github.io/RmlUiDoc/pages/gallery.html
这里的动画和变换效果应该比你的例子更复杂点，另外我看不出来tick去实现不支持的效果是什么灾难问题，可能没get到你的point
Posted by: kiwiboy | (12) September 10, 2024 07:48 AM
@kiwiboy 举一个例子，做序列动画（比如先移动到某个点，再缩放，再移动到某个点）这种复杂动画，必须自己封装tick函数做相关逻辑(能改源码还好，不能改源码的只能在JS里面Tick控制，简直是灾难)，因为底层是不支持的（css支持简单的预设序列动画，如果要通过代码实时修改效果是做不到的）。
Posted by: danggui1995 | (11) September 9, 2024 09:31 AM
"RmlUI 可能会使想尝试这个引擎的人望而却步"
------------------------
why, css 是久经验证过的UI方案，熟悉的人相当多
Posted by: kiwiboy | (10) September 8, 2024 08:29 AM
RmlUI 可能会使想尝试这个引擎的人望而却步
Posted by: danggui1995 | (9) September 6, 2024 10:32 AM
我感觉 c/c++/lua 多语言才是这个引擎的基本问题, 太复杂了。云大 要不一起来写 Wind 语言 (https://github.com/julywind168/wind) 然后引擎全部用 Wind 实现？(开玩笑的～)
Posted by: JulyWind | (8) September 5, 2024 04:57 PM
程序员是不是应该懂点商业
Posted by: 伟 | (7) September 5, 2024 03:53 PM
感觉很多人没读到最后一句话
Posted by: judadeshu | (6) September 5, 2024 03:11 PM
我想把kbengine和skynet用bigworld的思维整合起来，加入kubernetes云和用户大数据分析，适配xbox ps5 android apple win linux harmony平台，适应各类游戏mmorpg slg rts arpg moba 卡牌棋牌，加入webrtc音视频和im即时聊天，以及强大安全方案模块，适配虚幻引擎和unity，cocos h5引擎和大量demo，形成一套傻瓜式的云游戏引擎解决方案，研发人员批量生产游戏
Posted by: 伟 | (5) September 5, 2024 09:09 AM
某种意义上，我觉得游戏编辑器也是一种类型的游戏，好的游戏编辑器会让用户使用愉悦，也很需要设计能力,在我设想中，游戏和游戏编辑器的边界变得模糊，
制作游戏的编辑器，作为编辑器的游戏，游戏在编辑器中
Posted by: kavka | (4) September 5, 2024 06:18 AM
花时间做客户端游戏引擎，还不如集中所有精力把skynet引擎做成解决方案，不只是一个框架，做成一个游戏引擎云平台，适配多类游戏mmorpg stl rts oarpg，棋牌，卡牌
Posted by: 伟 | (3) September 4, 2024 02:56 PM
面向2D的话没必要折腾Vulkan了,会花过多时间陷入细节研究,第一部游戏作品不需要高大上的渲染特性.
Posted by: dwing | (2) September 4, 2024 09:48 AM
大佬，还是把精力放在游戏开发上吧，不能太发散了，引擎一直可以做的，没有上限
Posted by: single | (1) September 4, 2024 09:41 AM