游戏引擎

发布时间：2023-12-06 08:30

 
——————————————————
2015.7.15 更新
——————————————————
看了很多人的回答，基本上都是旁观者，让我来！

从头到尾跟过一个完整的游戏开发，而又从头到尾完整的设计过一个完整的游戏引擎的人国内一只手都能数的过来，都给我让开、让开，我告诉你游戏开发有多残酷、有多困难、有多屌！

先说结论，游戏开发涵盖几乎所有CS领域的知识，然后需要把所有这些东西（有些可能在单独领域中老死不相往来的算法），整合到一个大而全的稳定系统里面实时运行，这TMD就是一件不可能完成的事情啊！

一、关于游戏开发编程难度的定义

我认为，游戏开发编程就是围绕着游戏开发的一切写代码行为。有人回答说现在很简单啊、有引擎啊、写个逻辑没难度之类的，这都是没有帮助的答案。那引擎算不算游戏开发？如果不算，我能不能认为研发汽车很简单，只需要把汽车生产的流水线买回来，然后自己采购材料装配就算研发汽车？荒谬！没有引擎，算个J【哔】。没引擎研发你好意思说自己在做游戏么？那是策划和美术干的事情，没技术人员个J【哔】事情。

游戏研发的技术含量，绝大部分就在于引擎研发里面，没有引擎研发，等于技术人员没什么鸟事情。所以我认为游戏研发编程，应该用引擎研发的来定义，而不是简单用游戏逻辑敷衍过去。当然，游戏逻辑要开发好也绝对不是一件简单的事情，之前有人讨论过的，如何搭建一套任务系统，非常讲究。这里先不展开。

二、游戏引擎是个什么鬼东西

绝大部分人，特别是小白，只是认为游戏引擎只是画出游戏画面的那么一坨东西，只是一个执行游戏逻辑脚本的程序。嗯，这都是业余看法。

游戏引擎虽说是引擎，实际上是一套生产工具，代表着游戏开发者的生产力。要开发游戏，就需要通过这套工具，去进行游戏的内容创建（Content Creation），并且进行游戏的维护、迭代、再开发（DLC、资料片）。而且游戏引擎还包含对自身开发的工具，比如专门debug引擎的工具，专门profile工具等等。再深入一点，针对网络游戏，服务端有专门的部署工具、管理工具、测试工具、维护工具、GM工具等等。所有这些东西，加起来，一整套工作流水线的总和，才是游戏引擎。Runtime部分，只是一小坨东西。

游戏引擎Runtime部分的东西，都是实时或者准实时演算的、也有实时重演的，这部分对技术的要求是效率高，无论是图形、还是物理、AI等都必须在毫秒级别完成复杂运算，还需要跟游戏本身的表现进行配合，抠得很死。

游戏引擎编辑器部分的东西，大而全，一般稍微完整的编辑器都几乎要克隆大部分Autodesk 3DS Max的基本功能，而且还需要针对引擎本身特性作出一些定制，还需要根据不同游戏类型、游戏资源创建的pipeline进行调整。而这个调整、这个pipeline本身的合理性和流畅度，直接影响美术资源的制作、游戏内容的制作迭代，很多游戏胎死腹中，死就死在这个上面。什么东西是游戏制作预算最大头部分？你们猜？

游戏公司的生产效率，就直接体现在编辑器的制作效率上，以及内容生产者对pipeline的磨合程度。磨合得好，效率高、成品率高、往返扯皮少、预算低、项目可控、产出可控。磨合得不好，就跳票、跳票、跳票、挂。

服务端部分比较敏感，不多说，就一笔带过，用集群的，有可能你全服挂了还不知道哪个结点出问题了怎么死；逻辑不严密的，交易复制金钱一个星期了还没log没警报没言论监控察觉，游戏直接金钱通胀GG。

三、游戏引擎开发的难度

没做过引擎的、做过引擎的、和设计过引擎的人，想法完全不一样，不能同日而语。屁股决定脑袋，你不在那个位置上，不能把问题思考透彻。很少人可以从无到有搭建一个完整的引擎并且让它变成一个游戏可以卖钱，于是很少人能想明白，有些东西为什么这么做。

比如 href="//link.zhihu.com/?target=http%3A//zhi.hu/oKII" class=" wrap external" target="_blank" rel="nofollow noreferrer">游戏开发编程算不算是it行业中难度最大的？ - 匿名用户的回答class="icon-external"> ，这里列举了一堆所谓的问题和采用的算法，指出他们在很多年前就已经进入瓶颈了。真的吗？那么为什么这些年引擎还在进步？游戏画面在提高？游戏体验在加强？游戏引擎的算法在更新？举个栗子，LPV/SVO算不算图形算法的突破？二十年前卡马克时代有LPV么？有全局光么？他动态光都不敢多用两个，何况现在用的brickmap style的light point cloud做无穷多光源的模拟。这些例子太多，实际上还真不算什么难度，有算法出来了，我们集成就是了。

然而游戏引擎真正难的部分在于，架构。

重要的事情要说三遍：架构、架构、架构。

很多算法看上去很美，单独实现很简单，但要真的用起来，一点都不容易。因为你的引擎不一定容得下它。架构并不是很玄乎的东西，他实际上看起来就像一个架子，用来放一些业务和算法。牛逼的架构就是可以放好多好多东西，可以兼容不同类型的业务和算法，并且相安无事。挫的架构就是需要不断的进行整体的更替以适应业务的变化和新算法的需求。

简单的来说，架构源自于对重复性业务的抽象和对未来业务扩展的前瞻。即你的经验和预见。比如你的Entity底层架构是否带树状更新结构，要知道树状更新结构会在大量采用嵌套性挂接结构的时候引发性能问题，即如果你在做MMO，那么要小心咯，策划可能会做一些复杂的圆环套圆环装备、宠物、翅膀、坐骑、双人坐骑、移动平台，这些都是嵌套性的挂接结构，在树状更新的时候需要遍历树的每个节点，可能有性能问题（在移动时代这还可能产生耗电问题）。但如果你在做FPS，那么这个不是什么大问题。（请参考采用Unreal2的天堂，对照Unreal3的ActorComponent改动）。

所以，你的架构，决定了你做什么游戏有利，什么游戏不一定有利。

那问题来了，没引擎之前，怎么来架构？踩坑啊！踩足够多的坑。没做过实际游戏，一定、绝对、100%是没法做引擎设计的。因为引擎架构来自于业务，没有业务的洗礼，不知道什么才是引擎真正需要的。于是在做引擎之前，必须先熟悉游戏开发本身。引擎架构还必须足够宽容和庞大，以容得下各种不同领域的算法；同时架构还必须足够高效，本来已经繁重的游戏计算需要更轻更快的信息交互。

试想一下，你的逻辑结构每帧需要从设备抓取玩家输入，监听网络事件，然后转换成逻辑响应、驱动游戏逻辑运算、驱动AI运算、驱动物理运算、再变成Entity的属性、由Entity发送到渲染层、渲染层把属性翻译成渲染属性、组织成最合适渲染设备调用的数据、发送到渲染设备、设备在进行最复杂和繁重的渲染计算、这个时候引擎很可能在并行的做一些收尾工作、准备下一帧更新、同时调度后台的文件系统读取即将需要的游戏资源、并且游戏逻辑可能利用等待渲染的时候做垃圾回收、或者进行脚本的热更新操作。

上述工作，横跨数个大型模块：