这里是有感于游戏直播大神羽毛后续想做游戏，结合之前也有王老菊做游戏的事情，想从自己这些年创业和从业的一些经历和见闻聊聊，尽力给点建议。这里“主播”代表了一类行业内有梦想也小有经济积累的人，我个人也见过少数一些单机游戏创业的人符合这个叙述，但有相似情景（有一套房的钱但不投资、买房或者润）的其实不多。话题展开计划了2篇，这一篇偏向技术开发，后一篇偏向项目管理。

个人觉得开发方面B站的Games101系列课可能是基于3D项目沟通的基础。全看懂不指望，但是如果看完了一点没法懂，那基本也告别做3D游戏了。记得王老菊的项目初期开直播讲过一个2D游戏的45度角碰撞判定问题，当时给我的感觉是那么简单的问题如果还不能快速弄明白，继续开发的风险是很高的。不过这一篇里不会谈到人员构成的问题，更多还是说说开发用的工具和知识本身。

另外，做3D需要的知识维度是远高于2D的，如果没信心拿捏3D场景开发，用2D画面做一个《Tunic》那种游戏也是很优秀的。而且3D引擎当然也可以开发2D游戏，所以用不用3D商业引擎是一个综合考虑的事。（这里提到的多种观点由于篇幅限制，只能提出一个引子）

引擎选择实际上还要参考合伙的程序员的技术储备。这里假设主流引擎都可以选择，那么我认为中小型项目还是应该选Unity ，尽管现在使用前需要详细了解不同版本的收费策略（新的按下载数分成方案是从较新的几个大版本才开始）。

这个建议主要是基于以下几个考虑：

Cocos或者Godot作为轻量级开发引擎是完全合格可用的，而Unity反而有选择哪个版本才是稳定版本的问题；但是对于要开发中型规模关卡的项目来说，这些2D引擎开发一个完全自定义的关卡编辑器的代价会大很多，因为几乎要从编辑窗口到各种预览功能都要从头搭建。

对于Unreal，我的观点是不追求极致画面质量的就没必要用。这个引擎中小型游戏开发者社区人数相对比较少，如果不上Epic独占其实也没有价格优势。

如果是第一款产品，原型阶段既要验证团队也要验证玩法，其实是挺重要的。这种原型并不类似机核暴造活动的那种规模，因为活动中的项目突出一个点子的展示，有可能做完就丢一边不管了；而实际产品需要预留的框架扩展空间要更多一些，不能说从原型到正式开发代码要全部重构，那就白做了。

这里以类似《空洞骑士》或者《Tunic》这种规模的项目来作为标的，那么能开发这种程度的游戏的程序人才其实是很多的（虽然可能都被大厂收编也不好找，这个另说）。商业引擎里往往提供了模块化的初始包（Package），可以相对容易地从一个类型化的游戏开始搭建——例如第三人称箱庭玩法，在Unity就有3rdPersonController（第三人称控制器）控制器模块，也有完整的范例演示供参考；类似的摄像机跟随模块，也可以用CinemachineVirtualCamera（虚拟摄像机）组件来搭，可以实现一些例如缓动跟随、规避障碍、切镜头、轨道镜头等常见功能，整个Cinemachine模块也适合制作各种Cutscene（转场特写动画）。

在其上，如果要实现战斗模块，就需要一定的功能开发编程了。虽然也能找到对应类型化的第三方素材，但是扩展起来就会相对费劲。只用第三方库也能实现一个类似《Tunic》的战斗系统，但仅仅是那样的动作要素太简单太生硬了。

例如做一个近战判定为主的游戏，如果要实现取消硬直、时停、魔女时间这样要素，后续还想拓展一些丰富的动作要素，至少需要从角色的动画状态机管理、攻击特效管理、碰撞盒运行与检测这几个模块都自己从零开始搭。

如果是做一个第三人称射击游戏（TPS），原型阶段要验证的重点则转到镜头设置、枪械功能开发（如模拟弹道、后座力、开镜、红点、热成像等等），其次则是场景比例尺，敌人AI等等——动作游戏敌人AI可以稍微笨一点，以挨打为主，相对射击游戏敌人AI就更复杂——这里的AI只是有限行为树的常规俗称，不是最新意义上的“那个AI”。不同类型游戏的原型，关注的细节截然不同，但往往都不容易。

渲染开发方面，引擎的素材库能提供一些基础的大众化视觉效果，但如果要追求更风格化渲染（如卡通渲染、CRT显示器风格、剑戟片滤镜等），最好在这个阶段进行验证，因为这会改变一些美术素材的制作规格。如果游戏从铺量开发期再修改渲染风格，可能大量的贴图需要重绘，代价就非常大了。

这里再提一个往往不容易注意的点，就是逻辑帧与渲染帧，前者负责计算判定之类的，后者负责视觉表现；有的游戏类型需要两者是同步的（要卡一起卡），有的游戏类型则是2者独立比较好。单机游戏要求不高的情况下，两者的时间片长度往往也是对齐的，这就会导致低帧率判定帧时间略长的问题，例如FS社游戏常有的“越卡判定越宽”这类情况。

另外，“游戏是否要支持联机”这一点也需要在原型期开发并验证。因为一旦要做一个联机游戏，要在设计、架构、性能上考虑的事情就不止翻倍这么简单了——例如做成联机逻辑帧独立的重要性就会大大提高了。联机原型可以稍晚于单机原型，基本上动作性越强的游戏联机越难做好，要考虑应对延迟的解决方案等等。如果觉得用引擎方提供的联机服务可以接受（延迟、费用之类），至少也要在这个阶段跑通联机的原型。如果听了机核游戏开发节目帕斯亚那一期，就知道中途改联机其实是很难的，像很多出名的小规模游戏如《饥荒》，它的联机版也是后推出的。

假设原型阶段顺利完成，团队要基于一个高完成度的原型开始开发了，这时候就需要开发编辑器了。以小团队关卡型战斗游戏为例，至少需要一个战斗技能编辑器和一个关卡编辑器。引擎中的编辑器往往是基于它提供的一些接口进行扩展开发的，原则上是尽量用方便的方式实现可视化编辑。由于主流的3D引擎是商业化的，而主流的2D引擎是免费的，免费但是功能少导致在2D引擎里做方便预览的编辑器会更加困难。

3D引擎的编辑器往往是基于引擎内的窗体和编辑场景进行扩展开发的，这样的好处是“可视化编辑”、“所见即所得”。当然这是理想状态，有些定制需求可能引擎功能不支持，但最终也能覆盖绝大多数将可视化状态转为配置数据的需求。

对于战斗技能编辑器而言，最基础的应该是一个可以逐帧预览并编辑“角色动画+特效+碰撞盒”的工具。编辑器应该包含一个可以拖动的时间轴，上面可以存储预览关键帧的数据信息、过渡帧的插值及视觉效果。进一步可以做带入受击方的编辑功能，如打怪浮空等，需要在编辑状态下能放木桩怪；如果打击感中要涉及顿帧（俗称的“卡肉”），还要能编辑并预览顿帧的开始结束帧。这些细节如果不能可视化编辑，就必须从填配置数据开始，然后每次都运行游戏调试，那效率会非常低。

对于关卡编辑器而言，由于引擎本身自带基础的场景编辑预览模块，自定义编辑器主要是面向一些触发器或判定数据的快速编辑存储。例如游戏内有爬墙功能，那么需要编辑爬墙判定范围和上墙下墙的判定点；又比如游戏内有沼泽，需要对进入沼泽区域的角色进行速度降低并触发中毒，那么编辑时也要能划分出这个沼泽的判定范围；再比如有些游戏可以进入水体，需要入水时有跳水动作并进入游泳姿态，则进出水体的范围也需要配置判定（《之狼》里有邪道绕开了这个判定，就实现了天上游泳）。这些还只是3D探索游戏里一些基础的功能配置，如果游戏还有定制化的特殊需求，例如需要能全地图针对任务进行寻路导航，还需要烘培（Bake）寻路网格并配置连接点等等。

值得一提的是，当场景复杂度上升后，大量精力会被分配在编辑场景的块划分上——这里的块还可能是一类广义模块的划分，例如流式加载的分块、渲染用的加速结构等。对于大场景的高效渲染（也是游戏媒体提到的“优化”的主要方面）本身也是一个可以无限复杂的课题，即使全依赖中间件也有巨大的学习成本。针对中小团队来说建议就是——控制规模，场景一次加载，尽量别涉及到这一类进阶问题。

尽管面向对象开发不是运行时性能最高的架构方案，但确实是到目前为止最适合把功能需求转化为程序的方案。虽然很基础，但对于非计算机软件专业的制作人和策划来说，仍然是一个需要学习的功课。

简单来说，一个游戏世界的设计应该是基于归纳、抽象之后的很多个类（Class）在实例化后运行的结果。例如一个敌人可能就有这样的继承链条：游戏物体——可受击物体——自带AI物体——人类目标——拿枪敌人，那么具体逻辑也是这样逐层搭起来的，共性做在基类里，特性做在子类里。基于这种思想，游戏设计的功能就更应该是整体性的，类似先设计一个世界，再考虑世界按规则运行的事情。当然没有人能一开始就设计一个完美的游戏，设计上的迭代是不可避免的，所以一开始设计的结构越好，扩展越容易。

例如游戏内每个单位都有自己的生命值，如果后续要引入“共血条”的敌人，其中一个方案就是在敌人类型基础上插入一级“敌人群组”的类型；又比如一开始单位的生命值只有一条，后来要引入多条生命值（这里不只是表现，还有一些阶段转换之类的触发器功能），也需要扩写“敌人”这个类上的生命值定义与功能。

有了这个理解基础后，就能理解为什么在项目开发一段时间后，再引入一个全新的对象（和已有的很多对象有交叉逻辑），就可能会产生开发周期问题，或是从根本上就是很难实现。举个可能不恰当的例子：比如另一个世界的《之狼》，在做完了场景钩绳系统之后，觉得这个不错我们想让它也能钩怪或移动到怪前面，这就是一个破坏性很大的需求；如果是像《匹诺曹的谎言》里一开始就设计了这个功能，充分考虑了游戏内单位可以进行的空中位移情况，则没有问题。

假设人员能力在线，那么游戏开发到了阶段性的整合期就可以开始验证了。这时更要区分哪些细节不应该纠结——毕竟人的精力是有限的。个人认为重玩法的游戏应该先验证玩法，例如不能玩一关有趣玩10关就吐了；重视觉风格的游戏则应该保证其独特视觉风格的可行性，例如不能静态的时候很好看，实际玩起来光污染。前者更偏游戏关卡数值设计，后者更偏美术设计。

如果做的是一款“幸存者Like”游戏，那么完全可以从没有任何美术资源仅有游戏逻辑的状态就进行关卡调试，运行单位的美术资源可以都用临时资源替代（如原型小人、胶囊体等），主要验证关卡节奏可可玩性，并逐步填充战斗设计；相应的美术资源，在定好性能指标后可以在单独的制作管线开发。

如果是想实现类似《女神异闻录5》那种很灵动的动态UI效果，则需要尽早整合一版游戏内的其它美术素材（渲染风格、角色动画等），在3D场景的摄像机转场出也要接入相应的设计，才能实现场景动画过渡到UI动画比较平顺自然。当然这个属于一类高级追求了，小团队面临可能更多是视觉可行性问题，例如想做一个同屏杀100个怪的游戏，为达到这个怪数量进行渲染调整和性能优化（例如之前的怪太写实了模型面数太多，则可以做得低面数一点，或转向更风格化的渲染以减少特效粒子数等）。

总的来说，一款游戏首先是一款软件产品，最低要求是功能保质保量的完成；可能实现出的结果不达预期或者还有提升空间，但很多时候还是应该先把内容都做完再优化打磨。除非团队是像《戴森球计划》那种有经验的团队，否则不要想着做到特别完美再上线——能以类似Early Access模式进行发售也是一个产品自我检测的好机会。

有少数游戏是针对一个细节无限打磨，不考虑在一定时间内完整做完的。这可能是制作人对这个特性执念太深，或是这个特性过于诱人；如果后续的经济来源还能有保证，这或许也是一个方案，但这就太反软件工程思维了，个人是非常不提倡的。著名的众筹游戏《星际公民》就是这样一个例子。

受制于篇幅所限，写得还是太粗放，如果提出的关键点能引发思考和注意，也就足够了。下周如果有空会更下期，谈谈项目管理。