What to expect from Nau Engine — interview with Andrey Karsakov

Alexander Semenov, App2Top: Hi. Let's start with a little story about you. Please tell me what exactly you are responsible for in 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 am subordinate to a number of leads 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. I 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 Unreal Engine, often modifying 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, 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, 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 experience? 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 with rich experience in the development of both game projects known around the world and the engines on which these projects are made.

Let's move on to the agenda, to Dagor Engine. Why was it taken as the basis of 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 both to assemble for a wide variety of platforms and to conduct cross–platform development - these are very important factors for us. Plus Dagor is in the public domain, under a license that allows it to be used, modified and modified. In principle, these are the main factors. They fully meet all the criteria that we have set for ourselves when choosing technologies for 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 individual frameworks, open source libraries available for use. Analyzing all alternatives is a laborious and time—consuming process. But according to the totality of all factors, we decided to stop at Dagor Engine.

Now there will be a noob question. The render, kernel 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 much as a percentage 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 notorious 38 parrots. Even if you express the ratio in terms of the number of lines of code, it will become obsolete in 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 mostly closes the initial stage of development. As we said earlier, it will be useful at all stages of the life cycle of the game, and in this case the pie chart is too gross a simplification.

Which version of Dagor Engine became the basis for the Nau Engine? The question is important, 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, therefore, perhaps, it seems that this is an old version.

Against the background of recent Western releases, we are increasingly hearing 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 there 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 developer community everything necessary to expand the functionality of the Nau Engine 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 reveal what was 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 labor. But unfortunately, I can't reveal the details now, we would like to "polish" this solution and share the details later, together 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 there is 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 it planned and, if so, how soon, the implementation of visual programming in the Nau Engine? Is it possible in early access or in version 1.0 to create games with zero coding?

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 needed 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 had a low entry threshold was repeatedly mentioned. I want to understand exactly how the development team plans to go to 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 volume of documentation, on the specifics of the implementation of individual modules. The entry threshold is reduced just by convenient tools for developers that simplify working with low-level engine systems.

It's good that you started talking about 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 doing this. We are very actively working with universities that have been teaching game development for more than a year (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 come later.

How will the work on improvements made by third-party teams be built?

Andrey: The work can be built in several ways:

1. 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.
2. 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.
3. 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, along with us, can actively participate in the development of the Nau Engine.
4. 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 such completely, and not only at the plug-in 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 launched it in the editor. And if everything is fine, then I have put together a build that I can give someone to feel. Those who got into alpha testing check conceptual technological solutions and give us feedback on what can be improved or changed.

I see. Well, thanks for the interview. We will be waiting for news from you.