在中国，从业者开发出一款好游戏并不容易。 如果一个需求没有很好地联系起来，就会导致编程不令人满意、艺术困难以及规划方面的巨大麻烦。 有时整个团队会为此召开一整天的会议。
如果良好的开发环境能够显着减少这种情况的发生，游戏开发可能会进展得更加顺利。 去年，葡萄君报道了有趣的CEO Zola的一篇文章。 为了让他的团队能够更顺利地开发，他们自己开发了土星引擎，并添加了许多接地气的功能。
对内，梳理了一套清晰的项目管理流程，理顺了不同工种之间的对接标准，使策划、美术、程序之间的分工更加清晰； 对外，他们开发了许多易于使用的辅助工具来改善操作。 问题处理效率。 这个工作流程也引起了很多从业者的共鸣。
凭借这套引擎和项目管理流程，妙趣去年全线实现收入20亿元。 其中，与蓝港互动合作的《黎明之光》全球总收入已达10亿元人民币，《十万个冷笑话》全球总收入也达到1亿美元（约6.4亿元人民币）。
当时，佐拉希望最大限度地优化协作流程，尽可能减少不同部门之间的部署环节，让规划者能够专注于开发3D植物，承担最多的开发内容。 今年，妙趣开发的土星引擎已迭代至2.0版本。 算上一代的开发时间，佐拉和他的团队在这款引擎上投入了整整10年。
佐拉在采访中告诉葡萄君，新版本的引擎对于他们团队来说意义重大。 除了美术品质、光影渲染、图形计算能力的提升，更重要的是管理流程和底层计算的效率提升。 能力提升等。妙趣今年开始的产品也将采用新发动机生产。 此外，合作多年的Zola与蓝港互动也在土星2.0引擎上达成全面战略合作，将首次联合开发基于新引擎的《伊苏8》手游。
关于发动机本身，首先2.0发动机基本上可以完成80~90%的开发工作，都是按计划完成的。 优秀的编程团队已经开始平台化，通过矩阵管理成为项目之间的公共资源。 干预项目。
其次，项目管理流程进一步功能化。 除了能够横向更清晰地推进项目进度外，还可以实现单个项目分支、打包、测试的纵向管理。 同时，还支持多个工作人员之间的实时协作。 两名工作人员在同一游戏场景中的建模、放置物品等操作可以实时显示在对方的游戏场景中，并且可以通过语音交流进行协作。
第三，秒趣团队还花了三个月的时间开发了新的底层计算框架，以解决服务器、线程和计算核心之间使用效率难以平衡的问题，避免负载不平衡。 健康）状况。 基于这个计算框架，他们实现了全球服务器更高效的处理以及无缝的大地图数据匹配。
最后，第二代引擎将进一步细化之前的数据分析模型，将用户数据分解为更精细的标签，以支持大数据索引和跨时间数据过滤和分析功能。
在佐拉看来，他之所以如此渴望优化工作流程和开发效率，是因为他希望策划者能够将时间集中在游戏设计等更有价值的领域，而不是把时间浪费在工作中的琐事上。 他甚至正在考虑推出该引擎的个人版本，向独立开发者开放，例如 RPG Maker，这有助于轻松快速地实现好想法。
在葡萄先生看来，土星2.0可能是最适合国内特殊开发环境的引擎。 虽然在美术表现上还有提升的空间，正如佐拉坦言，与国外主流引擎相比还是略有差距，但在外围系统和项目管理流程方面，并不适合一个不具备技术能力的团队。技术上是一流的。 据说土星2.0的实用价值要高很多。 具体来说，我们来看看葡萄君最近对佐拉的采访。 以下为采访内容整理。
打造自研发动机的目的是什么？
当我们创立妙趣恒生时，我们的团队已经做了七八年的游戏，非常熟悉引擎日常使用所面临的问题。 如果我们想继续开发出好的产品，就必须解决工程问题，解决沟通成本带来的问题、流程复杂带来的低效率问题。
游戏虽然是创意产品，但至少有30%到40%的内容是可以设计的，就像电影行业一样。 当时我们认为，要支撑上层策划和美术的创造力，没有良好的底层工程工具就不可能实现规模化生产。
所以我们的切入点是提供底层技术支持，打造一个更接地气、更符合我们实际需求的引擎。
在发展过程中，我们会遇到很多棘手的问题。 例如，程序有版本管理系统，但美术没有。 如何管理外包美术资源？ 100人美术团队制作的PSD、3DMAX文件以及导入引擎的文件，大到1G、2G，大到十几G的文件，我们应该如何管理呢？ 此外，集中打包版本的优化以及硬盘资源的回收也存在问题。
所以我们在第一代引擎中开发了art版本管理功能，来解决资源压缩、版本变更、存储等问题。
再比如缺乏有效的管理方法怎么办？ 如何并行处理多个项目？ 国外发动机的独立属性较强，协同性相对较弱，因为国外研发团队大多有自己的内部管理方法，但中国非常需要这种体系。 即使现在很多主流引擎都在集成周边功能，但主要还是依赖于第三方工具的商业合作而不是内置引擎。 所以如果策划和美术能够在我们的引擎中协同推动项目进程的话，效率会更高。
所以我们也对这部分进行了设计，比如测试和包装等等，都已经自动化了。 后端程序不仅可以看到团队和资源的绑定状态，还可以看到统一的版本状态。 SDK接入还支持自动化处理。 别人可能要一周才能打包，但我们可能不到一天就能完成。
另外值得一提的是服务器更新。 过去的手动管理阶段，500台服务器需要5、6人更新4到6个小时，上传、解压、更新过程中手动操作容易出错。 现在我们已经实现了自动化，系统自动分发、停止、更新、启动，只需要一个人半个小时就可以完成这个过程。
以上都是为了腾出团队的创作时间。 只有简化底层流程，才能让人们专注于业务层面。 比如每小时10分钟可以用来实现想法，45分钟可以用来思考想法，而不是整天找bug，最后发现代码里多了一个空格。
所以从我们的角度定义，Saturn是一个提供完整开发流程的工具集，是一个工作引擎。
制造一台发动机花了10年时间。 有多难？
我们花了近8年的时间开发第一代土星发动机，又花了2年的时间开发第二代发动机。 这期间，我们经历了很多困难。
起初，因为我们工作了8年，积累了1.5到160万行代码，大约有60到70%可以重用。 理论上来说，大部分只需要整理并填充到新的引擎框架中即可，但实际上并没有想象中的那么容易。 仅发动机设计文件就花了我们一年的时间。 积累了大量的细节之后，工作量就非常可怕了。
第一个困难在于技术突破。 我们重新设计了底层计算框架。 仅这一部分就花了近三个月的时间。 这期间我们选择了很多计算模型。 我们不仅要考虑底层的计算处理，还要考虑上层开发人员的实际使用情况。 如果底层设计不到位，将难以理解的概念暴露给上层，会给开发人员带来麻烦。
例如，网络游戏中有大量的高频计算，但每个包的计算量并不大，有时只需要十几毫秒。 虽然这种底层操作的分配速度很快，但由于计算量很小，实际上浪费了分配效率。 因此，我们在底层逻辑上做了更加集成、高效的分配方式，以提高整体效率。 类似的数据存储结构和版本系统也做了相应的优化。
第二个难点在于匹配开发者的使用习惯。 第一代引擎专注于简单的界面，而在第二代引擎中我们考虑让开发者更容易使用。 比如美术要用到很多软件，比如PS、贴图制作、建模制作、电影剪辑等，UI、UE的前端设计需要与这些软件相匹配。 因为需要反复测试，所以后端的制作也会很困难。
第一代Saturn引擎的逻辑编辑界面
第三个难点在于产业的向心力。 外部业务环境和内部团队目标必须匹配，事情才能推进。 比如我要求公司今年所有的项目都使用新版本的引擎，包括我们新的沙盒游戏以及与蓝港合作的《伊苏8》手游。
如果没有商业游戏的支持，我们就很难从一线获得最实际的需求和反馈，引擎的开发就会脱离实际意义。 在这方面我非常钦佩Epic Games。 除了引擎之外，他们每年还制作游戏。
所以虽然引擎开发是一个比较技术性、纯粹性的事情，但实际上它不仅影响技术水平，对架构水平、产品水平、团队水平也有很大的影响。 现在我们还有差不多两个月的施工时间，完成一些细节之后就可以真正投入使用了。 我的背景是一名工程师。 对于我们公司来说，经过近十年的发动机研发，我们将会积累更多的技术。 这是一种优势，也可能成为一种核心竞争力。
如何从技术角度优化开发效率？
在我看来，土星2.0引擎改动的细节实在太多，很难一一举例。 除了图形计算、物理引擎、物理光照、动态采集系统、服务器集成框架等基础层面外，最大的创新在四个方面。
首先，从项目管理的角度来看，2.0的整个流程、版本管理、业务分发、协调都会更好。
第二代的工作流程将比第一代更加先进。 在第一代，我们实现了任务分配系统，有分配、完成、提交的完整流程。 在此基础上，在第二代中，可以直接将相应的资源附加到每个任务上，然后在这些完成的节点上，都可以根据需求级别进行版本升级和发布包，以进行自动调试。
这相当于在每个人的节点设立向下的独立分支，实现横向整体流程的提升和纵向独立分支的管理功能。 例如，如果你打算调整某个核心价值，直接提交，可能会影响社交关系、货币系统等其他系统的平衡。 不过，当你有了自己的工作分支后游戏动态，你可以自己测试该值并调整后再提交。
此外，我们还可以导出独立的游戏模板，例如RPG、SLG模板。 用户可以通过替换自己的资源来快速生成游戏。 该功能主要针对未来正在考虑发布的个人版引擎，以便一些游戏爱好者可以快速创建游戏。
在协作方面，我们还有层次的概念。 例如，10到20名开发者分为一层，在同一游戏场景中进行协作。 可以想象，一位艺术家正在处理地面的纹理和地形，而另一位艺术家正在将物体放置在地面上。 无论是这里刷掉地上的植被，还是那里放置一棵树，这些操作都可以完成。 实时显示在对方的操作界面中。 而我们可以通过内部语音和截图工具来传达这些细节的制作思路。
第一代土星引擎场景构建界面
第二，技术上最大的变化是我们的计算框架，影响到全球服务器、服务器协同计算、开放世界大地图实现等功能。
之前的计算框架下，服务器功能仍然是定制化的，服务器之间的功能是绑定的，不够灵活。 未来的很多游戏，比如无缝世界的实现，除了客户端功能和3D图形加载技术外，最大的难点在于服务器的整合。 看似无缝的世界，实际上是由多台服务器协同计算、数据同步来实现的。 如果底层计算不够灵活，就很难实现一些个性化的规划需求。
所以这次我们在自动化计算框架中引入了套件的概念。 只要在设置中将功能类拖入服务器的套件中，服务器就可以随时切换功能。 拖入聊天类，也就是聊天服务器，拖入物理计算类。 ，这是物理计算服务。
对于无缝大世界的处理，让两个玩家站在地图的实际接缝处，是看不出任何差别的。 它依靠引擎底层封装的大套件相应协议和动员机制来防止系统关注对面的玩家。 在哪个服务器或进程中，双方的数据被安排匹配。
这种处理的好处是，无论双方的数据、动作过程、动作结果最终执行到哪里，我们都会执行到对应的服务器位置，然后读取出来。 开发者无需考虑底层操作是如何进行的。 在制作界面中，他们只需要指定需要多少组服务器，然后将想要编辑的内容拖到引擎界面即可。
利用该技术，可以更加合理地利用服务器资源。 以往服务器资源分布不均、服务期间核心负载分配不均的问题，可以基于底层计算框架的变化，实现动态负载分配。
第一代 Saturn 引擎脚本编辑器
第三，从操作层面来看，数据分析系统也发生了显着变化。
在一代人的时间里，我们可以统计游戏中的大量数据，比如玩家的产出、消耗、游戏中的动作，甚至服务器宕机的次数。 研发人员将从这些数据中了解用户需求，找到优化游戏和服务的方法，这可以帮助策划人员更准确地识别玩家在游戏中遇到的问题和游戏中的Bug。
然而，生成所需的数据存储是一个关系性需求。 虽然可以记录每个人产生的记录，但由于数据的关联属性是固定的，所以无法提取这些数据进行类比。
Saturn引擎玩家行为日志生成
因此，在第二代引擎中，我们将不再使用关系型存储，而是利用大数据的概念，采用Hadoop对象存储系统。 这样我们就可以调用不同的关键数据并自动导出数据进行分析。 之后还可以随时进入关系层数据库查询具体的用户行为关联性。 例如，可以挖掘用户在任意步骤的流失节点以及广告量的影响。
第四，我们这次在图形图像方面也做了很大的改进，包括支持纯物理方程、光线追踪算法、动态模糊等。我们现在和主流引擎可能会有一些差距，但不会有代沟。 图形图像的最终表现还是取决于团队的美术素质、制作能力以及对引擎的理解。 对此，我们也在与国外团队合作，拓宽思路。
引擎解放了规划和编程，但接下来会发生什么？
总体来说，我们引擎的新功能可以更大程度地释放规划工作时间，然后用引擎的功能来替代程序员和美工的功能。 在第一代中，策划人员可以完成近40%的游戏开发工作。 在2.0引擎中，策划者甚至可以承担80%到90%的开发工作并控制大部分内容。
因为我们在引擎上层使用了ECS实体组件系统，所以我们可以依靠拖拽图表来实现大部分引擎功能，所以现在我们的团队非常精简沙盒游戏开发引擎，单组规划8到12人，一个程序员8人左右，总体高峰20~30人。 我们将节目和美术划分为通用平台，按照矩阵管理思路转移到不同需求的项目组。
这样，策划就成了我们最核心的人员。 我希望规划腾出时间和空间后，我可以更专注于训练我的思维，花更多的时间思考创意，放下我的设计想法，并将其运用到我们未来的所有产品中。
比如首次与蓝港共同开发的《伊苏8》，就是第一批使用二代引擎制作的游戏。 我们主要为蓝港科技合作开发提供技术支持。 开发团队约有30人。 此次，凭借引擎的全新性能，我们也希望能够制作出更好的品质，尤其是在冲击力、画质、世界观还原等方面。这也是首个与蓝港共同开发的IP游戏，并在全球发行。在项目开始时就考虑到了。 汪峰还亲自做出了拿下《伊苏8》全球独家手游改编权的决定。 这款游戏预计将于2019年Q2上线。此外，我们未来还将推出土星2.0开发的游戏。
除了已经获批的商业化项目外，我们也在努力改变我们制作产品的思维方式。
在立项的时候，首先团队必须对游戏行业充满热情，其次制作人不仅要喜欢这个项目本身，还要拿出一份报告来说服我和核心管理层。 接下来沙盒游戏开发引擎，制作者需要找到同样喜欢这个项目的成员，建立自己的团队，每个人都必须真正愿意为项目做出贡献。 因为未来，只有在玩家中口碑好的游戏，才会成为盈利的游戏。 玩家将不再购买商人制造的产品。
如果这个局能够成立，我们就会拥有一批充满激情的开发者，创造力离我们就不远了。 现在我们团队里有人想做沙盒游戏。 这个团队里80%的人都喜欢玩沙盒游戏，所以他们想做一款属于自己的沙盒游戏。 只有团队积极性高，发展环境才能健康。
总之，在我看来，技术不是为了技术而做的。 技术应该是生产力的驱动力，能够充分发挥这个行业的创造力。
文章来源:http://www.360doc.com/content/20/1212/13/72871545_951083695.shtml
