What to expect from Nau Engine — interview with Andrey Karsakov
In October, it became known that the new Russian open source Nau Engine will be based on a solution from Gaijin Entertainment — Dagor Engine. App2Top talked with Andrey Karsakov, head of Nau Engine development, about how it happened and what technologies the engine will support.
Alexander Semenov, App2Top: Hi. Let's start with a little story about you. Please tell me exactly what you are responsible for at Nau Engine and what engines and games you have worked on before.
Andrey Karsakov
Andrey Karsakov: In the Nau Engine project, I lead the development, that is, the teams themselves that create the engine. I have a number of leads under my command who are responsible for the design and technical implementation of the product.
I've been in IT development since 2012, and I've been leading teams since 2016. He started with a laboratory at ITMO University. We have been developing scientific research visualization systems on our own engine. Then, when we were already moving towards commercial development, we switched mainly to the Unreal Engine, often refining it to suit our needs, but sometimes we also used Unity.
The laboratory has grown into an independent small IT company with a focus on non-trivial technical and product tasks and continues to engage in b2b development: games, visualization systems, applications for developers, industry, education and the entertainment industry.
So, from publicly "visible" projects, my team has developed a comprehensive (smartphones + TV broadcasting) AR system for large live events, which was used, for example, at the final of the WorldSkills International Championship in 2019 in Kazan. We have also developed a mobile AR application for the show "Fiction" on Channel One.
For more than 11 years of working in the university environment and running an independent IT business, I have accumulated quite extensive managerial and R&D experience in the field of computer science, defended my thesis for the degree of Candidate of technical Sciences, participated in major international research projects, and have more than 30 English-language scientific publications. If we take it together with Russian speakers, there will probably be about 50, most of them related to development tools, computer graphics, visualization, AI, augmented reality and education.
During a recent presentation, it was announced that the Nau Engine team has 25 people. Can you tell us a little about the leaders and their experiences? Not by name, but to understand what the guys were responsible for earlier.
Andrey: At the moment, the team has grown a little, there are already more than 30 of us.
We have gathered a team of experts with extensive experience in large companies: Playrix, Sperasoft, Saber Interactive, Unigine, Nival, Lesta. All the guys have extensive experience in developing both game projects known all over the world and the engines on which these projects are made.
Let's move on to the agenda, to Dagor Engine. Why did they take it as the basis for the Nau Engine? What factors played a decisive role?
Andrey: Dagor Engine was created by highly qualified technical specialists from Gaijin Entertainment and tested on a variety of projects that earn good money. This engine has a very good technically implemented platform base, support for modern graphical APIs, allows you to assemble for a wide variety of platforms, and conduct cross–platform development - these are very important factors for us. Plus Dagor is in the public domain, under a license that allows you to use, modify and refine it. In principle, these are the main factors. They fully meet all the criteria that we have set for ourselves when choosing technologies for the Nau Engine.
It is clear that Dagor is not an ideal tool, like any internal engine of any studio. That is why we do not rely on it completely, but take only those elements that we really need to solve our problems.
What were the alternative solutions? Roughly speaking, between what and what did you choose?
Andrey: It is impossible to answer this question briefly. Our lists included dozens of different technical solutions, ranging from full-fledged large game engines that could potentially become donors of some parts for the Nau Engine, ending with separate frameworks, open source libraries available for use. Analyzing all alternatives is a time—consuming and time-consuming process. But based on the combination of all factors, we decided to focus on Dagor Engine.
Now there will be a noob question. The render, core, and system-level components are transferred from Dagor Engine to Nau Engine. If we take the Nau Engine as a pie chart, then these elements are how many percentages of the future game engine?
Andrey: In my opinion, it is incorrect to count the percentage. It is impossible to quantify what is a complex system of components, each of which performs certain functions. It's like the proverbial 38 parrots. Even if you express the ratio in terms of the number of lines of code, it will become obsolete after half an hour.
Dagor parts and modules, even large and fundamental ones, are just one of many in the Nau Engine technology stack, and they will be changed and added, and the engine itself will be overgrown with new modules.
In addition, in our view, the Nau Engine is something more than a classic engine, which closes the initial stage of development for the most part. As we said earlier, it will be useful at all stages of the game's lifecycle, and in this case the pie chart is too gross a simplification.
Which version of Dagor Engine became the basis for the Nau Engine? This is an important question, because what lies in the repository is mainly the import of the fourth version, which was released in 2015.
Andrey: As far as we know, version 6.5 is currently in the repository – the latest up-to-date version of the engine, and we started from it.
The development of the project does not mean a complete rewrite of all modules in each release, and versioning is not prescribed in all modules and code files, so perhaps it gives the impression that this is an old version.
Against the background of recent Western releases, we increasingly hear terms such as mesh shader, tessellation, ray tracing, DLSS, FSR and so on. Is it worth waiting for these decisions at the stage of public beta tests?
Andrey: Some of them are already available now, for example, FSR. Something will appear gradually as the product and code develop. But so far we do not plan to enter into a technological race with such giants as, for example, Unreal. Our task is to make a good high—quality render that provides all the necessary features for today, as well as to give the development community everything necessary to expand the functionality of the Nau Engine in order to add new features and functions.
In general, if we talk about the technology stack, then which version of DirectX (not support, but compliance with capabilities) can be discussed at the start of public access?
Andrey: DirectX 12, along with Metal and Vulkan.
At a recent presentation, it was announced that any other language can be used as a scripting language. Can you tell me what that meant?
Andrey: Our team has found an interesting solution that will allow you to connect almost any language as a scripting language with relatively little effort. But unfortunately, I can't reveal the details now, we would like to "polish" this solution, and share the details later, along with the open beta.
At the announcement of the engine this spring, it was stated that "it will be possible to write program code in C++ and C# languages." Do I understand correctly that even then it was not about their equivalence for the engine, but about the fact that C# can be taken as a script?
Andrey: Yes, in this context it was about scripting — the ability to assemble game projects and write game logic. The engine itself is based on C++. Accordingly, if you have a great desire, you can dive inside and write on the pure "pluses" right inside, expanding the engine. And scripting will be possible both in C++ and in any other language that will be connected.
Is there a plan and, if so, how soon is it planned to implement visual programming in the Nau Engine? Is it possible to create games with zero coding in early access or in version 1.0?
Andrey: Visual programming is definitely planned, because one of the most important tasks for us is to lower the entry threshold for novice developers. If we talk about a full—fledged end-to-end visual programming system, I would rather focus on version 1.0 (release by the end of 2025) than on an open beta, where we want to assemble basic versions of the systems necessary to create gaming products.
The previous question is related to the fact that, as far as I know, Dagor Engine is considered to be a difficult engine to master. At the same time, both earlier and in the framework of a recent presentation, the importance of creating a Nau Engine in such a way that it has a low entry threshold was repeatedly mentioned. I would like to understand exactly how the development team plans to go about this?
Andrey: We plan to go in this direction due to convenient tools: a single editor, convenient tools inside it, universal scripting, visual programming. At a low level, the complexity of all engines is about the same. For the end user, the complexity depends on the amount of documentation, on the specifics of the implementation of individual modules. The entry threshold is reduced by just convenient tools for developers that simplify working with low-level engine systems.
It's good that you brought up the documentation. The variety of training materials and tools is one of the important conditions for the popularization of the engine. For example, Godot has a wonderful interactive tutorial teaching programming, Unity has a set of educational demos inside the engine. Etc. What will happen at the start for those who want to deal with the Nau Engine?
Andrey: There will be everything you need: technical documentation, user manuals for tools, additional training materials on the engine.
A dedicated team is currently working on this. We are very actively working with universities that have been teaching game development for several years (ITMO, HSE, KFU, FEFU, etc.). We collect all available feedback on what materials and in what form it is better to prepare so that the development of the engine goes faster, more efficiently and better from the point of view of exactly who studying this engine, — a student or a novice developer.
If we talk about indie teams, they are usually interested in broad support for two-dimensional graphics (for example, an appropriate editor that involves working with two-dimensional tiles). What can Nau Engine offer them?
Andrey: The toolkit for working with two—dimensional graphics is one of the important functional parts of our editor, which we take into account, but we will work on it a little later. Details will be provided later.
How will the work on improvements made by third-party teams be structured?
Andrey: The work can be built in several ways:
- The first one is the simplest and most understandable: teams independently place their plugins in open repositories so that the community can download them freely.
- The next level is the placement of third—party modules in the asset store or even the official plugin manager. Moderation and quality control are already assumed here so that users can get guaranteed workable modules.
- A system of review and integration of developments and improvements from the community into the source code will also be built. We are planning this track so that the community can actively participate in the development of the Nau Engine along with us.
- The last point is large, independent modules that developers will want to integrate into the engine itself. In case of confirmation of their quality and demand by the community, we are ready to implement them completely, and not only at the plugin level.
We practice a flexible approach, the format of cooperation will depend on each specific case.
Alpha testing began on November 1. What is there in this alpha? What can the teams participating in the testing do with it?
Andrey: By and large, closed alpha is a technological proof—of-concept that covers the entire development cycle. That is, I installed the engine on my computer, launched it, assembled the scene, wrote scripts, connected it, checked it and ran it in the editor. And if everything is fine, then I have put together a build that can be given to someone to feel. Those who got into alpha testing check conceptual technological solutions and give us feedback on what can be improved or changed.
It's clear. Well, thanks for the interview. We will be waiting for news from you.
