WhiteEngine-专注图形渲染与游戏引擎技术的网站

新浪微薄腾讯微薄

最新碎语:暂无碎语

您的位置:WhiteEngine-专注图形渲染与游戏引擎技术的网站 >自研引擎> 渲染引擎设计的初衷和假想

渲染引擎设计的初衷和假想

设计游戏引擎的初衷和假想


      我是一名游戏开发者,接触游戏开发领域已有3年多,以前我非常喜欢玩游戏,但自从接触到游戏开发以后,或许这种热爱转变成了对游戏开发的热爱。我现在在一家做MMO的手游开发公司工作,在业余的时间里,我喜欢去研究一些自己喜欢的东西,我并不能算一个行业内精湛的开发人员,更算不上有多少工作经历的老司机,选择这样走完全是自己对这些东西感兴趣,就恰如我对游戏,对游戏开发,以及我对我现在喜欢的事物。从我使用c#去写了一个c++和c#代码生成的配置表工具以及在不断迭代的过程中,我越来越喜欢底层的一些东西。虽然这个工具看似是多么的简单,但我在这个过程中发现其实我使用的方式和程序的编译却非常的类似。然后我就买了些编译原理的书籍来看,再接触到国内一个匿名开发者写的一个C语言编译器UCC,再到一个非常完整的C语言编译工具TCC,整个过程看下来的确是非常复杂,从高级语言转到中间语言再到汇编和ARM及X86各种机器码的编译和链接,初略的理了下流程我整个脑子都快被烧坏了,其原因就是基础不够。之前我接触过shader以及shader相关的GLSL等东西,再到OpenGL以及OpenGL SE子集在ARM处理器上的API,把整套东西串联起来,我想,如果我有足够的时间,我可以写出一个基于C的游戏开发引擎。但这句话说出来是那么的简单,而做起来却是一件非常非常非常困难的事情。当然,重要的事情需要说三遍~。但我觉得我对这块东西蛮感兴趣的,所以我决定花些时间去尝试一次,下面就说说我的思路吧。

        游戏开发并不是我想象的那么简单,更何况游戏引擎这个庞大而复杂的东西。这里会涉及到好几个核心的东西。

        第一个就是编译器,只有自带编译器的“游戏引擎”才能称得上游戏引擎。我们得为游戏写一个最基础的编译器,我暂且认为写一个C编译器是最合适的选择。

        第二个就是渲染的集成,当然,由于编译器的集成过于复杂,我肯定不会选择从第一步开始,而我的切入点则是OpenGL。因为游戏引擎中图形渲染是最核心的一个东西了。我不想考虑平台相关的问题而去考虑DX,OpenGL为我们提供了足够的支持来完成我设想,并且我也不想没有编译器的时候去考虑如何集成渲染引擎的问题。所以我想先做一个渲染引擎,之后我再做细分的讨论。好了,就当我们有了这两个东西,哇塞,我似乎完成了20%的工作。好了,我们已经用C调用OpenGL接口绘制一个正方体了。

        接下来是第三步,我们的管理好我们的资源,把引擎工程文件和实际开发项目文件分离开来以免产生混淆,因为项目文件是需要公开的而且应该被引擎使用者所支配的。我们得设计好一个比较好的资源管理方案来解决这个问题。

        如果让我想第四步,那就是我们需要为我们的游戏引擎支持脚本语言,并为此写生命周期相应的接口,以及引擎相关的接口,这些东西都是为以后做准备的。就像Unity的开发方式一样。当然不是说想支持脚本语言就能支持的,还得为这个脚本语言提供编译器,这又是一件非常费时的事情呀,我们不得不考虑跨平台开发的事情,如果说考虑C#的话,那我该支持C#1.0?2.0?3.0好了,这些都是后话,能支持C#1.0对于我来说都是一件非常有成就感的事情,或者说偷点懒,支持CC#即简化版C#。

        第五步,当提供了脚本语言那就必须支持脚本语言的编译,我们该选择什么样的方式去编译我们的脚本代码呢?当然,动态编译是再好不过的事情。我们不可能让游戏开发者扑啦啦的写了一年的代码做了一个游戏而不运行一下。Unity现在的处理方式是IL2CPP,IL2CPP的原理就是把C#代码转换成C++代码,然后再调用统一的编译接口对各平台进行编译。Unity放弃Mono VM固然是一个明智之举,当然啦,公司做大了肯定有那个财力去自己写一个VM,所以就Unity就出现了IL2CPP VM,好处就是自己有控制权,对代码也可以进一步优化,从而提高游戏性能。

        第六步,当考虑了脚本语言和脚本语言本身的编译问题后后就不得不考虑对编辑器的选择了,如果你让我去开发一个编译器,好,请给我一个团队。自己开发肯定是费时费力的,而且成果99%可能都不尽人意。你看VS做得那么好,公认的开发利器。我们何不使用它呢?或者为了跨平台选择一个Mono?那我们是不是成为了Unity的模仿者。当然先不考虑模不模仿的问题,实现我们的想法最重要。如果只考虑Windows平台那自然VS是首选,但如果考虑到跨平台那么Sublime是很不错的,但不支持断点调试,我在还没有更深入去研究有多少可选的方案的时候我们暂且选择Monodevelop。相关的如何让我们的脚本和Mono相关联那就是后话了,我想应该不会比写编译器难。

        第七步,如果我们深入去讨论编译相关的问题的话,那么第七步就是跨平台编译了,我们需要解决编译器自身的编译问题,以及目标平台的编译问题。这里就会涉及到我们所做的游戏需要支持什么平台的问题。Win?MacOs?Android?IOS?当然我会优先考虑Win因为Win解决起来最快,并且在我前几个步骤中我们已经对编辑器的编译做了处理以及提供了脚本语言的编译,那么运行在Win平台是一件不算很难的事情了。如果是MacOs那或许更难一些,因为汇编层的处理差异还是很大的。但对于X86这两个平台来说我们可以比较友好的解决了它,那Android和IOS就不是那么容易的事情了,因为他们都是ARM架构的,这就涉及到指令集的不同,我们的翻阅大量了Eclipse工程的安卓编译源码和大量与java相关的东西,以及OpenGL SE相关的接口,我们在手机上已经不能使用OpenGL了,只能使用OpenGL SE,当然高级语言转高级语言似乎比转汇编更容易些,那我们就可以先把我们的工程以及相应的接口在C层里面进行C转Java的过程,然后让Eclipe去完成安卓编译的事情,如果能集成安卓编译器那再好不过了,同理,IOS由于比较封闭,所以我们只能把C转化成Objective-C或者Swift来完成类似的工作。这样我们就实现了跨平台。

        第八步,走到这里我们的游戏引擎可以说是完成了90%,也可以说之完成了30%。当然这只是一个预估,其实做了这些还远远不足以完整开发一个游戏,90%是因为我们已经为开发者提供了编译的相关东西,你可以绘制一个图形然后发布版本到我们提供的目标平台上,如Win,MacOs,Android,IOS。当然你也仅仅只能做一些非常简单的事情,如果我们只提供脚本语言给你使用的话。那30%是因为我们还没有提供完整的渲染相关的解决方案,以及各种UI和功能的集成,你看着看不到引擎的UI,也只能调用几个渲染接口,没有模型资源,文本资源,字体,图片,音效,视频,骨骼动画,以及他们对于的各种各样的格式的支持。没有物理碰撞,可以考虑Nvidia的物理系统,没有粒子系统,没有shader处理自定义图形渲染,没有地形,没有UI系统。所以我们需要做的事情还有太多太多。所以走到这里,我们得处理一下引擎自身的UI,总得给开发者一个图形界面吧。

        第九步,资源导入,资源导入就会涉及到我们如何处理3DMax,maya等各种软件到处的资源,每种格式都是不同的,对于模型资源,我们或许一开始只提供一种资源的导入,那就是FBX,而字体,文本,图片,音效,视频等等这些也可以提供一个最基本的使用格式来完成游戏引擎的初步制作。让你能使用外界的资源来实现你游戏的伟大创造。

        如果说物体碰撞,粒子系统以及shader相关的东西,地形等等都要处理的话,那我们就得回归到话题的本源。设计与制作游戏开发引擎最开始需要做什么,那就是图形渲染引擎。OGRE就是一个非常非常成功的图形渲染引擎,其实我们完全可以使用OGRE来作为我们的渲染引擎,但我觉得它太过庞大,以至于我无从下手去掌控它。所以我还是更希望去自己实现一些初步的想法,哪怕是最简单的方式。这里得为图形渲染引擎提供shader的支持,用来实现各种渲染表现的支持。

        所以我一开始并不能直接去按步骤去实现这些想法,它们每一个功能的实现都需要话费很长的时间来能完成。我现在想从图形渲染作为切入点,无论在Win上开发还是在MacOs上开发都大同小异。先把环境搭建好,然后先去实现基本图形的渲染和shader的支持以及处理各种关照模型。然后加入对资源的读取,比如图片,字体,FBX模型,能导入一些外部资源以后我们需要绘制我们的3D空间,以及确立坐标系。然后我们就可以在渲染引擎里面处理阴影等渲染相关的东西,我们可以先提供最简单的漫反射光照模型,后面再逐步扩充。我们还要处理物理碰撞,以及地形相关的东西。再者我们可以提供一套简单的UI系统。直接用C调用,后续可以提供给脚本语言调用。这样,我们最基本的图形渲染引擎就完成了。

        或许有很多很多东西都介绍得不全,只是我目前的一些实现游戏引擎的想法,随着我们不断的成长,可能会觉得当初写这些东西时的想法是多么的幼稚和简单,但或许成长就是一点点的积累,完善和自我更正的一个过去。人闲着的时候去做一些自己感兴趣的事情是一个不错的选择,这是我的一份爱好,一份和工作有那么点关系的爱好,在业余的时间里,希望我能实现。

        2016.9.1

---

转载请注明本文标题和链接:《渲染引擎设计的初衷和假想

发表评论

路人甲 表情
看不清楚?点图切换 Ctrl+Enter快速提交