0
0

是时候启动一个为移动设备设计的 3d 引擎项目了

云风 发表于 2017年12月20日 11:28 | Hits: 691
Tag: lua与虚拟机 | 我爱折腾

首先,我们在 2011 年底开创的简悦被阿里巴巴文化娱乐集团全资收购了。原来简悦的全套班底转型为阿里大文娱游戏事业群。

当收购的事情尘埃落定,我发现可以从新的视角来看待未来,重新设计制作一款 3d 引擎这件事可以重新启动了。在简悦一直想做而做不了这件事,是因为没有余力,必须优先考虑产品盈利;而对于阿里来说,投入资源来做这样一件短期没有收益,但长远看来却很有意义的事是很自然的。

世面上已经有了很多优秀的 3d 游戏引擎,比如目前最为流行的 Unity 和口碑优异的 Unreal ,还有许多品质精良的开源引擎,再从头做一个又有什么意义?

我是这么看这个问题的。

Unity 和 Unreal 固然优秀,但是它们在设计之初并没有把移动设备作为核心平台来考虑。发展历史悠久,固然细节上的完善是后来者无法比拟的,但也存在很多历史包袱。尤其是移动平台上需要特别考虑内存紧致、节约能耗,更胜过运行的更快、效果更华丽。

另外,就国情而言,我们需要的移动游戏需要有更弹性的资源管理以及更新方案,这一直是 Unity 的弱项。Unity 作为一个闭源引擎,很难让使用者做出根本改进。

我们已经和 Unity 达成了合作,购买了全部源码。现在公司也成立了专门的团队自己维护 Unity 源码对其他产品团队做技术支持。在这种情况下,重新抄一个 Unity 没有意义:有什么需求,我们完全可以在 Unity 源码的基础上做开发。所以我要的是一个全新的东西。

我对这个新引擎做如下构想,其实我已经开干了:

  1. 尽快基于 MIT 开源协议开发,包括引擎的运行时部分和全部的工具链。闭源方式是维持不下去的,开源带来的好处,在 skynet 这个项目中已经得到了充分的验证。另外,由于我们和 Unity 有合作,且签有保密协议;尽快开源,并保持开源模式开发也可以自证清白:我们不会使用 Unity 的一行源代码。

  2. 专门针对移动设备做优化,渲染部分将基于 Opengl ES 3.0 ,面对 2 年以后的市场。提高硬件要求,可以精简掉很多不必要的设计,这犹如 10 年前的引擎会兼顾固定管线和可编程管线两套设计一样,现在已经没有引擎再考虑固定渲染管线了。把下限放在 Opengl ES 3.0 ,我们可以放心的使用统一的 ETC2 贴图(而不用考虑苹果特有的 pvr 格式)、使用 Instance 渲染多个物件、使用 MRT 技术来做延迟渲染的光照模型,等等。

  3. 和 Unity 等引擎最大的不同在于,我一开始就会把引擎的运行时和编辑器设计成 C/S 结构,即编辑器和项目是跑在不同的位置的。开发期间,要求开发者必须把项目运行在真机上,让移动设备真机变成真正的第二块显示窗口,而不是像 Unity 那样,开发在 PC 上,只在必要的时候打包上传到设备上开发。这样,开发者自然在整个开发过程中都时刻在关注游戏在真实设备上运行的状况、是否发热严重、帧率是否够、会不会内存不足、操作是否合理,等等。任何时候,都可以方便快捷的插拔不同的硬件设备做测试,省去繁杂的打包上传流程。

  4. 强调工具的易用性。模仿 Unity 的组件机制,但不照搬。用 ECS 结构来搭建引擎的基础框架。

在实现上,我做了一些技术选型:

  1. 渲染底层使用 bgfx ,而不自己从零开发。因为这是项特别脏累的活,需要有足够经验和能力的人来维护。而我们这个游戏引擎,并不需要在渲染底层抠出多少性能出来,精力放在这个方面不合适。bgfx 花了很长时间做多平台多 api 的整合,作者也有长年的游戏开发经验,非常值得信任。

  2. 整个框架基于 lua 构建,只在性能要求非常高的部分用 C/C++ 来封装成内聚性强的库,供 Lua 调用。不用 C/C++ 实现任何框架代码。bgfx 有完善的 C99 接口,可以完美的封装给 lua 调用,这部分工作我已经做得差不多了。动画模块,我选择了 ozz-animation 这个库,也是符合高内聚性原则,稍做封装就可以在 lua 中使用的。后面的开发都会维持这一原则。

  3. 编辑器开发基于 iup ,这是一个可以驱动原生 UI 控件的 gui 框架,使用起来对于 Lua 程序员来说非常方便。虽然原生控件有时不那么美观,但我认为一个好用的编辑器,美观不那么重要。

  4. 编辑器和游戏项目基于自定义的简单协议通讯。本质上是在移动设备上运行一个纯引擎的 app ,没有任何资源和业务代码,接管了底层的 IO 操作,映射到开发机上。当这个 app 运行时读取程序脚本时,其实是通过 usb 或 wifi 读取的开发机上的代码;资源加载亦然。只需要做好 cache 同步机制,和资源在本地运行几乎没有区别。输入设备也是把开发机的鼠标键盘通过协议映射到移动设备上的,并不需要在开发的时候去点手机的屏幕。我们还可以为游戏项目实现一些调试功能界面,直接显示放在开发机上,比在手机上做一个调试控制台,使用起来要舒适的多。

在开源之前,我会逐步把已完成的工作在 blog 上介绍,等到引擎的原型可以使用了,就在 github 上开放全部源代码。

当然,我一个人来做所有的事情太慢了。游戏引擎是一个巨大的工程,特别是在使用细节上需要大量的人力去完善。这是为什么这次我一反先做再说的惯例,在开源之前就写这篇 blog 的原因:这篇 blog 其实是一则招聘启事。

阿里大文娱游戏事业群创新实验室招聘全职 3d 引擎开发工程师 1-2 人

工作地点 广州 待遇 面议 (按阿里的标准不会太离谱)

要求 :

  • 认同并喜爱游戏引擎开发工作。(有内在动力把引擎做好)
  • 有 Unity 或 Unreal 等流行游戏引擎的项目经验(要知道引擎的用户需要什么)
  • 有 C/C++ 开发经验 (有能力编写高效代码,有能力阅读其它游戏引擎源代码)
  • 有动态语言的开发经验,认同动态语言开发。喜爱 Lua 更佳。(绝大部分的开发工作是基于 Lua 而不是 C/C++ 开发的,C/C++ 仅用来编写高内聚性的库,不用来搭建框架)
  • 对设计模式有一定的理解。(有能力把控程序的结构,不仅仅是搬砖堆代码)
  • 心态开放,乐于学习,懂得妥协。(不想整天为实现细节吵架)

有兴趣的同学,请投一份简历到我的 email (我的 blog 上可以找到地址)。

今天畅游的同学打电话来说我昨天的正文中调侃了他们的开源引擎似乎 “抄” 了 Unity 。我这里解释一下我想表达的意思,并把这句话从正文中去掉。

注意看上下文,我强调的是,按照 Unity 的设计,重新实现一遍没有什么意义。这个 "抄" 指的是结构设计,就好像 linux 最初抄了 minix , git 抄了 bitkeeper 一样;至于是否照搬了 Unity 的代码,我当然无从知晓。畅游的开源引擎设计结构是否和 Unity 一样,应该经得起用户评价。

原文链接: https://blog.codingnow.com/2017/12/mobile_3d_engine.html

0     0

评价列表(0)