Nau Engine的未来展望 — 与安德烈·卡萨科夫的采访
在十月，透露，新的俄罗斯开放引擎Nau Engine将基于Gaijin Entertainment的解决方案——Dagor Engine。关于这个决定的背景以及引擎将支持哪些技术，App2Top与Nau Engine的开发负责人安德烈·卡萨科夫进行了交流。
亚历山大·谢缅诺夫, App2Top: 嗨。我们先从简单的自我介绍开始吧。请告诉我们你在Nau Engine中负责什么，以及你之前参与过哪些引擎和游戏的开发。
安德烈·卡萨科夫
安德烈·卡萨科夫: 在Nau Engine项目中，我负责开发，也就是领导创建引擎的团队。我的团队中有几位负责人，负责产品的设计和技术实现。
我从2012年开始从事IT开发，2016年开始带领团队。最初是在圣彼得堡ITMO大学的一个实验室工作。我们专注于在自主开发的引擎上，进行科学研究的可视化系统开发。后来，当我们开始转向商业开发时，主要转向Unreal Engine，常常根据我们的需求进行二次开发，有时也会使用Unity。
这个实验室发展成为一家独立的小型IT公司，专注于非传统的技术和产品问题，并继续从事B2B开发，例如游戏、可视化系统、开发者应用、工业、教育和娱乐行业的项目。
举个公开的例子，我的团队开发了一个综合性的（手机 + 电视广播）AR系统，用于大型现场活动，例如2019年在喀山举行的世界技能大赛决赛。此外，我们还开发了一个移动AR应用，用于“第一频道”的“幻想”节目。
在超过11年的大学环境工作和经营独立IT业务的过程中，我积累了相当丰富的管理和研发经验在计算机科学领域，获得了技术科学候选人的学位论文，参与过大型国际研究项目，并拥有超过30篇英文科学出版物。如果加上俄文出版物，可能会有大约50篇，大多数与开发工具、计算机图形学、可视化、人工智能、增强现实和教育相关。
在最近的一个发布会上提到，Nau Engine的团队目前有25人。你能简单介绍一下各个负责人的背景和经验吗？不需要逐一列出，但可以让我们了解他们之前的工作。
安德烈: 现在团队扩大到30人以上。
我们汇聚了一支拥有丰富经验的专家团队，成员来自诸如Playrix、Sperasoft、Saber Interactive、Unigine、Nival、Lesta等大型公司。所有成员在全球著名的游戏项目以及这些项目所使用的引擎的开发方面有着丰富的经验。
接下来讨论Dagor Engine。为什么选择它作为Nau Engine的基础？有哪些关键因素影响了这个决定？
安德烈: Dagor Engine是由Gaijin Entertainment的顶级技术专家开发，并经过了多项盈利良好的项目的验证。该引擎拥有非常好的技术实现平台基础，并支持现代图形API，能够在多种平台上进行开发，这是对我们非常重要的因素。此外，Dagor是公开的，采用允许使用、修改和完善的许可证。总的来说，这就是主要因素，它们符合我们在选择Nau Engine技术时设定的所有标准。
显然，Dagor并不是一个完美的工具，就像任何开发团队内部的引擎一样。因此，我们并不是完全依赖它，而是选择那些对我们解决问题真正有用的元素。
有没有其他替代方案？简单来说，你们在选择时考虑了哪些其他选项？
安德烈: 要简短回答这个问题是不可能的。在我们的名单上有几十种不同的技术方案，从成熟的大型游戏引擎，可能成为Nau Engine某些部分的来源，到单独的框架、库等开源工具。对所有替代方案的分析是一个耗时且复杂的过程。但综合考虑所有因素，我们决定选择Dagor Engine。
现在一个初学者的问题。从Dagor Engine过渡到Nau Engine的部分是渲染、核心和系统级组件。如果把Nau Engine看作一个圆饼图，那么这些元素大约占未来游戏引擎的百分之多少？
安德烈: 我认为量化这个比例是不合适的。仅仅通过数量表达复杂的组件系统是不可能的，每个部分都执行特定的功能。这跟著名的38只鹦鹉一样。即使用代码行数来表达这种比例，也会在短短半小时内过时。
Dagor的部分和模块，哪怕是重要的和基础的，也只是Nau Engine技术栈中的一部分，它们会被修改和扩展，整个引擎也会不断增加新的模块。
此外，在我们看来，Nau Engine不仅仅是一个经典引擎，它在整个游戏生命周期的各个阶段都将发挥作用，因此用饼图来描述过于简单。
具体使用哪个版本的Dagor Engine作为Nau Engine的基础？这个问题很重要，因为在代码库中主要是2015年发布的第四版的导入。
安德烈: 据我们所知，目前代码库中是6.5版本，这是引擎的最新版本，我们正是基于这个版本进行开发。
项目的发展并不意味着在每个版本中完全重写所有模块，版本控制并没有写在所有的模块和代码文件中，因此可能会给人留下这是旧版本的印象。
在最近的西方发布会上，我们频繁听到一些术语，比如网格着色器、细分、光线追踪、DLSS、FSR等。在公开测试阶段，是否能期待这些技术的应用？
安德烈: 其中一些技术现在已经有了，比如FSR。有些技术会随着产品和代码的发展而逐渐出现。但目前我们并不计划与Unreal等巨头竞争。我们的任务是提供高质量的渲染，具备现今所需的所有功能，并为开发者社区提供必要的工具，以扩展Nau Engine的功能，添加新特性和功能。
总体来看，关于技术栈，你们预计在公开访问时将支持哪个版本的DirectX（不是指不支持，而是指在功能上的符合性）？
安德烈: DirectX 12，以及Metal和Vulkan。
在最近的发布会上，有提到可以选择任何其他脚本语言。你能详细说明一下吗？
安德烈: 我们的团队找到了一个有趣的解决方案，可以将几乎任何语言相对轻松地连接为脚本语言。但遗憾的是，目前我们无法分享更多细节，我们希望在公开版本时，能够把这个方案进一步完善并分享更多信息。
在引擎的春季发布会上，曾声明“可以使用C++和C#编写程序代码”。我理解的正确吗？那时并不是说这两种语言对引擎是等效的，而是指C#可以用作脚本语言吗？
安德烈: 是的，在这个上下文中，主要是指脚本化的能力——能够构建游戏项目并编写游戏逻辑。引擎是基于C++的。因此，如果有强烈的意愿，可以深入底层，使用纯C++来进行扩展。同时，脚本不仅可以基于C++，还可以使用任何其他连接上来的语言。
是否计划在Nau Engine中实现可视化编程？如果是的话，预计多久可以在早期访问或1.0版本中实现零编码的游戏开发？
安德烈: 我们确实计划实现可视化编程，因为降低初学者的进入门槛是我们的首要任务。如果要实现完整的可视化编程系统，我更倾向于把目标放在版本1.0（预计发布于2025年底），而不是公开测试期间，我们希望在那个阶段建立必要的系统基础。
之前的问题与此相关， Dagor Engine被认为是一个复杂的引擎。但此前和最近的发布会上都强调了Nau Engine低门槛的重要性。我们想了解开发团队计划怎样实现这一点？
安德烈: 我们计划通过便捷的工具来实现这一目标：统一的编辑器、便捷的内部工具、通用脚本和可视化编程。在低层次上，各种引擎的复杂性大致相当。对最终用户而言，复杂性依赖于文档的丰富程度以及特定模块的实现方式。通过为开发者提供更便捷的工具，能够降低他们对底层系统的操作难度，从而降低入口门槛。
你提到了文档，这是非常重要的。丰富的学习材料和工具是推动引擎流行的重要条件。例如，Godot有很棒的互动教程来教授编程，Unity内部也有一系列的教育示例。那么对于那些想要了解Nau Engine的人来说，初期会有什么支持？
安德烈: 我们会提供所有必要的支持，包括技术文档、工具用户手册，以及额外的学习材料。
这方面目前正在由专门团队负责。我们正在积极与那些已经教授游戏开发多年的高校合作（如ITMO、维诺德学院、喀山联邦大学、远东联邦大学等）。我们收集了所有可用的反馈，以了解最适合准备什么样材料，以便快速高效地帮助学生或初学者掌握引擎。
对于独立团队，他们通常对二维图形的广泛支持（例如一个支持二维图块的相应编辑器）感兴趣。Nau Engine能为他们提供什么？
安德烈: 二维图形的工具是我们编辑器中的一个重要功能部分，我们会考虑这一点，但会在稍后进行详细开发。具体细节会在之后发布。
关于改进方面，外部团队的工作会如何安排？
安德烈: 工作可以通过几种方式进行：
- 第一种，最简单和明确的方式：团队独立地将他们的插件放在开放存储库中，供社区自由下载。
- 第二层次是将外部模块放在资产商店或官方插件管理器中。这一点要求进行审核和质量检验，以确保用户获得经过验证的模块。
- 我们还将建立一个审查和整合社区开发和改进的系统，以便社区可以与我们一起积极参与Nau Engine的发展。
- 最后，独立的重大模块，如果开发者希望将它们集成到引擎中，我们准备在得到社区确认其质量和需求后，将这些模块完全融入，而不仅仅是作为插件。
我们将采取灵活的方法，合作格式将因具体情况而异。
alpha测试于11月1日开始。这次的alpha版本包含了什么？参与测试的团队可以做什么？
安德烈: 总体而言，封闭的alpha测试是一个技术概念验证，涵盖了整个开发周期。也就是说，你只需在自己的计算机上安装引擎，启动它，构建场景，编写脚本，连接，检查并在编辑器中运行。如果一切都顺利，就可以打包构建，给其他人试用。参与alpha测试的人在测试概念技术解决方案，并给予我们反馈，指出哪些可以改进或更改。
明白了。那么感谢你的采访。我们期待你们的消息。
