Nau Engine is a 3D-game engine for creating games and applications that is currently in active development since the beginning of 2023. One of its goals is to give any developer the opportunity to implement their dream projects, so Nau Engine is an Open Source solution and will be distributed free of charge under the BSD-3-clause license. The beta version of Nau Engine is scheduled for release at the end of November 2024.

Every game engine is a complex mechanism consisting of many interconnected systems. In Nau Engine, we have paid special attention to creating the foundation that will become the basis for the development of the engine.

In this article, we will consider the key components of the Nau Engine core. The choice of technologies and architecture of the core directly affects the capabilities that projects developed using our engine will possess. Let's talk about them.

The key moment in the architecture of a project is the used data structure, approach to storing and interacting with entities. One of the most debated topics in this area is the "GameObject vs ECS" debate, each side having its own strengths and weaknesses.

In the upcoming beta version, the main focus will be on GO-projects, which are more common and less demanding for developers as users of the engine.

Ideologically, Nau Engine is built on the principles of modularity and replaceability of separate subsystems. Therefore, when implementing applied solutions (physics, networks, user interfaces), we have previously laid down the possibility of their use in an ECS architecture.

Additionally, the engine has an adapted ECS-library from Dagor's engine - a efficient and productive solution tested on projects such as WarThunder, Enlisted, and others, but its use at this stage will require significant immersion in the engine code.

The choice of programming language is a significant consideration when selecting an engine and working with it. The preconditions for this choice often go beyond technical issues, affecting not only the final platform compilation, but also existing competencies within the team.

When designing the engine, we focused on the need to create products and share tools and results with the maximum possible circle of specialists - without binding to specific programming languages used by a particular team. Therefore, one of the most important modules is a flexible language-agnostic scripting system - an instrument for efficient connection of user logic written in a convenient script language to the C++ runtime of the engine itself.

In the beta version of 2024, main user code writing is planned using languages C++ (for all engine systems) and Lua (for basic functions and systems). By connecting scripts as components to game objects on the scene, the developer will manage project game logic.

The general system of language-agnostic scripting can work both as an external library for the engine itself and as a separate completed product ready for use in the IT sphere, including beyond video game development.

"Content Pipeline" - a set of tools for content production, configuration, and integration in project-based industries - varies from company to company in the gaming industry. Models, sounds, animations, textures, and other elements are created using a variety of popular professional editors and then added to the project using either built-in engine tools or custom scripts.

The presence of a uniform input format for the engine simplifies content processing rules, reduces the number of operational errors, and minimizes overhead costs. We chose OpenUSD as this unified format - an open framework originally developed by Pixar and now supported by major DCC packages (digital content creation tools).

In Nau Engine, USD serves as a universal container for using various types of assets: from 3D models and textures to sound effects. Its flexibility and universality are ideal for importing, configuring, and managing data in the editor. For runtime operation (during application execution), internal binary data formats are used, which provide the necessary processing speed.

In the beta version of the engine, we plan to support typical asset formats of the following types: scene/level, geometry (static and skeletal), textures, animations, physical objects, GUI, sound, particles (VFX).

The rendering system is one of the most notable modules of the engine, and it determines the image that the player sees in the final game. Its flexibility depends on the number of tools available to graphics programmers and technical artists, while its performance affects the platform requirements and ultimately the video card model. Currently, we support DX12 for Windows OS as one of the graphic APIs.

One of the engines used as a foundation is the Dagor engine repository - a low-level rendering system that includes a set of high-performance libraries for interacting with the graphics API, hardware, triangle calculations, textures, and shaders on the video card. This code has been used to create successful multi-platform products using modern physical correct rendering and cascade shadow mapping technologies.

On top of this low-level system, we have implemented a high-level rendering system in Nau Engine that manages scene objects, stores them in memory, and integrates with the asset pipeline. Writing shaders now takes place in standard HLSL.

In addition to the basic render graph from the Gaijin repository, Nau Engine uses daFX - an instrument for creating and managing visual effects such as fire, explosions and particles. Setting up effects in Nau Engine is done through a single editor, along with scene objects, scripts and animations.

Physics is a fundamental module of any game engine - a tool for developers that covers a wide range of tasks from simple calculations of forces and collisions to complex simulations such as waves around ships and hair on characters.

Writing your own physics engine is a popular challenge both in academic circles and among game developers. Many programmers in our team have also approached this problem in the course of previous projects. Given the tight deadlines for development, we didn't aim to reinvent the wheel and used existing open-source projects instead.

The Jolt physics engine is currently used in Nau. In the beta version, it will support rigid bodies, physical materials, mesh and primitive collision detectors, raycasting, and collision channel settings.

No game project can do without audio accompaniment, whether it's background music in menus or sound effects of a character's footsteps while moving. To solve these problems, developers use both internal engine capabilities and external software - professional audio editing tools.

The Nau Engine primarily focuses on basic needs for working with audio tracks, importing them into the project, setting up their playback parameters inside the project, and calling them from a running application. As a foundation of our code, we use miniaudio - an open-source audio library. The developer can manipulate containers with audio files, adjusting various playback parameters.

Tools for interacting with the network allow developers to share game experiences with others - a set of services and protocols that enable sending commands from clients to servers and back, synchronizing the state of multiple players' worlds, and ultimately ensuring smooth movement of pixels on screens located at opposite ends of the country.

To achieve this, we developed a replication module for game logic that allows developers to create simple multiplayer projects.

At the low level, our solution is based on open-source libraries GameNetworkingSockets and ASIO - for supporting P2P connections via UDP and direct connections via TCP respectively.

An essential part of any video game is interaction with the player - a combination of interfaces, displaying various indicators, plus mechanisms for input transmission.

In line with the general principles of Nau Engine's architecture, we designed the GUI system as a separate module that will be used in GO projects in the upcoming beta version.

The basic components of Nau Engine's GUI system are built on top of existing solutions from the open-source engine Cocos2dx. Additionally, we use the Dear ImGui library for technical and debugging purposes, as well as rendering service entities.

Input handling in Nau Engine is implemented through a low-level gainput system and our own solution on top of it. In the November version, developers will have the ability to create projects with keyboard and mouse support.

The realism of what's happening on screen isn't just determined by the physical model under the hood, but also by the breadth of animation settings for various objects. It's these settings that allow you to turn a static image into a living, dynamic scene, responding variably to the player's actions.

In the beta version, developers will be able to work with keyframe animations to set up object positions and properties on stage, as well as import skeletal animations for characters (and other objects using skeletal models) and manage them from user logic scripts. The foundation for importing and playing back skeletal animations is provided by open-source code from the ozz-animation library.

In late November, we're expecting a significant milestone in our interaction with a wide range of users. Ahead lies projects that will start using our engine and developers who will be improving it – both for themselves and for the entire community.

As a product team with open-source code developed for the community and together with the community, we would be happy to receive feedback from you, future Nau Engine users, and all other concerned colleagues.