« Lua 实现 ECS 框架的一些技巧 | 返回首页 | BenQ WiT ScreenBar 试用记录 »

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

首先,我们在 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 一样,应该经得起用户评价。

Comments

期待, 希望能够早点出来用上云大做的新引擎

赞同,支持。做开源,才能做大,哪天跟阿里闹掰了,也不会影响到这个项目和个人的发展。阿里这个级别的公司不掌控自己的技术核心,制定自己的技术标准,用别家的引擎,削足适履,东拼西改,终究也做不到优秀。

3d引擎是3d引擎.但是工具集太多太复杂,想要做一个完成度很高的工具集不是一件容易的事,即使把它的限定为狭义的3D引擎,也不是一件容易事情.
我建议你还是不要开源的好,即使开源了,恐怕也很多人也来找某个特定问题解决办法的,最后你发现主要的工作还是你自己在做,因为大多数开源社区形成的代码质量都不高,而且有很大的随意性,想到一点,就加一点.
还有语言不过是实现逻辑的一个工具而已.

Unity的热更新确实是弱项,但是现在更新不是什么问题,Unity也可以用lua,而且这么多上线游戏都验证了。仅仅因为更新这一项就选lua作为脚本开发语言,注定了这个引擎成不了气候。
lua不适合做大规模的程序开发,不适合做编辑器,选lua还不如选Python。用lua的引擎比比皆是,没有一个成功的。Unity之所以成功,很大程度上是由于选了mono作为脚本语言,C#开发效率高,优雅,运行效率高,基本上是开发游戏Engine的最佳选择。

人傻,钱多,速来

目的何在呢,为了磨练团队?为了实现理想?

@fenng

我认识的那个大辉重来都是用 Fenng 这个 id 的,注意下次再冒名请注意大小写。

做你擅长的事,3D引擎还是交给别人去做吧!看你的风魂,还有ejoy的那些玩具,那叫什么玩意!离真正的商业引擎差的太多了

楼上一味鼓吹 TypeScript 的怕是没写过 JavaScript。。。

簡悅怎末被收購了呢﹦別看現在游戲很火﹣將來會死得很惨﹣娱樂游戲是死路﹣具有新理念論壇功能的社交網站才是發展方向◻

确实是时候了,不过Unity这几年的发展,让3D引擎程序员已经断层了,基本能找到的人都是老弱病残+新生代小鲜肉了。

真心不看好重做一个3d引擎。就跟重写操作系统内核一样,可能加入一些新的feature, 如果没有太多实质性的改变,最终意义不大。另外引擎和操作系统内核这样的项目需要千锤百炼。这个项目如果不能维持五年以上并且被广泛使用的话,很难成功。

云风准备做3d引擎了?有啥合作机会不,要不干脆把我们收了吧:)

Unity 的游戏不错~一些好用的应用类拿来用也没什么吧~很多好用的类库优化一下很好用~

小小期待一下,虽然现在入了UE的坑~

WebAssembly 呢

Cloud Wu, I am Chaoyang Zhang from ChangYou and I will have a talk with you soon.

Enjoy2D, Happy3D..
真不错的
感谢云风为游戏开发社区做出的卓越贡献。
持续关注~

云风好像一生都只用lua,从不考虑其他语言.

@轩
首先搞个引擎重点不是什么脚本,而是它实实在在的特性,比如你买个电视机,画面一般般,但是操作电视再怎么方便也是白搭。就我看来,云风除了有点写逻辑程序的经验和喜欢用用脚本,会一点设计模式,图形方面基本上是不太懂的。lua能做什么优化?你渲染的效率能靠lua?我们都知道,效率首先是来自算法上的,结构上的。

看看这些人说的话,真是无语了
什么JS更好啦,什么C#更好啦,什么真机运行不好啦……
说这些的一看就是没什么项目经验的,基本什么坑都没踩过,也没思考过。吃谁第一口奶的就叫谁娘,只是因为只会用这些东西才说这些话。
首先lua的性能足够好了,lua的语法写起来也比较轻松,没太多变数,也足够强大和灵活。其次就与底层结合来说,lua完爆其他语言选择。
真机运行这个要举双手赞成,知道打包流程有多烦吗?一直开发,直到最后一天才上真机运行?可能很多反对的人不负责“打包”是吧?
支持云风,不要被这些可笑的人影响到了。现在确定的路线图是真的可行,希望能够做成一个长久的项目。

让一个不懂3D技术的程序员主持一个3D引擎开发这个本身就是一个笑话。

lua怎么可能会比C#更适合作为框架语言

只有lua作为脚本语言感觉不是很好啊。
很希望能提供有类型的语言支持。
比如TypeScript。

或者在lua的基础上增加类型支持,就相当于TypeScript之于JS。

没有类型,维护起来的确是麻烦。
希望能考虑考虑

畅游其实还有个引擎的笑话:黑火引擎

用lua真的会害死人的,建议Typescript

看起来很棒的项目,支持你

没所谓苛求,这是正常且合理的行为。做一样东西的时候,看看类似的项目是怎么做的太正常不过了。github 上大量的游戏引擎项目标榜自己要再做一个 Unity ,不缺这么一个。

光明正大的事而已。除非心虚,做了什么不应该做的。

当年搞播放器的时候,一有问题就去翻FFMPEG的代码,对畅游也不必苛求。

听起来不错,期待开源的那天

云大,当年的Ejoy2D等等,以及现在的新项目,又要重来了吗。不知为何,每次看到你做引擎的技术贴,都感觉很心痛。。。

Cool, Just do it!

Unity引擎的游戏代码分成三级, 最底层C++(和少量C#)一般来说是固定不变的, 只有引擎本身的功能, 现在看起来API设计的足够简洁正交,功能也够多. 相对于cocos2d-x由于API设计问题很多而且开源, 每个用户都做了很多修改, 导致很难合并官方修正, 这个问题在新引擎上一定要避免.
中间层用户写比较稳定的C#程序, 性能和内存占用接近C++, 而且足够安全, 主要实现游戏基础框架,不太变化,性能要求高的部分.
最高层一般是脚本语言, 写一些灵活多变, 性能要求不高的具体逻辑.

建议考虑这三个层次需求如何在C/C++和Lua之间分配.

确实编辑器是难点, 相比之下引擎运行时不算什么了.

另外用Lua作为主力语言,写大规模程序(尤其是编辑器)感觉会比较吃力, 综合开发效率未必高. 在移动端运行也会违背"特别考虑内存紧致、节约能耗".

看来首先得着手设计一个好而详细的Lua开发框架和守则, 否则多人开发到后期一定是噩梦.

从总体上感觉, 跟Unity还是很难竞争, 不过可以给开发者另一个选择, 适用于一些特殊需求的情况.

哈哈。这里好多畅游的同事啊。

现代的游戏引擎主要拼得是编辑器,希望理想中的编辑器可以做到,
1. 极可能地降低开发技术门槛,专注游戏制作
不只提供美术编辑功能,也提供游戏逻辑的可视化编辑,
像unity的一些插件(play, uscript),像UR blueprint,甚至更好,降低开发的门槛,让美术,策划能更深度地参与游戏制作。
我实现过类似的图形化逻辑编辑,我发觉优化的图形化编辑有能力更有效率地实现大部分游戏逻辑。
游戏沙盒:
像是war3编辑器,以有限的规则,编辑丰富的游戏形式,这属于应用层,但这是理想中的制作游戏的方式。
我们说war3或GTA技术领先,是因渲染和性能吗,让人叹服的恐怕是制作游戏的方式。

有混图形圈的热衷于用lua写引擎????这种人我怎么没见过。

作为12-13年参与此事的畅游员工 我只想说抄袭unity是实锤 楼下可以不用歪楼了 祝云风开工大吉

本来还觉得畅游好厉害,毕竟不是每个公司都有勇气和精力。直到看到有人来公关。

作者您好,请将举例畅游的那句话去掉,并不属实,不要因此造成我方公司对您的追究责任,我是畅游的员工

编辑窗口一定是在 PC 上的,上面说的是开发期间的游戏运行。

另, iup 有自带语法高亮的编辑控件。

如果编辑器和引擎做成C-S结构,要求在移动设备上开发,可能会有一些麻烦的地方,比如美术可能需要"所见即所得"地编辑场景,这些操纵在移动设备上进行的时候很不方便;再比如编辑时显示的内容总量可能会远远超过真实运行时的要显示的内容,这时候移动设备的性能可能不够(比如编辑时的视距可能是10000米,而实际游戏中的视距是400米)。

编辑器可能是个困难的事,
简单工具制作和复杂的IDE的开发是不一样的,IUP未必足以制作出和unity/UR竞争的编辑器,
打个比方,编辑器内支持脚本代码编辑(高亮和自动完成),
在生态丰富的web技术看来,这就是小菜一碟,
还需考虑在复杂编辑器需求下的实现和维护,如MVVM, react之类的方案,
lua上也许没有成熟方案,谁考虑过用lua去做复杂UI呢

祝,好运~

作为引擎的主体,我觉得使用lua超出了它设计目标和当前实现强度,
1 性能,lua早已不是性能最好脚本语言,比之v8,有数量级的差距;
2 没有原生的面向对象,使用过interface/trait会知道这对于重用性和框架设计的意义,比较scala对于面向对象的正确实现;
3 作为编辑器的支持,没有结构化的类型系统,因此难以做到类型元数据反射;如果强行模拟,又增加运行时的负担(且不谈有些不能实现,比如函数对象的反射),相比较c#对于编辑器的友好;

云大,这是你第几次搞3d引擎了?
如果没记错的话,算上这次至少第三次了吧,之前的deepcold呢? 你没次推到重来,真的是在玩啊。

你知道为啥跟随你的技术人员都跑了吗?说句实话,你擅长干自己一个人能完成的小项目,凡是涉及多人协作一起干的技术项目,我都不看好,你对技术的追求太纯粹了,纯粹到根本给不了追随你的哥们需要的发展。

底层是bgfx,这个是渲染层的中间件。

意味着无论是Vulkan,还是ES 3.0,或者是Metal, 都可以不支付太高的成本,切换render backend。

感觉lua或许又要掀起一些波澜了,持续关注~

很不错的理念,持续关注。。同问为什么不用Vulkan

非常关注这个项目。对一起研发也很感兴趣。
不过有几个问题请教
1,为什么使用lua,而不是js,是因为作者喜好吗?
2,lua的ide调试自然是不如js的,请问这方面是否有特别加强?

是市面上

不论如何,在U3D和UE这么火热的情形下还开发新的引擎,不论看不看好,顶一个。

LUA调试不是不方便么,虽然iOS上U3D的原生代码热更不友好,但是不是还有其他方面原因么(苹果不赞成);不能发布到PC端吗?就像最近网易的吃鸡,做一个版本就支持3端,PC端玩起来还更合适;把手机屏幕作为第二块显示屏,那还是支持PC的显示屏的吧,不然那些没iOS设备的开发者一开始就得买设备而不是做成功后再买了(即便最终没做出来也浪费了已购设备)

理念非常喜欢,期待:)

只能在设备上跑可能不是太好,因为并不是只有手机,比如我现在做的汽车配件,也会用到gpu做算法。前期涉及到3d的代码是可以在pc上先做的,因为硬件的板子可能是后做出来,并且也不一定有网络usb什么的,更新程序并不是太方便就是了。

不知道云风大大关注过 Godot engine没, 感觉很有前途的一个跨平台开源游戏引擎

怪不得最近一直在讲ECS的事,原来是要用在新的引擎内啊,哈哈。

预祝开工大吉!
客户端做的不多,也没用过,但会追随这个项目,感谢云风为游戏开发社区做出的卓越贡献。

新的旧的又能怎么样?除非你能带来革命性的变革.我不是指框架,而是指性能,效果.这些能给用户带来实实在在的体验感受的东西.把自己熟练的技术反复折腾是否说明你其实很无能?

真不错的工作,可惜太远了.

作为风哥多年老粉 skynet用户。愿追随这个开源3d项目

确定目标是2年以后的市场,为何不考虑直接Vulkan做渲染。作为取代OpenGL的新一代图形API,CPU端性能完胜,接口设计也更加现代化,彻底摆脱OpenGL的历史遗留问题。

Post a comment

非这个主题相关的留言请到:留言本