Ares Engine Architecture

Introduction

The Ares Engine can morph into practically any kind of game engine one might desire. The engine architecture is based upon plugins to make modifying and extending the game engine a very straight forward effort. For example, even the game loop, while perhaps the core concept of any game engine, is itself a plugin, making it possible to replace one game loop for another by merely swapping one plugin for another.

The engine core is limited to just the bare essentials to load the plugins and integrate them into a cohesive system that can work together. (It is, in a sense, just a boot strap loader and API layer.)

The code is designed for clarity. For example, the entry point of the engine defined by the Windows operating system is the C function, WinMain. This can be found in the windows' executable project in a file MainEntryWin32.cpp, whose name is designed to facilitate easy discovery for the entry point.

There is a plugin manager that is solely responsible for loading plugin modules at runtime and is operating system specific (e.g., dynamic linked libraries for Windows, shared objects for Linux, etc.).         

There is an operating system agnostic platform which is well known throughout the code base that acts as an API layer to which each plugin can publish their interfaces, and through which each plugin can access the API of other plugins. 

Interfaces

The code base uses abstract C++ classes to define interfaces between class objects. Each plugin publishes one or more interfaces for use by other plugins. These interfaces represent what services the plugins offer. Plugins only access other plugins through their published interfaces. This means that no plugin is dependent upon any other plugin. This also means that many of the interfaces are well known to the engine at large.

Plugin

Plugins are installed into the engine through the following steps:

Discovery - The first thing the engine does is discover all of the plugins that are installed.

Loaded - Each plugin is loaded and instructed to integrate with the engine.

Initialize  - All plugins are initialized, gathering the interfaces to other plugins and preparing to provide their services to other plugins.

startup - All plugins begin normal operations.

The Game Loop

Once all plugins are ready to be fully used, the main code passes control to the GameLoop plugin.

The game loop is simply a sequence of event signals being raised, one after another. They are synchronous in nature. That is, one signal must have fully processed across all plugins that subscribed to it before the next event signal is raised. It is through this signaling architecture that the code supports a robust design of separation of responsibilities (e.g., the GameLoop plugin has no idea which plugins if any respond to any of its events) and thus reducing the maintenance burden when making changes to any one part of the engine code.

In addition, though the sequence of signals being raised throughout the game loop is synchronous, this doesn't prevent the plugins from responding by initiating asynchronous tasks. However, the burden for managing the thread synchronization falls on the code responsible for initiating the tasks, including offering synchronization workflow through its interfaces.

The game loop must play nice with the operating system. The game loop looks for operating system events near the top of the loop and queues as many as possible for processing later in the loop rather than blocking.

Tokens & The World Manager

The scene is managed by the world manager, a plugin that bookkeeps the Tokens in the World. Tokens are the objects in the scene, both those that you can see because they render, and those that are never visible (audio, rules, data, etc.).

The world manager includes a streaming service that helps game developers stream in sections of their open worlds in intelligent and optimal fashion. 

The Player possesses a Token to interact with the scene. Once a Player has possessed a Token (a Pawn, usually a character Token), it can then have its possessed Pawn possess another Token (e.g. vehicular Token). The entire design is to simplify the game developer's effort to interact with and take control of vehicles or other types of Tokens.

Rendering with Vulkan

The rendering plugin that comes default with the engine utilizes the Vulkan API to render with modern GPUs. The plugin is designed to make use of multiple discrete GPUs (dual GPU cards in a single box) to support multiple local players (e.g., coop campaign or multiplayer).

Memory is allocated by the plugin in heaps. (Images are stored in GPU memory apart from these heaps.) The direct heap is the GPU memory that is directly accessible by both CPU and GPU. The indirect heap is that memory only accessible by the GPU. The shared heap is the CPU memory accessible by both CPU and GPU memory. Each has their uses based upon their performance characteristics.

Mesh level of detail (LOD) is auto generated upon asset import. This is a simple approach that has much room for improvement for both an enhanced import workflow (e.g., importing recognizes multiple LODs, IDE provides LOD selections and generations, etc.)

3D animation is accomplished with up to four weighted joints.

A compute shader is ran at the start of each frame rendering to calculate which meshes are to be rendered and at which level of detail. Then a series of indirect draw commands are performed - once for opaque meshes, and once for translucent meshes.

The plugin utilizes the Physically Based Render Diffuse Model. Since photo realism is not a goal, not all of the PBR Diffuse Model is utilized.

Physics

Ares Engine integrates the prestigious Jolt Physics library as its default physics system. While height fields were explored for the purpose of terrain collision surfaces, it was felt that mesh bodies were on par with height fields for performance, yet offered superior flexibility for designing complex terrain. Anything that must be moveable must utilize a collision body other than mesh bodies (which are static), such as convex hull, spheres, etc.

The world manager intelligently caches new collision bodies for Tokens that are preparing to spawn into the world to maximize overall performance at run time. This allows the world manager the flexibility to create the bodies in the background. Then, without impacting game play, the world manager plugin can instruct the physics plugin to either insert them into the system or release their resources if the course of game play changes. 

Netcode

Ares Engine will include a netcode solution based upon CodeNet's implementation for the Unity3D engine.

Asset Import

glTF 3D assets can be imported into the game, including meshes, nodes (and joint information), animations, and textures. Future enhancements listed in the roadmap include importing the FBX format. Additional formats may also be considered.